Hi Lucas, > In some coinjoin implementations inputs are registered first because in that > way, if the user fails or refuses to sign the transaction the input is banned > and denial of service is made a bit more expensive, in the sense that an > attacker needs more and more utxos to keep the attack going.
DoS attacks are even possible in later stages of a coinjoin round. Example: Double spend inputs after signing Inputs could be banned in second step if ALL|ANYONECANPAY sighash flag is used and outputs are registered initially. /dev/fd0 floppy disk guy Sent with Proton Mail secure email. ------- Original Message ------- On Tuesday, May 23rd, 2023 at 5:47 PM, Lucas Ontivero <lucasontiv...@gmail.com> wrote: > Hi all, > In some coinjoin implementations inputs are registered first because in that > way, if the user fails or refuses to sign the transaction the input is banned > and denial of service is made a bit more expensive, in the sense that an > attacker needs more and more utxos to keep the attack going. > > Your proposal can work if you find an alternative mechanism for mitigating > the DoS attacks or when DoS attacks are not a problem (I can imagine there > are scenarios where it is not really important). > Best > - Lucas > > > > On Mon, May 22, 2023 at 7:53 PM Ben Carman via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
