Author: Jeremy Spilman 2014-01-13 09:18:39
Published on: 2014-01-13T09:18:39+00:00
A Bitcoin payment of 1BTC was made to a stealth address on TestNet, with the transaction ID df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c. The code used to generate this transaction is available on GitHub, with one minor change from the protocol discussed. After importing the private key for the TxIn to that transaction, two rows appear in the Transaction List of Bitcoin-QT, both saying 'Sent to' with a blank address. One row has 1BTC amount and is the 2-of-2 stealth multisig, while the other has 0BTC amount and is the OP_RETURN. The author queries whether the 0BTC OP_RETURN transactions should be hidden from the Transaction List as 'Transaction Details' truncates the after OP_RETURN anyway, making it not particularly useful for seeing what data you embedded. The author suggests defining the PaymentRequest extension, updating Gavin's PHP to generate PaymentRequests for stealth payments, getting Bitcoin-QT loading the PaymentRequest and generating transactions from those PaymentRequests, and writing an agent to detect incoming stealth payments. However, the author notes that there would still be meaningless rows in the payer's Transaction List without additional work.The author also raises questions about how to receive P2P stealth payments in Bitcoin-QT as an end-user and how to keep 'd2'/'Q2' unencrypted so it's available for doing necessary tests but has no chance of ever being used as a standalone private key. Finally, the author questions how to fully verify the transaction when 'd1'/Q1 is available decrypted and how to indicate if that has or has not been done yet.
Updated on: 2023-06-07T23:59:56.673903+00:00