Author: James MacWhyte 2019-01-27 19:42:03
Published on: 2019-01-27T19:42:03+00:00
In a bitcoin-dev discussion, users are debating the standardization of a protocol that allows for steganographic hiding of transaction ownership. Some argue for the adoption of the PayJoin protocol, while others express concern over its impracticality and complexity. Members also discuss the need for protocol versioning and the inclusion of PSBT/BIP174 in the standardization process. There is debate over the utility of including information such as the transaction version and locktime in the protocol.Bustapay is a proposed method for making bitcoin transactions more fungible and avoiding the leakage of information through the assumption that all inputs of a transaction are signed by a single party. It proposes a simple, practical solution in the form of a payjoin transaction, which requires no changes to Bitcoin and creates transactions that are indistinguishable from normal ones. The sender creates a fully valid, signed transaction paying the receiver, known as the "template transaction", with all inputs using segwit and gives it to the receiver via HTTP POST. The receiver adds their own input, known as the "contributed input", and increases the output that pays themselves by the contributed input amount before returning the "partial transaction" back to the sender for signing. The sender then returns the partially signed coinjoin transaction to the receiver, who validates, re-signs, and propagates it on the Bitcoin network. The Bustapay payment method is a proposal for a simplified version of the CoinJoin proposal by Dr. Maxwell, with reduced scope inspired by a simplification of the "pay 2 endpoint" blog post by Blockstream. The process involves the receiver observing the finalized transaction on the bitcoin network and processing it like a normal payment once enough confirmations have been received. If the receiver does not see the finalized transaction after a timeout, the original "template transaction" will be propagated to ensure the payment happens and function as a strong anti-DoS mechanism. For anyone wanting to implement Bustapay payments, the notes for receivers include checking if a transaction is suitable for the mempool with testmempoolaccept in bitcoin core 0.17, ensuring all inputs are segwit, keeping a mapping of which utxos people have shown and which they revealed, and checking if the transaction was already sorted according to BIP69. The notes for sending applications include fully validating that no unexpected changes have been made to the transaction, and being aware that the original "template transaction" may be propagated at any time. It is important to note that a transaction can be checked for suitability for the mempool and tracking transactions by txid is precarious. Additionally, Bustapay could be abused by a malicious party to query if a deposit address has been used or not, so it is recommended to never accept a Bustapay transaction that pays an already used deposit address. Finally, the HTTP response must not be trusted, and it should be fully validated that no unexpected changes have been made to the transaction.
Updated on: 2023-06-13T14:24:45.918055+00:00