* [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY @ 2023-05-22 12:51 alicexbt 2023-05-22 22:51 ` Ben Carman 0 siblings, 1 reply; 5+ messages in thread From: alicexbt @ 2023-05-22 12:51 UTC (permalink / raw) To: Bitcoin Protocol Discussion 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY 2023-05-22 12:51 [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY alicexbt @ 2023-05-22 22:51 ` Ben Carman 2023-05-23 12:17 ` Lucas Ontivero 2023-05-23 12:34 ` alicexbt 0 siblings, 2 replies; 5+ messages in thread From: Ben Carman @ 2023-05-22 22:51 UTC (permalink / raw) To: alicexbt, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2217 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 5474 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY 2023-05-22 22:51 ` Ben Carman @ 2023-05-23 12:17 ` Lucas Ontivero 2023-05-23 12:48 ` alicexbt 2023-05-23 12:34 ` alicexbt 1 sibling, 1 reply; 5+ messages in thread From: Lucas Ontivero @ 2023-05-23 12:17 UTC (permalink / raw) To: Ben Carman, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3186 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 6376 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY 2023-05-23 12:17 ` Lucas Ontivero @ 2023-05-23 12:48 ` alicexbt 0 siblings, 0 replies; 5+ messages in thread From: alicexbt @ 2023-05-23 12:48 UTC (permalink / raw) To: Lucas Ontivero; +Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY 2023-05-22 22:51 ` Ben Carman 2023-05-23 12:17 ` Lucas Ontivero @ 2023-05-23 12:34 ` alicexbt 1 sibling, 0 replies; 5+ messages in thread From: alicexbt @ 2023-05-23 12:34 UTC (permalink / raw) To: Ben Carman; +Cc: Bitcoin Protocol Discussion 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 <benthecarman@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-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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-05-23 12:48 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-05-22 12:51 [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY alicexbt 2023-05-22 22:51 ` Ben Carman 2023-05-23 12:17 ` Lucas Ontivero 2023-05-23 12:48 ` alicexbt 2023-05-23 12:34 ` alicexbt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox