Author: Adam Gibson 2019-01-27 12:20:54
Published on: 2019-01-27T12:20:54+00:00
In a Bitcoin mailing list, Ryan Havar thanked Adam Gibson for pointing out some mistakes in his recent BIP 0079 proposal and stated that he agreed with Adam's opinion about possible steganographic hiding of transaction inputs. He suggested that better support was needed for moving UTXOs between wallets, which could be achieved by having a standardized format for (txid:vout:privatekey) with wallets showing it as "External UTXO" and preferentially spending it. Adam commented that creating a standard that a reasonable number of people could agree with would be the limiting factor to adoption of such protocols. Furthermore, he argued that protocol versioning and the possibility of more than one option should be taken into account, and that PSBT/BIP174 could be optional, but it shouldn't be excluded from the standardization process. Adam also suggested that the avoidance of non-payment "Unnecessary Input Heuristic" should be included in the BIP, and that the receiver's contributed input(s) should be chosen to avoid triggering the UIH2 heuristic where possible so that the final payjoin transaction is maximally plausible as an ordinary payment. Finally, he pointed out that avoiding UIH1 and UIH2 could prompt implementers to do this, and that being more explicit about simple things like transaction version and locktime could be valuable.Bustapay is a proposal for a simple and practical way to bust assumptions that causes fungibility concerns with Bitcoin transactions. It allows senders and receivers to benefit from creating indistinguishable Bitcoin transactions without changing the Bitcoin system. The specification has been intentionally kept as simple as possible to encourage adoption, but a "v2" specification will be created if widespread adoption occurs. Bustapay payments are made from a sender to a receiver in five steps. First, the sender creates a bitcoin transaction paying the receiver known as the "template transaction." Second, the sender gives the "template transaction" to the receiver, generally done as an HTTP POST. Third, the receiver processes the transaction and returns a partially signed coinjoin. Fourth, the receiver validates, re-signs, and propagates the transaction on the Bitcoin network. Finally, the receiver observes the finalized transaction on the Bitcoin network.One of the most powerful heuristic's employed by those whose goal is to undermine Bitcoin's fungibility has been to assume all inputs of a transaction are signed by a single party. Bustapay requires no changes to Bitcoin and creates Bitcoin transactions that are indistinguishable from normal ones. The receiver must add at least one input to the transaction, which is known as the "contributed input," and increase the output that pays himself by the contributed input amount.After adding inputs to the transaction, the receiver generally will want to adjust the output that pays himself by increasing it by the sum of the contributed input amounts (minus any fees he wants to contribute). However, the only strict requirement is that the receiver must never add or remove inputs, and must not ever decrease any output amount. It is strongly preferable that the receiver makes an effort to pick a contributed input of the same type as the other transaction inputs if possible. To prevent an attack where a receiver is continually sent variations of the same transaction to enumerate the receiver's utxo set, it is essential that the receiver always returns the same contributed inputs when it's seen the same inputs. 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:22:51.914718+00:00