Если есть (2 ^ п) + 1 сделок, то последняя сделка хешируется с собой снова и снова на каждой стадии Merkle дерева.

Например, если бы было 5 (4 + 1) сделки, то дерево вычисляется следующим образом.

А, В, С, D, Е

Первый проход занимает 5 хешей и уменьшает его до 3

Х = Н (А, В)
Y = H (С, D)
Z = Н (Е, Е) (Е хэшированный с собой)

X, Y, Z,

Следующий проход занимает 3 и уменьшает его до 2

М = Н (Х, Y)
Н = Н (Z, Z) (Z хэшированный с собой)

Затем они объединяются, чтобы дать окончательный корень.

Н (М, N),

Тем не менее, Z представляет собой Н (Е, Е), так что N чисто определяется Е.

Чем глубже дерево, тем больше хэши должны быть выполнены, но он по-прежнему чисто решается Е.

Это означает, что, чтобы доказать, что Е была в дереве, вам просто нужно обеспечить E (так N может быть вычислена), M и глубина дерева.  

Это гораздо более компактным.

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

Сделка будет действительной, если он переехал 0BTC из некоторого вывода на выход транзакции.

Если транзакция была создана, который заплатил 0BTC в OP_TRUE, то он может быть использован как начало "пустой" сделка цепь.

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

Это позволило бы дополняя список транзакций, чтобы степень 2. Каждая транзакция будет использовать предыдущую операцию заполнени в качестве входных данных.

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

Заголовок может затем быть расширен за 80 байт.

Стандартный - 80 байт
ИНТ версия
Hash предыдущая
Hash Merkle
ИНТ метка времени
ИНТ биты
ИНТ нонс

Info - 65 байт
гашиш "M"
Хэш-предыдущей транзакции, используемый E
var_int tree_depth
var_int extra_field_length

Дополнительные поля - ??
var_int blockHeight (например)

Сделка Е можно определить, зная предыдущую сделку, что она тратит. Остальная часть сделки является стандартным и Hash (дополнительные поля) входит в сделку. Вся эта информация содержится в расширенном заголовке.

Это позволяет полный заголовок + вспомогательный заголовок проверяется без необходимости какой-либо другой информации.

Это обратная совместимость.

Недостатком является то сделка спам. Тем не менее, шахтеры могли бы поощрять стремиться к степеням 2 сделок.

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

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

Переменная extra_field_length будет означать, что клиенты могут по-прежнему проверять заголовки, которые имеют новые поля, чем клиент понимает.