Технология блокчейна — биткойн-сегрегированный адрес-свидетель и атака на пластичность

внешний интерфейс блокчейн
Технология блокчейна — биткойн-сегрегированный адрес-свидетель и атака на пластичность

Автор: Линь Гуаньхун / Призрак под кончиками пальцев. Репринтер, пожалуйста: Обязательно указывайте источник.

Самородки:самородки.IM/пользователь/178526…

Блог:www.cnblogs.com/linguanh/

Гитхаб:GitHub.com/afan913337456…

Облачная колонка Tencent:cloud.Tencent.com/developer/U…

Совет: для чтения этой статьи необходимы базовые знания технологии Биткойн.

содержание

  • Справочная информация
  • протокол
  • Генерация отдельного адреса свидетеля
  • Принцип расширения
  • Проверка транзакции
  • податливая атака
    • Сцены
    • Вопросы и ответы
    • Изменить код S

Справочная информация

Segregated Witness возникла в результате апгрейда Биткойна.Это обновление включает в себя уровень консенсуса.Он поддерживает дополнительный режим транзакций - транзакцию Segregated Witness, что также привело к софт-форку.

он появляется на заднем плане для解决下面两个问题:

  1. Биткойн «вызван уязвимостью алгоритма подписи на эллиптических кривых ECDSA»延展性攻击"вопрос;

  2. Достижение биткойнов в определенной степени区块扩容цель.

протокол

обращать внимание,“隔离见证地址”это биткойн“隔离见证体系”Часть всей системы Segregated Witness состоит из нескольких частей. Введение в полную систему находится в Биткойн改进协议（BIP）Внутри в основном задействованы следующие протокольные документы:

  1. BIP-141, ссылка:GitHub.com/bitcoin/Force…, 141 дал подробное введение в Segregated Witness, включая его определение и использование;

  2. BIP-143, ссылка:GitHub.com/bitcoin/Force…, 143 дал подробное представление о Segregated Witness с номером версии 0, его подписи в транзакции и общем процессе проверки подписи;

  3. BIP-144, ссылка:GitHub.com/bitcoin/Force…, 144 дал подробное представление о том, как работает Segregated Witness и участвует в одноранговой (P2P) сети;

  4. BIP-173, ссылка:GitHub.com/bitcoin/Force…, лицом к лицу с Segregated Witness в 173地址Сделал введение, в том числе какой формат кодировки он использует, что такое код проверки и так далее.

Чтобы ознакомиться с другими официальными сведениями о Segregated Witness, вы можете просмотреть полностью улучшенный протокол самостоятельно по ссылке:GitHub.com/bitcoin/Force…

Генерация адресов

Давайте посмотрим, как генерируется адрес Segregated Witness. Все этапы генерации адреса Биткойн начинаются с открытого ключа и должны пройти несколько этапов.字节拼凑сделай это сноваhash算法а также编码процесс. Точно так же процесс генерации адреса Segregated Witness аналогичен.Ссылаясь на протокол BIP-173, мы можем резюмировать процесс его генерации:

  1. Приготовьтесь в биткойнах, разблокируйте скрипт в16进制哈希字节流, в настоящее время существует два основных типа, а именно P2WPKH и P2WSH. Наиболее очевидная разница между этими двумя скриптами заключается в том, что хэш в P2WPKH занимает 20 байт, а хэш в P2WSH — 32. Соответствующие структуры скрипта:
  • P2WPKH:OP_0
  • P2WSH: OP_HASH160 OP_EQUAL

  1. Выберите строки «hrp», соответствующие разным сетям Биткойн, а именно, основной сети: «bc», тестовой сети: «tb» и частной сети regtest: «bcrt». Эта информация определяется в файле конфигурации в исходном коде, например, путь к версии Go:github.com\btcsuite\btcd\chaincfg\params.go.

  2. Поток байтов на шаге 1 кодируется 5 битами на байт, исходный — 8 битами на байт, а результат устанавливается равным B;

  3. Добавьте 0x00 байт к началу B, результат будет равен C;

  4. Используйте алгоритм проверки кода генерации "bech32", чтобы сгенерировать код проверки D для потока байтов hrp и C;

  5. Добавьте D к задней части C, результат будет равен E;

  6. Сборка: hrp + "1" + E объединить строку сопоставления таблицы кодирования, чтобы получить адрес.

Среди них, на шаге 1, хотя открытый ключ напрямую не участвует в генерации, хэш-данные в нем также эволюционируют из открытого ключа. седьмой шаг“bech32”из编码表字符组合Да:qpzry9x8gf2tvdw0s3jn54khce6mua7l. Поскольку количество байтов хеш-структуры в разных скриптах разное, то и результаты разные. На следующем рисунке представлена ​​блок-схема, соответствующая вышеуказанным этапам генерации:

Реализация кода генерации адресов может использоваться напрямуюbtcd源码Функции, представленные в , как показано на следующем рисунке:

Принцип расширения

торгуется в биткойнах一般打包流程, это займет каждую транзакцию签名数据также включены, как показано на рисунке ниже.

В то же время мы знаем, что一个区块所能容纳的数据量大小是有限的, что означает, что количество транзакций, которые могут быть упакованы в блок, также ограничено.Если мы сможем найти способ уменьшить объем данных в транзакции, мы сможем косвенно достичь цели расширения блока.

Суть Segregated Witness в том, что при упаковке блока подписанные данные не упаковываются, а подписанные данные размещаются в другом месте. Если так, то怎样验证交易的签名是否正确, чтобы гарантировать, что данные не были подделаны?

