В статье Википедии о деревьях Меркла я как раз читал это, не в силах понять, в чем кроется проблема:
Вторая атака прообраза
Корень хеша Меркла не указывает глубину дерева, что позволяет проводить атаку второго прообраза, при которой злоумышленник создает документ, отличный от оригинала, с тем же корнем хеша Меркла. В приведенном выше примере злоумышленник может создать новый документ, содержащий два блока данных, где первый — это хэш 0-0 + хеш 0-1, а второй — хэш 1-0 + хэш 1-1.
Одно простое исправление определено в Certificate Transparency : при вычислении хэшей конечных узлов к хеш-данным добавляется байт 0x00, а при вычислении хэшей внутренних узлов — 0x01. Ограничение размера хеш-дерева является необходимым условием для некоторых формальных доказательств безопасности и помогает сделать некоторые доказательства более надежными. Некоторые реализации ограничивают глубину дерева, используя префиксы глубины хэш-дерева перед хэшами, поэтому любая извлеченная цепочка хэшей считается действительной, только если префикс уменьшается на каждом шаге и остается положительным при достижении листа.
Мои первые вопросы: действительно ли это проблема Биткойна? Если да, то как это решается в ядре Биткойн?
Мои вторые вопросы: можно ли решить эту проблему, сохраняя глубину дерева каждого блока непосредственно в цепочке блоков? Или, если говорить о Биткойне, не повлияет ли это как-то негативно на саму процедуру проверки блока?
Да, такие атаки действительно влияют на Биткойн, они известны и описаны. Биткойн не имеет для них каких-либо смягчений на уровне консенсуса, потому что для этого требуются изменения консенсуса, которые трудно сделать. Известно, что структура дерева Меркле Биткойн имеет множество уязвимостей.
Конкретная атака, описанная в Википедии, заключается в том, что внутренний уровень может быть представлен как действительный документ. В Биткойне это теоретически возможно, хотя для создания блока, в котором транзакции создают хэши, потребуется значительная работа, которую затем можно десериализовать как действительные транзакции. Если бы такой блок был создан, это могло бы привести к сетевому разделу из-за поведения, связанного с кэшированием недопустимых блоков. Очевидно, что решение этой проблемы состоит в том, чтобы убедиться, что кешированные недопустимые блоки тщательно обрабатываются, чтобы избежать отклонения блоков для вещей, которые могут быть изменены третьей стороной.
Фактически, эта конкретная проблема привела к уязвимости в Bitcoin Core 0.13, которая с тех пор была исправлена. Описание уязвимости доступно в списке рассылки bitcoin-dev .
Есть еще одна связанная атака, идущая в другом направлении, включая транзакцию в блоке, который можно интерпретировать как внутренний узел в дереве Меркла. Эта атака может быть использована для нацеливания на кошельки SPV и обмануть эти кошельки, заставив их думать, что транзакция была включена в блок, хотя это не так. Эта атака описана Серджио Демианом Лернером в этом сообщении в блоге .
Единственное верное решение этой второй атаки требует некоторого изменения консенсуса, чтобы ввести глубину дерева. Но изменения консенсуса сложны, и есть другие вещи, которые можно сделать. Кошельки SPV могут защитить себя, проверив, что никакие внутренние узлы не могут быть сериализованы как действительные транзакции. Маловероятно, что такой внутренний узел появится случайно, поэтому это не должно иметь никакого реального влияния на пользователя. В Bitcoin Core для защиты от этой атаки 64-байтовые транзакции не будут ретранслироваться. Поскольку 64-байтовые транзакции меньше, чем любая стандартная транзакция, это безопасно.