Date: Tue, 23 May 2023 12:48:02 +0000
To: Lucas Ontivero <lucasontivero@gmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <oLOjKr_MJ2WHkg0KSM5sw5B9RQNFDWpM3RHjea_Q_lRM3rBzwyRELllZzc2hxuGjFTkykJDAP1p-p3QbXTqYMl3U_EnuDxq_3a5ZfcB7aPw=@protonmail.com>
In-Reply-To: <CALHvQn29S2T=ehqGD1vCJQQuC0aD6rjUUPsb+n80EBPgc_G4JA@mail.gmail.com>
References: <EWAXAmgFlZ8XQJOYO8VTH7Zj0tTAftwy-ylaGvf3Giealz1FFb97CbcxjP0q-Zu85XoAzOG0ivdYIKa_kG77ooHqBvCP7YOZOkb6yHmX75s=@protonmail.com>
 <SJ1P223MB0531D7D62140F0516A25897AA1439@SJ1P223MB0531.NAMP223.PROD.OUTLOOK.COM>
 <CALHvQn29S2T=ehqGD1vCJQQuC0aD6rjUUPsb+n80EBPgc_G4JA@mail.gmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY
Precedence: list

Hi Lucas,

> In some coinjoin implementations inputs are registered first because in t=
hat 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 tha=
t 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 u=
sed 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 t=
hat 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 tha=
t an attacker needs more and more utxos to keep the attack going.
>=20
> Your proposal can work if you find an alternative mechanism for mitigatin=
g the DoS attacks or when DoS attacks are not a problem (I can imagine ther=
e are scenarios where it is not really important).
> Best
> - Lucas
>=20
>=20
>=20
> On Mon, May 22, 2023 at 7:53=E2=80=AFPM Ben Carman via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> wrote:
>=20
> > The problem with using ALL|ANYONECANPAY is that you cannot verify befor=
ehand that the other inputs are the inputs you want added to the transactio=
n.
> >=20
> > Some examples of bad things that could happen:
> >=20
> >=20
> > -   Coordinator adds its own inputs, you still get your outputs but eff=
ectively 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.
> >    =20
> >=20
> > This is the code in ln-vortex that verifies the psbt on the client side=
 if you are curious
> >=20
> > https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scal=
a/com/lnvortex/client/VortexClient.scala#L616
> >=20
> >=20
> > Best,
> >=20
> > benthecarman
> >=20
> >=20
> >=20
> > From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> on be=
half 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
> >=20
> > Hi Bitcoin Developers,
> >=20
> > I recently experimented with different sighash flags, PSBTs and realize=
d ALL|ANYONECANPAY could be used to reduce some steps in coinjoin.
> >=20
> > Steps:
> >=20
> > - Register outputs.
> > - One user creates a signed PSBT with 1 input, all registered outputs a=
nd ALL|ANYONECANPAY sighash flag. Other participants keep adding their inpu=
ts to PSBT.
> > - Finalize and broadcast the transaction.
> >=20
> > Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297
> >=20
> > Tx: https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb=
0f2b623471fcf8e073c87c1179c492
> >=20
> > I plan to use this in joinstr if there are no major drawbacks and it ca=
n even be implemented by other coinjoin implementations.
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
> > Sent with Proton Mail secure email.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >=20
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev