Timewarp Attack — согласованная манипуляция временными метками заголовков блоков, искажающая следующий расчёт сложности. Атака может снизить сложность без соответствующего падения хешрейта и ускорить создание блоков.
Bitcoin пересчитывает сложность каждые 2016 блоков, стремясь к среднему интервалу 10 минут. Из времени последнего блока периода вычитается время первого: учитываются лишь 2015 интервалов. Промежуток между последним блоком одного периода и первым следующего в эти разности не входит. На этой границе время можно вернуть назад без непрерывной связи между двумя расчётами. [4] [3]
Время нового блока должно превышать Median Time Past (MTP), медиану времени предыдущих 11 блоков. Но оно не обязано быть позже времени непосредственно предыдущего блока. Злоумышленники могут ставить большинство меток лишь на 1 секунду выше MTP, последнему блоку периода указать примерно реальное время, а затем снова более раннее. Они меняют время новых блоков, а не переписывают уже подтверждённые заголовки. [1]
Классический сценарий предполагает большинство хешрейта либо меньшинство с дополнительным влиянием на порядок блоков, например через Selfish Mining. Нужен длительный контроль временной последовательности, а не один блок с необычным временем. Подготовка классической атаки занимает примерно месяц и оставляет публично видимые следы в цепочке. [1]
Во втором атакованном периоде метки могут создать видимость средних 20 минут на блок и примерно вдвое снизить сложность. Следующий период добывается быстрее, но искажённое время снова требует снижения. Ограничение одной корректировки четырёхкратным множителем не мешает повторению. Теоретический долгосрочный предел по MTP соответствует примерно 6 блокам в секунду; это не обещание практической пропускной способности сети. [1] [3]
Быстрые блоки перенесли бы получение будущей блоковой субсидии в более короткий срок; сами по себе они не повышают предел 21 миллион BTC. Узлам пришлось бы быстрее проверять и передавать данные. Перегруженные процессоры, слабые соединения, конкурирующие ветви и частые реорганизации снизили бы надёжность подтверждений. [1]
BIP 113 использует MTP предыдущего блока для проверки абсолютной блокировки nLockTime, заданной временем. Блокировка, заданная высотой блока, по-прежнему зависит от высоты. При атаке MTP может двигаться значительно медленнее реальных часов. Средства в контракте с временным условием могут оставаться недоступными дольше ожидаемого, а сложные протоколы — потерять согласованность этапов. [5] [1]
Предложение ограничивает время первого блока периода: оно не может быть раньше предыдущего блока более чем на 7200 секунд, то есть два часа. Время последнего блока также не может быть меньше времени первого. Спецификация имеет статус Complete. Это означает завершение предложения, а не активацию: для обязательного применения новых правил консенсуса в mainnet нужна отдельная активация. [2]
Сравнивайте время заголовков, MTP, границы каждых 2016 блоков, реальный темп майнинга, сложность и хешрейт. Различайте классическую атаку и вариант Murch–Zawy, правила testnet и mainnet. Программа может заранее создавать более безопасные шаблоны блоков; это ещё не означает, что вся сеть отклоняет каждый блок, нарушающий предлагаемую защиту. [3] [2]
Для полной картины прочитайте эту статью вместе с Difficulty Adjustment, Майнинг, Proof of Work, Consensus Cleanup, Timelock, Reorg. На эту статью также ссылаются Consensus Cleanup.
01Нужно ли атаке большинство хешрейта?+
Классический сценарий предполагает большинство либо другое преимущество, дающее нужное влияние на порядок блоков. Меньший майнер без такого преимущества недостаточно контролирует их время.
02Достаточно ли защиты Median Time Past?+
Нет. MTP ограничивает отдельные метки, но не закрывает пробел между периодами. BIP 54 предлагает дополнительные ограничения связи между временем первого и последнего блока.