Поведение биткойн-клиента в случае форка

Что происходит, когда разветвленная цепочка становится длиннее основной цепочки блоков?

Предположим, что в разветвленной цепочке, которая только что стала длиннее, нет транзакций, так что все транзакции в последних n блоках никогда не происходили.

Насколько я понимаю, официальный биткойн-клиент распознает, что любые недавние отправленные им транзакции больше не существуют, и повторно транслирует их. По вопросу,

  • Какие возрастные транзакции будут переоформлены? Будет ли переоформлена транзакция, которой уже несколько лет? Какая отсечка?
  • Будет ли перевыпущена точная транзакция или будет создана эквивалентная транзакция? т. е. попытается ли он отправить точно такие же биткойны (которые из-за форка могут больше не принадлежать ему) или создаст эквивалентную транзакцию на основе биткойнов, которыми он все еще владеет? Что делать, если у клиента недостаточно биткойнов?

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

Ответы (2)

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

Этот конфликт с ответом Сипы. Вы написали «даже если у них нет шансов попасть в цепочку, потому что они теперь недействительны», а он написал «при условии, что они действительны в новой цепочке». Кто прав?
Мы говорили о разных вещах: * владелец транзакции будет ретранслировать при условии, что его транзакция не будет принята (уже), даже если у нее нет шансов. * другие узлы в случае реорганизации будут перемещать транзакции обратно в пул памяти, если они допустимы в новой цепочке. Это не связано с ретрансляцией.

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

Эффект от перемещения транзакций обратно в пул памяти заключается только в том, что клиент их не забывает (он не будет повторно анонсировать или скачивать их с пиров, когда о них сообщат), а если нода является майнером, то они будут кандидатами на включение в следующем созданном блоке.

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

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

"при условии, что они допустимы в новой цепочке" - где это условие в коде? Я просто сканировал его, но не видел.
::Reorganize в main.cpp восстанавливает потерянные транзакции, передавая их в пул AcceptToMemory, который вызывает те же проверки, что и для транзакций, которые приходят в виде сообщения tx.
Да, но он делает это до того, как вызывается RemoveFromMemoryPool для транзакций, которые были на предыдущем лучшем форке, и поэтому разве не бывает так, что проверки могут пройти из-за транзакций, которые существовали только в старой ветке, и скоро не будут больше не существует?
vConnect — это список транзакций во вновь подключенной ветке.
> «он не будет повторно объявлять». Таким образом, повторное объявление не в интересах отправителя, если он планирует удвоить расходы. Звучит как вектор атаки, который нужно решить.
Поведение биткойн-клиента в случае форка
СпросиСетьПолитика конфиденциальности1y, 0v