alicexbt [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-23 🗒️ Summary of this message: Using ...
📅 Original date posted:2023-05-23
🗒️ Summary of this message: Using ALL|ANYONECANPAY in coinjoin can lead to added inputs with lower fees or different types, reducing privacy gain. Client-side validation can help manage this.
📝 Original message: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 at 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 at lists.linuxfoundation.org> on behalf of alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Monday, May 22, 2023 7:51 AM
> To: Bitcoin Protocol Discussion <bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
🗒️ Summary of this message: Using ALL|ANYONECANPAY in coinjoin can lead to added inputs with lower fees or different types, reducing privacy gain. Client-side validation can help manage this.
📝 Original message: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 at 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 at lists.linuxfoundation.org> on behalf of alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Monday, May 22, 2023 7:51 AM
> To: Bitcoin Protocol Discussion <bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev