Hi Ben, Thanks for the feedback.
> - Coordinator adds its own inputs, you still get your outputs but > effectively paid fees for no privacy gain What will be the incentive for a coordinator to add its inputs in coinjoin? Is this possible without ALL|ANYONECANPAY as well? Even if there is an incentive its unlikely to work in joinstr as there is no centralized coordinator. Multiple common relays are used to coordinate a coinjoin round. > - The inputs added could be paying at a lower fee rate than expected, > causing the tx to take longer than what you paid for > - Different input types or amount are added so you no longer have the same > uniformity across the inputs > This is the code in ln-vortex that verifies the psbt on the client side if > you are curious > > https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scala/com/lnvortex/client/VortexClient.scala#L616 These 2 are important things and could be managed with client side validation by keeping min-max amounts for inputs in a round and disallow different types of inputs. Thanks for sharing the code that validates PSBT. Joinstr will also use NIP38/48 channels for coinjoin rounds so that only participants in a coinjoin round are aware of details. /dev/fd0 floppy disk guy Sent with Proton Mail secure email. ------- Original Message ------- On Tuesday, May 23rd, 2023 at 4:21 AM, Ben Carman <benthecar...@live.com> wrote: > The problem with using ALL|ANYONECANPAY is that you cannot verify beforehand > that the other inputs are the inputs you want added to the transaction. > > Some examples of bad things that could happen: > > > - Coordinator adds its own inputs, you still get your outputs but > effectively paid fees for no privacy gain > - The inputs added could be paying at a lower fee rate than expected, > causing the tx to take longer than what you paid for > - Different input types or amount are added so you no longer have the same > uniformity across the inputs > - (if you care) An input from a sanctioned address is added, causing you to > get "tainted" coins. > > > This is the code in ln-vortex that verifies the psbt on the client side if > you are curious > > https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scala/com/lnvortex/client/VortexClient.scala#L616 > > > Best, > > benthecarman > > > > From: bitcoin-dev <bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf > of alicexbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> > Sent: Monday, May 22, 2023 7:51 AM > To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> > Subject: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY > > Hi Bitcoin Developers, > > I recently experimented with different sighash flags, PSBTs and realized > ALL|ANYONECANPAY could be used to reduce some steps in coinjoin. > > Steps: > > - Register outputs. > - One user creates a signed PSBT with 1 input, all registered outputs and > ALL|ANYONECANPAY sighash flag. Other participants keep adding their inputs to > PSBT. > - Finalize and broadcast the transaction. > > Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297 > > Tx: > https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b623471fcf8e073c87c1179c492 > > I plan to use this in joinstr if there are no major drawbacks and it can even > be implemented by other coinjoin implementations. > > /dev/fd0 > floppy disk guy > > Sent with Proton Mail secure email. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
