Как кошелек использует неподтвержденные выходы в качестве входов после неподтвержденных транзакций?

У меня есть 10 btc на адресе А.

Используя необработанную транзакцию, я отправляю 5 биткойнов из A в B и устанавливаю адрес для сдачи как сам A. Теперь, поскольку транзакция от A до B не подтверждена, я не могу потратить оставшиеся 5 биткойнов.

Но я видел, что кошелек QT может это делать. Бывший:

У меня есть 10 биткойнов на адресе А. Я отправляю 5 биткойнов на адрес Б. Кошелек создает новый адрес С и устанавливает его в качестве адреса для сдачи. Затем я пытаюсь использовать 5 биткойнов в кошельке, и это работает. Это позволяет мне отправлять с адреса C.

1) Использует ли кошелек неподтвержденные выходы в качестве входов здесь?

2) Если да, то как это сделать и как это сделать с помощью необработанных транзакций?

3) Если нет, то что здесь происходит?

Ответы (4)

Использует ли кошелек неподтвержденные выходы в качестве входов здесь?

Да.

Если да, то как это делается

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

Для Bitcoin-Qt безопасно тратить неподтвержденные изменения, потому что он знает, что ввод действителен и будет подтвержден в какой-то момент (хотя, вероятно, медленно). Для Bitcoin-Qt было бы небезопасно тратить неподтвержденные входные данные, которые он сам не создавал, потому что они могут никогда не подтвердиться, что приведет к постоянному привязыванию средств. (Очень старые версии Биткойн допускали эту ошибку, но она была исправлена ​​после широко распространенных проблем.)

как я могу сделать это, используя необработанные транзакции?

Вы можете создать транзакцию в createrawtransactionобычном режиме, но вам нужно будет указать signrawtransactionдополнительную информацию о неподтвержденной транзакции во втором параметре.

createrawtransaction поддерживает использование неподтвержденных входных данных; см . пример gist.github.com/gavinandresen/3966071#file-twoofthree-sh-L42 .
@gavinandresen Глядя на это подробнее, мне кажется, что мы оба ошибаемся. В вашем примере createrawtransactionна самом деле не смотрит на предоставленный redeemScriptили scriptPubKeyAFAICT. createrawtransactionиспользует любые данные, которые вы ему даете, и даже не использует блочную базу данных. signrawtransactionнужен redeemScriptи scriptPubKeyдля неподтвержденных транзакций.

Похоже, что Bitcoin QT может ссылаться на свои собственные неподтвержденные транзакции, что довольно опасно. Учти это:

Первая транзакция (от A до B) может поступить в цепочку блоков после второй (C до ...) или вообще не поступить. В этом случае вторая транзакция не пройдет, потому что она недействительна до тех пор, пока не произойдет первая. Несмотря на то, что вторая транзакция существует в Bitcoin QT, она, вероятно, не будет отправлена ​​до тех пор, пока не пройдет первая.

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

«Первая транзакция (от A до B) может поступить в цепочку блоков после второй»... Я думаю, вам нужно уточнить это... вторая транзакция никогда не будет включена в блок, если только первая не будет в том же блоке. или более ранний блок
@RentFree Спасибо за разъяснения. Да, вторая транзакция на самом деле не попала бы «в» цепочку блоков, потому что без первой она была бы недействительной.

Биткойн-QT, рассматривающий сдачу как достойную трату, зависит от того, создал ли ее сам клиент. Создание транзакции с изменением createrawtransaction как неподтвержденным. Bu sendfrom нет.

Насколько я понимаю, технически первое подтверждение делается против вашей собственной копии блокчейна.

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

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

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