Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D4509C002A for ; Tue, 23 May 2023 12:17:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B6ED483CBB for ; Tue, 23 May 2023 12:17:43 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B6ED483CBB Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=Ja/ohoOJ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV7EowMA_NNU for ; Tue, 23 May 2023 12:17:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9E77883C99 Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9E77883C99 for ; Tue, 23 May 2023 12:17:36 +0000 (UTC) Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-623f24b7ec9so32963836d6.3 for ; Tue, 23 May 2023 05:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684844254; x=1687436254; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lptscLZCpLJjkJwtmC6g7VyNqITSKtrCiYCrw0KGH0I=; b=Ja/ohoOJKCNaVR0IUaLyaLanbR2uB5IYhK8C/c4bdbuBJwqtnnXJ4RvLfb0Qx7JkEH y+v55V9H+6hXhcTf8EDltsrPAIIOzUsDAxlXkL/3A9EUt/ZfJpsFvaKGJKwnoeX9nhkZ TOIuZq6if7TvhmJcroUvO/vvViH24GYEoMXDELZk/B1XTZfCe52jKejDs2AzXPomKUHl HPKZB9PGW1vIbihS+AUXHv4Bgw4fZJzSZL5miqo8fYwdpT9hcV8OyWhsk/yrB4C8Yu/a 2e+y/R5QrAaLhgZRaDfxA/l+oqSS/nesObnRlR/uU6esYWwO+bS0gMIecm4Y/ywKJ+Gx U8cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684844254; x=1687436254; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lptscLZCpLJjkJwtmC6g7VyNqITSKtrCiYCrw0KGH0I=; b=a0QUJcstrsghd958/I/9J/IPNR0vRNCKz26GmMBXZoZXRL2M4JW1NlFnQIb8/lc/+A fF8J/TgXU36HEgUAfdygGcWGCekMttVrYyyEGgbJr4dZmivAAw9sg8R1dxod2RBiW1Lt uD21QPI+NdgWH7jILv/u8OjLbDyGK6rqyGETFbpEf6soR0lVDbs87YKEQeSoRRXsH70l KKkIN/V8m/Nz1fU89G00EtpFzMz5ZQnVDjuqEsxLnyoNcQzaB+bwxg89WzK6wnw+Mim/ 9B7ZUnvihV12z9IDaVmIb7HCXod61ma33ksURDOJNr9zbR4/jiIE0nM7sMH5iwC/Hd41 OuGg== X-Gm-Message-State: AC+VfDwY9vPjzAK/3tn4wxzXb/2Qdh0LEgwBwi3kVwh7yGQXd8x62FCB ptNGQKKFfH+7Pnpb1Ztox9XeygJ/NiVLDBQT0DTMHsO1ulc= X-Google-Smtp-Source: ACHHUZ6QLw9FIYXRP4J+6RJZKdZQFHxD9M7mDPVrT8TIQImUyB59oOJwnLmzH+Fpod+UbSw3qZ8ZFiyc3ZeghlEKJQQ= X-Received: by 2002:a05:6214:20a5:b0:621:6bcb:e49 with SMTP id 5-20020a05621420a500b006216bcb0e49mr21636901qvd.0.1684844254411; Tue, 23 May 2023 05:17:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Ontivero Date: Tue, 23 May 2023 09:17:23 -0300 Message-ID: To: Ben Carman , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000004941f105fc5b5f10" X-Mailman-Approved-At: Tue, 23 May 2023 13:04:22 +0000 Subject: Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2023 12:17:45 -0000 --0000000000004941f105fc5b5f10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM 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 i= f > 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 on > behalf of alicexbt via bitcoin-dev > *Sent:* Monday, May 22, 2023 7:51 AM > *To:* Bitcoin Protocol Discussion > *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 input= s > to PSBT. > - Finalize and broadcast the transaction. > > Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297 > > Tx: > https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b62= 3471fcf8e073c87c1179c492 > > 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 > --0000000000004941f105fc5b5f10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

In some coinjoin implementa= tions 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 pro= posal 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 scen= arios where it is not really important).

Best

- Lucas


On Mon, May 22, 2023 at 7:5= 3=E2=80=AFPM Ben Carman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:
The problem with using ALL|ANYONECANPAY is that you cannot verify beforehan= d 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 privac= y gain
  • The in= puts added could be paying at a lower fee rate than expected, causing the t= x 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 san= ctioned 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/VortexClien= t.scala#L616


Best,

benthecarman

From: b= itcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org>= ; on behalf of alicexbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundati= on.org>
Sent: Monday, May 22, 2023 7:51 AM
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundatio= n.org>
Subject: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANP= AY
=C2=A0
Hi Bitcoin Developers,

I recently experimented with different sighash flags, PSBTs and realized AL= L|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 A= LL|ANYONECANPAY sighash flag. Other participants keep adding their inputs t= o PSBT.
- Finalize and broadcast the transaction.

Proof of Concept (Aice and Bob):=C2=A0https://gitlab.com/-/snippets/2542297
Tx: https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b6234= 71fcf8e073c87c1179c492

I plan to use this in joinstr if there are no major drawbacks and it can ev= en 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/bitcoi= n-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000004941f105fc5b5f10--