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 пропонує додаткові обмеження зв’язку між часом першого й останнього блока.