Published on: 2023-05-23T12:48:02+00:00
In a recent Bitcoin Protocol Discussion post, a user named AliceXBt suggested using the ALL|ANYONECANPAY sighash flag in CoinJoin to streamline the process. This approach involves registering outputs and creating a signed PSBT with one input, all registered outputs, and the sighash flag. Other participants would then add their inputs to the PSBT before finalizing and broadcasting the transaction. While this method could reduce some steps in CoinJoin, there are concerns about security.The main issues with using the ALL|ANYONECANPAY flag include the possibility of the coordinator adding its own inputs, which could compromise privacy benefits. There is also a risk of inputs from sanctioned addresses being included. However, these issues can be addressed through client-side validation and by disallowing certain types of inputs. Joinstr plans to use NIP38/48 channels for CoinJoin rounds to ensure that only participants are aware of the details.Another proposal in a Bitcoin Developers discussion group focused on the order in which inputs are registered in coinjoin implementations. It was suggested that registering inputs first could make denial of service (DoS) attacks more expensive. However, using the ALL|ANYONECANPAY flag may have drawbacks, such as the inability to verify beforehand if the other inputs are the desired ones or allowing inputs from sanctioned addresses. The ln-vortex code for verifying PSBT on the client side was provided as an example.A proof of concept was presented using ALL|ANYONECANPAY to reduce steps in coinjoin. One user created a signed PSBT with one input and all registered outputs, while other participants added their inputs to the PSBT before finalizing and broadcasting the transaction. The poster plans to implement this method in joinstr if there are no major drawbacks, and encourages others to adopt it for their coinjoin implementations.While the ALL|ANYONECANPAY sighash flag offers potential benefits in reducing steps in CoinJoin, there are risks to consider. The inability to verify beforehand if the desired inputs are included in the transaction can lead to unintended consequences, such as the coordinator adding its own inputs or a lack of uniformity due to different input types or amounts. However, the ln-vortex code provides client-side validation for PSBT, and a proof of concept has been shared to demonstrate the feasibility of using ALL|ANYONECANPAY. The sender plans to implement this approach in joinstr and invites others to do the same.
Updated on: 2023-08-02T09:30:57.541979+00:00