Может ли злонамеренный мажоритарный майнер переписать историю?

Действительно ли злонамеренный майнер с большей мощностью хеширования (скажем, 99%) может выполнить атаку двойного расходования, переписав историю?

Если да, то не могу понять как. Если нет, то при каких обстоятельствах вообще возможна двойная трата?

Рассмотрим следующие простые предположения:

  1. Злоумышленник-майнер M контролирует 99% хэш-мощности
  2. M не контролирует большую «мощность реле» (например, он управляет только одним узлом в сети).
  3. Текущий законный блокчейн (до атаки) не имеет форка и состоит из блоков B0, B1,..., B10, и 100% узлов в сети согласны с этим.
  4. Злоумышленник хочет аннулировать блоки B6-B10
  5. Злоумышленник добыл альтернативные блоки B6' (поверх B5), B7', ..., B11'.

Как злоумышленник может осуществить атаку?

Если он сначала опубликует B6', не отклонят ли его все узлы, потому что он построен поверх блока, отличного от последнего, что предотвратит атаку?

Если он сначала опубликует B11', не отклонят ли его все узлы, потому что он построен поверх неизвестного блока (еще не видя B10'), тем самым предотвратив атаку?

Примечание: предположение 2 кажется неуместным. Если M будет контролировать 99% хэш-мощности, он наверняка сможет управлять сотнями узлов по всему миру. Он всегда может решить, сколько использовать, в зависимости от своих потребностей в совершении злонамеренных действий.
Он по-прежнему не может использовать эти сотни узлов, чтобы изменить мнение других узлов.
Если бы биткойн-узел мог точно знать, какой блок является последним, все эти множественные подтверждения не понадобились бы.
@pieter, вот почему я сказал неуместно: в любом случае не имеет значения.
Яннес: так вы говорите, что злоумышленник с такой же суммой денег, но без большой вычислительной мощности, мог бы сделать то же самое? Это неправильно. Количество узлов не имеет значения, но имеет значение скорость хеширования.
@PieterWuille эм... тут недопонимание. Предположение 2 говорит о «мощности реле», т. е. о количестве узлов, которыми управляет атакующий. Я просто говорю, что не имеет значения, запустит ли он 1 или 100 узлов, чтобы его атака увенчалась успехом или нет. Это не имеет значения.
@Jannes Мои извинения! Я пропустил, что вы говорили о предположении 2.

Ответы (1)

Давайте на минуту предположим, что ваша теория верна, и что реальные узлы в сети не примут эту новую, действительную и более длинную цепочку блоков.

Это само по себе было бы ошибкой. Может быть, это неочевидно для реорганизации в 5 блоков, но если бы это была реорганизация в 2 блока (что действительно происходит на практике), ваш аргумент был бы в равной степени верным. Если бы не было возможности принять глубокую реорганизацию на 2 блока, узлы застряли бы в своей более короткой цепочке. На самом деле это тоже можно использовать: кто-то может намеренно попытаться привести вас в такое состояние, так как вы не увидите новых платежей в цепочке, которые могут конфликтовать с платежом, который злоумышленник пытается вам отправить.

Это верно для любой глубины реорганизации. Если мы не примем 12-блочную глубокую реорганизацию, сеть останется в очень тяжелом состоянии, если когда-либо произойдет разделение сети на несколько часов. Возможность принять самую длинную действующую цепочку при любых условиях абсолютно необходима для конвергенции Биткойна.

Итак: нам нужен механизм для реорганизации почти любой глубины. То, как это достигается, изменилось в Bitcoin Core 0.10 с введением синхронизации заголовков.

До версии 0.10 атакующий сначала транслировал B11', о чем жертва не знала. Он отправит getblocksсообщение для запроса хэшей блоков между B5 (используя локатор блоков) и B11'. Когда он получит эти хэши, он загрузит их один за другим с помощью getdata, увидит, что у них отсутствует родитель, поместит их в пул сирот (набор блоков без известного родителя), а когда все они будут получены, заметит, что они соединяются. , и переключитесь на него.

Начиная с 0.10 , атакующий будет invB11'. Жертва будет использовать getheadersсообщение для запроса заголовков блоков между B5 и B11' и getdataдля самого блока B11'. Когда приходят заголовки, они проверяются на лету (в порядке увеличения высоты, чтобы они всегда соединялись). К тому времени, когда появится B11', мы уже знаем о его родителях и знаем, что (при условии, что родители действительны) это будет новая лучшая цепочка. Затем мы начнем извлекать фактические блоки с B6' по B10', чтобы заполнить пробелы, и когда они все будут получены, переключимся на эту цепочку.

Это не значит, что крупные реорганизации не сработают тревожными звоночками, верно?
Да, в самом деле. В какой-то момент становится достаточно неопределенно, что может потребоваться вмешательство человека.
Может ли злонамеренный мажоритарный майнер переписать историю?
СпросиСетьПолитика конфиденциальности1y, 0v