Проверка подписи транзакций с сегрегированными свидетелями

Метод такой, когда транзакция вот-вот будет инициирована и построен входной Vin скрипта, входные данные скрипта разблокировки помещаются в другое поле, в исходном коде имя этого поля: Witness. Когда транзакция отправляется на узел транзакции, код узла извлекает данные из этого поля для восстановления сценария разблокировки, а затем выполняет операцию проверки подписи на узле.После прохождения проверки подписи подписанные данные больше не будут быть упакованным в блок.Внутри, когда транзакция будет использована в будущем, сценарий разблокировки также восстанавливается из поля Witness.

Вместо типа транзакции Segregated Witness поле Witness не имеет данных, а данные скрипта разблокировки переносятся в подпись, так что восстановить его можно только из подписи, а это значит, что данные подписи должны быть упакованы в блок. Ниже приведена структура Vin и связанное с ней выше:

type Vin struct {
    // 省略无关字段
    ScriptSig *ScriptSig  `json:"scriptSig"`
    Witness   []string   `json:"txinwitness"`
}

ScriptSig 放置的就是签名数据,Witness 放置的就是解锁脚本数据. Функция восстановления скрипта в исходном коде находится в части виртуальной машины кода операции Биткойн, как показано на следующем рисунке.

податливая атака

Как упоминалось выше, одной из предпосылок появления Segregated Witness является решение «атаки пластичности», которую также называют «атакой подделки», английское название: атака пластичности транзакций.

В 2014 году на бирже MT.GOX (Mentougou) было потеряно 850 000 биткойнов, после чего стороны обвинили в аварии атаку на пластичность транзакций биткойнов. Давайте посмотрим, как он достигает цели атаки. В Биткойне учетными данными, которые отличают транзакцию, является идентификатор транзакции или TxId. Если TxId двух транзакций различаются, они будут считаться двумя разными транзакциями. Когда мы используем браузер блокчейна для ежедневного просмотра транзакций, мы также будем запрашивать транзакции на основе TxId.Два разных TxId определенно не являются одной и той же транзакцией.

Теперь предположим такой сценарий:

A использует алгоритм подписи на эллиптической кривой ECDSA для отправки транзакции T на биткойн-узел N. В это время N проверит, существует ли уже T в пуле транзакций, и связанную с ним логику в соответствии с идентификатором T. Если обнаружится, что это уже существует и не соответствует условиям замены, то A будет возвращено сообщение об ошибке. Если он не существует, он будет помещен в пул транзакций в ожидании обработки, а идентификатор T будет возвращен A. В настоящее время предполагается, что B сам написал программу, проследил за пулом транзакций узла Биткойн, нашел транзакцию T, извлек T и получил поле ScriptSig в структуре Vin. Блок-схема, соответствующая приведенному выше сценарию, показана на следующем рисунке.

Что делает B после получения ScriptSig от T? Во-первых, несомненно, что B не должен вмешиваться в данные T, так как же он это делает?“延展性攻击”?

Затем B делает следующее:

B Восстановите целые числа R и S информации о подписи из ScriptSig, используя соответствующий код ECDSA. Затем, в соответствии с уязвимостью алгоритма шифрования на основе эллиптических кривых, модифицируется S, перегенерируется подписанный ScriptSig и транзакция воспроизводится. Обратите внимание сюда! Во время воспроизведения узел N повторно сгенерирует TxId_2 на основе информации обо всей транзакции, включая ScriptSig, но поскольку ScriptSig был изменен, TxId отличается, поскольку TxId генерируется алгоритмом хеширования, а алгоритм хэширования отличается. в разных В случае ввода вывод определенно не одинаков.

Описание операционной части B оставляет два вопроса:

  1. Если та же транзакция будет отправлена ​​в цепочку, не будет ли обнаружена входная часть (UTXO)?

  2. Почему ScriptSig изменен, но подпись все еще успешна?

отвечать:

  1. Поскольку модель учетной записи Биткойн основана на UTXO, если определенный UTXO не был потрачен, его можно попытаться удвоить. И когда оно было съедено, было бы ошибкой потреблять снова в это время. В приведенном выше примере UTXO в транзакции T и его модифицированная копия B, хотя и являются одинаковыми, не израсходованы, поэтому на них можно ссылаться несколько раз. То есть обнаружение, только чтобы определить, было ли оно потрачено на цепочку.

  2. Причина, по которой подпись может быть успешно проверена, заключается в том, что в алгоритме подписи на эллиптических кривых ECDSA подпись может быть проверена для S и R, и подпись также может быть успешно проверена для отрицательных S и R. Но отрицательный S приводит к другому TxId.

Блок-схема атаки B показана на следующем рисунке:

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

В это время предположим, что A — это биржа, и она помогает пользователю снять наличные в это время, а B — пользователь. но он этого не знает.Также есть TxId_2 который выполняет ту же операцию снятия. Тогда в это время упаковывается TxId_2, а Б, как злоумышленник, считает, что его атака удалась, и он пойдет на биржу и скажет, почему его вывод не удался. И A проверит и обнаружит, что его TxId не удался, а затем повторно инициирует операцию вывода пользователю. На данный момент B получил два или более перевода по цепочке.

Весь описанный выше процесс представляет собой «растягивающую атаку».

Изменить код S

Конкретная реализация в коде также очень проста: вам нужно всего лишь добавить строку кода, чтобы изменить букву S в подписи, чтобы проверка подписи по-прежнему была действительна. На картинке ниже рабочая функция, которую я реализовал,为了不被滥用，关键行数已打码.

Код для изменения S в подписи:

над

Категории