Что предотвращает DoS на основе почти действительных временных меток блоков?

При получении вновь добытого блока проверка временной метки блока выполняется здесь:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3263-L3270

Q1: Что касается второй проверки (временная метка блока находится слишком далеко в будущем), что мешает майнеру транслировать в будущем блок, близкий к лимиту, и заставить некоторые узлы принять блок, а некоторые другие узлы отклонить блок?

Q2: Если часть сети принимает блок, а другая часть сети отклоняет блок (т. е. не записывает блок в свое дерево блоков из-за недействительной метки времени), может ли сеть каким-либо образом восстановиться после этого?

Ответы (3)

Отвечаю сразу на оба вопроса. Нередко сеть разделяется, т. е. разные узлы принимают разные блоки в качестве вершины цепочки. На самом деле это происходит время от времени, когда два или более блоков одновременно обнаруживаются разными майнерами. Это решается, когда следующий блок находится поверх одного из предыдущих блоков. Самая длинная цепочка действительна.

И майнер не может просто установить метку времени при трансляции. Отметка времени должна быть установлена ​​до того, как будет найден действительный одноразовый номер. Таким образом, майнер получает стимул к майнингу с действительной отметкой времени. Если блок не принимается сетью, использованный хешрейт (и электричество) не компенсируется.

Спасибо за решение этого вопроса, но на самом деле это не отвечает на вопросы, вот почему: в случае «обычной» вилки, о которой вы говорите, деревья блоков разных узлов содержат оба блока, тогда как в этом случае деревья блоков существенно отличаются, и поэтому они не могут синхронизироваться/переключаться на ветку с дополнительным доказательством работы. Что касается поощрения майнера, когда дело доходит до манипуляций с метками времени, конечно, майнер не поощрен, но вопрос в том, возможно ли это теоретически или нет.

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

В описанном случае, что не так, но, если так или иначе может быть иначе, тогда некоторые узлы могут продолжать строить на блоке, который отвергают другие узлы. Как это будет решаться, будет зависеть от процента разделения сети. Если 51% или более мощностей майнинга отклоняют спекулятивный блок, проблема со временем разрешится сама собой, поскольку действующая цепочка расширяется дальше и имеет наибольшее PoW. Если, с другой стороны, 51% или более мощностей майнинга принимают спекулятивный блок для построения, то потребуется вмешательство, чтобы подобрать узлы, которые все еще отклоняют, или отбросить недействительную цепочку.

По сути, если блок соответствует правилам консенсуса (правилам эталонного клиента), то он действителен.

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

Спасибо за 2-й абзац, однако 1-й абзац неверен: в этом случае верхняя граница достоверности метки времени определяется как время локального узла + смещение сетевого времени (в основном оценивается ошибка локального времени на основе одноранговых узлов). Таким образом, можно представить себе, что майнер добывает блок с отметкой времени, близкой к верхней границе, и блок отклоняется некоторыми узлами и принимается другими узлами. ссылка: GetAdjustedTime() на github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3398
Хорошо, я согласен, что эта деталь ускользнула из моей памяти. Я пересмотрю написание первого абзаца.
@ bgd223 bgd223 Не будет ли тогда, что через несколько минут отметка времени блока действительно будет действительной? В худшем случае это требует пересмотра блока или даже меньше, ничего согласно объяснению Г. Максвелла.
Согласен, если предположить, что нет механизма, который повторно отклоняет уже отклоненные блоки в любом сценарии. и DoS на основе нижней границы в данном случае, похоже, не применяется.

Это нормально и не проблема, когда часть сети находится на одном блоке наконечников, а остальные — на другом. Когда есть такое разделение, оно в конечном итоге будет решено последующими блоками.

Если блок не принят узлом из-за того, что его временная метка находится слишком далеко в будущем, ситуация не сильно отличается: после того, как временная метка станет допустимой, будущий блок на этой ветке, который сделает эту вилку самой длинной цепочкой, вызовет реорганизацию. на него. Таким образом, единственная разница между этим и разделением, вызванным обычной гонкой блоков, заключается в том, что узлам, которые отклонили блок, потребуется больше времени, чтобы принять его — до тех пор, пока и время не будет действительным, и новый блок не появится на этой вилке.

Вмешательства не требуется.