Published on: 2019-01-30T20:58:03+00:00
The conversation revolves around the potential attack on a transaction template and the weaknesses identified in the proposed protocol. The sender suggests that refusing to sign the final transaction can still propagate the template transaction, but the real attack would be if the sender double-spends it before propagation. The receiver acknowledges the weaknesses and agrees that there may not be a better solution. They also understand that implementers unable to integrate signing and UTXO validation are unlikely to implement this feature.Another discussion focuses on the issues faced by a "PayJoin-only" merchant who repeatedly uses a single UTXO. This could lead to an imbalance of funds violating UIH2. To avoid this, it is suggested to have a mix of PayJoin and non-PayJoin transactions. The concept of Bustapay is introduced, which allows for PayJoin transactions with a single UTXO. However, repeated use of the same UTXO can still suggest a naive approach. A heuristic is proposed to randomly flip coins for each UTXO owned to determine when to use PayJoin or not, although no formal analysis has been conducted.James MacWhyte expresses concerns about the complexity of the Bustapay spec and questions the effectiveness of the anti-spy feature. He suggests simplifying the protocol by dropping the signing requirement in the first step. However, he acknowledges the transaction malleability issues that may arise. MacWhyte concludes that the only viable way to use Bustapay with increased privacy would be to pay the first part of the invoice in lightning and then pay the rest with Bustapay, but admits that this approach has too many moving parts and implementation difficulties.ZmnSCPxj proposes solutions to address the UIH2 issue, suggesting standard coin selection algorithms and the inclusion of contributed inputs. AdamISZ raises concerns about mismatched input sizes and the concentration of funds in a single UTXO. Belcher suggests having a mix of PayJoin and non-PayJoin transactions to avoid violating UIH2.The conversation also discusses the steganographic hiding of transaction ownership and the adoption of the PayJoin protocol. Members debate the practicality and complexity of the protocol, as well as the need for versioning and inclusion of PSBT/BIP174. The importance of explicit transaction details like version and locktime is also debated.The implementation of Bustapay is discussed, including its integration into BtcPayServer and the need for a standardized format for moving UTXOs between wallets. Concerns are raised about wallets violating standards and the need for uniformity in Bitcoin transactions.Ryan Havar acknowledges mistakes in his recent BIP 0079 proposal and agrees with Adam Gibson's opinion on steganographic hiding of transaction inputs. He suggests better support for moving UTXOs between wallets through a standardized format. Adam emphasizes the need for consensus on protocols, versioning, and the inclusion of PSBT/BIP174. He suggests avoiding unnecessary inputs and making the payjoin transaction appear as an ordinary payment. Adam also highlights the value of being explicit about simple things like transaction version and locktime.In conclusion, the discussions revolve around the potential attacks, weaknesses, and proposed solutions in the Bustapay protocol. There are debates on issues such as the concentration of funds, UIH2, steganographic hiding, standardization, and protocol versioning. The importance of simplifying the process, ensuring privacy, and protecting both senders and receivers is emphasized.Ryan and Adam Gibson discussed the standardization of PayJoin as a transaction that breaks the assumption of common ownership of transaction inputs. They talked about various aspects such as protocol versioning, using PSBT/BIP174, version/locktime, and avoiding non-payment "Unnecessary Input Heuristic. "The proposal, known as Bustapay, aims to address fungibility concerns and blockchain analysis by creating indistinguishable Bitcoin transactions. The sender creates a fully valid, signed "template transaction" and gives it to the receiver through an HTTP POST request. The receiver adds their own input and increases the output that pays themselves by the contributed input amount. The partial transaction is then sent back to the sender to sign and propagated on the Bitcoin network by the receiver.Implementing Bustapay payments requires receivers to be aware of implementation notes, including checking if the transaction is suitable for the mempool with testmempoolaccept in Bitcoin Core 0.17. Sending applications should validate the HTTP response to ensure no unexpected changes have been made to the transaction.A proposal has been suggested to standardize the Bustapay protocol, which allows for hiding transaction information and increasing privacy. Steganographic hiding is considered worth pursuing, as Joinmarket and Samourai have already begun implementing the protocol. The aim is to create a cross-wallet standard that can be included in projects like BTCPayServer.
Updated on: 2023-08-01T23:47:19.394119+00:00