[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY
From:       alicexbt via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date:       2023-05-23 12:48:02
Message-ID: oLOjKr_MJ2WHkg0KSM5sw5B9RQNFDWpM3RHjea_Q_lRM3rBzwyRELllZzc2hxuGjFTkykJDAP1p-p3QbXTqYMl3U_EnuDxq_3a5ZfcB7aPw= () protonmail ! com
[Download RAW message or body]

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 <lucasontivero@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-bounces@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


[prev in list] [next in list] [prev in thread] [next in thread]