Отправка платежей с HD кошелька

Я нашел эти два вопроса очень полезными для понимания HD-кошельков.

1) Как иерархические детерминированные кошельки работают с точки зрения транзакций?

2) несколько вопросов о том, как работает HD-кошелек

Однако мне до сих пор не ясно, как отправка платежей будет работать в случае с HD-кошельком. Предположим следующий сценарий:

  • производный публичный ключ #15 получил 1 BTC за одну транзакцию
  • производный открытый ключ #20 получил 2 BTC за одну транзакцию

Теперь, когда я хочу отправить 2,5 BTC на какой-то адрес, как это сделать? Нужно ли мне делать две отдельные транзакции?

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

Ответы (1)

Кошельки HD не являются чем-то особенным, когда дело доходит до транзакций. Транзакциям все равно, были ли задействованные ключи получены детерминировано или сгенерированы случайным образом.

Подумайте о кошельке, разделенном на две части: первая часть (которую мы назовем обработчиком ключей) обрабатывает пары закрытый/открытый ключи и создает цифровые подписи. Вторая часть (которую мы будем называть обработчиком транзакций) обрабатывает получение и создание транзакций. Предположим, первая часть имеет некоторые функции getnewpubkey(возвращает новый адрес) и signdatawithpubkey(получает открытый ключ и некоторый фрагмент данных для подписи, возвращает цифровую подпись).

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


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

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

Обратите внимание, что обработчик транзакции, который фактически получает и создает транзакцию, не знает и не заботится о том, как были получены ключи. Вы могли бы использовать обработчик ключей, который генерирует ключи случайным образом или детерминировано; это не имеет значения.


что должен сделать пользователь. Таким образом, был бы признателен, если бы кто-нибудь мог объяснить вышеизложенное, выделив, например, некоторые шаги в биткойн-ядре.

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

очень тщательно. большое спасибо! в качестве дополнительного вопроса (и, надеюсь, последнего вопроса, прежде чем я буду копать глубже): если мы получим целую кучу незащищенных pubkeys из xpubи раздадим другим людям в качестве способа получения средств. Когда мне нужно потратить из этих адресов, нам нужно вывести privkeyдля них соответствующие s и подписать транзакции, чего мы изначально не делали, верно? «мы», я предполагаю, что это может быть сделано программным обеспечением кошелька.
Это зависит от программного обеспечения кошелька. Некоторое программное обеспечение также извлекает закрытые ключи и сохраняет их. Некоторое программное обеспечение, а также те, которые поддерживают режим только просмотра с помощью xpubs, будут хранить пути деривации. В этом типе раздельной настройки, когда вы создаете транзакцию, программное обеспечение выдает вам неподписанную транзакцию, часто с некоторыми дополнительными данными, которые на самом деле не являются частью самой транзакции, но используются программным обеспечением, которое имеет так, чтобы это программное обеспечение xprvподписавшего может подписать транзакцию и дать вам что-то для трансляции в сеть.
еще раз спасибо. есть ли у вас какие-либо подробные материалы для чтения или ресурсы с точки зрения шагов по настройке separated paradigmописанного вами программного API? Я понимаю, что это ответы на программное обеспечение. Меня в основном интересуют программы с открытым исходным кодом, такие как биткойн-ядро, электрум, оружейная палата и т. д. Так что все, что основано на любом из них, было бы очень полезно. Я тоже проведу небольшое исследование и задам еще один вопрос о SE, если не найду. :)
кстати, я учусь настраивать какую-то платежную систему, и чувствую, что то, что вы описали, это именно то, что мне нужно. вот почему я хотел бы узнать по коду, какие функции API я могу использовать.