Создание адреса P2WSH из спецификации BIP173

Спецификация BIP173 определяет, как создавать собственные адреса Bech32 Segwit.

В разделе примеров приведен открытый ключ: 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798.

На основе этого ключа довольно легко сгенерировать адрес P2WPKH: ключ хешируется с помощью SHA256, затем с помощью RIPEMD160 и используется результат шестнадцатеричного декодирования в качестве программы-свидетеля (первые две команды — это простой интерфейс командной строки, а последняя — из библиотеки Dart bech32). ):

$ echo 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 | xxd -r -p | openssl sha256
(stdin)= 0f715baf5d4c2ed329785cef29e562f73488c8a2bb9dbc5700b361d54b9b0554                                                                                                                                                                                                                                      

$ echo 0f715baf5d4c2ed329785cef29e562f73488c8a2bb9dbc5700b361d54b9b0554 | xxd -r -p | openssl ripemd160                                                                                                                                                         
(stdin)= 751e76e8199196d454941c45d1b3a323f1433bd

Segwit('bc', 0, HEX.decode("751e76e8199196d454941c45d1b3a323f1433bd"))
// bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3

Генерация P2WSH включает в себя сценарий key OP_CHECKSIG, за которым следует однократное хэширование SHA256. Я в недоумении, как построить указанный скрипт. Код операции закодированOP_CHECKSIG как . Но добавление этого к ключу кажется глупым (и не работает). Кроме того, код операции требует двух параметров. Что мне хешировать?0xacCHECKSIG

Ответы (2)

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

Ваш сценарий будет:

OP_PUSH33 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 OP_CHECKSIG

или

210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac.

Тогда ваша программа свидетелей становится witprog = sha256(script)или1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262

Затем вы кодируете bech32, и вы получаетеbc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3

Кроме того, код операции CHECKSIG требует два параметра.

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

Это OP_PUSH33совсем не было очевидно для меня, когда я читал en.bitcoin.it/wiki/Script . Спасибо!

Прежде всего, что вы пытаетесь сделать? Зачем вам нужен адрес P2WSH?

Адрес P2WSH (и более ранние адреса P2SH) отправляет монеты скрипту , который требует выполнения этого скрипта для декодирования. Скрипт формы <key> CHECKSIGрасточительный - вместо этого вы должны использовать P2WPKH. Как правило, вы используете P2WSH, когда у вас есть более сложные требования к расходам, чем один ключ. Чаще всего это происходит, когда вам нужна мультиподпись (несколько устройств или людей должны подписывать расходы).

Теперь все это выходит за рамки BIP173, который определяет только то, как кодировать выходные данные segwit в удобочитаемые строки и обратно.

Выходные данные segwit — это выходные данные, чей scriptPubKey начинается с OP_0, OP_1, ..., OP_16, после чего следует push от 2 до 40 байтов. Вот и все, и BIP173 может кодировать любой из них.

Теперь, после активации BIP141 в Биткойне, небольшое подмножество выходов segwit получило значение:

  • OP_0 + 20-байтовая отправка RIPEMD160(SHA256(pubkey)) называется P2WPKH для этого открытого ключа.
  • OP_0 + 32-байтовая отправка SHA256 (скрипт) называется P2WSH для этого скрипта.

Все остальные виды segwit-выходов сейчас бессмысленны (нестандартны и доступны любому), но это может измениться в будущем. Однако все они могут быть закодированы в Bech32 с использованием BIP173. Ему все равно, каков контекст или значение; он просто кодирует номер версии (код операции OP_n в начале) и байты данных (то, что передается впоследствии).

Возможно, ваше замешательство связано с тем, что тестовые векторы BIP173 используют в своих примерах «ключ + OP_CHECKSIG». Это был простой способ построения воспроизводимых примеров. Они не являются репрезентативными для того, как это на самом деле использовать.

Я совершенно упустил из виду, что «ключ + OP_CHECKSIG» сам по себе бессмысленен. Что я хотел сделать, так это добавить тесты, чтобы убедиться, что моя реализация была правильной: я добавил эти тесты сейчас! (См.: github.com/Kolibri-POS/bech32/blob/master/test/… )