Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-19 Thread Jonas Nick via bitcoin-dev
> [...] we can use 2-party ECDSA to create 2-of-2 multisignature addresses that > look the same as regular single-signature addresses[2]. Even the old-style > p2pkh addresses starting with 1 can be CoinSwap addresses. Probably worth considering that p2pkh, p2wpkh and p2sh are vulnerable to the

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 10/06/2020 11:58, ZmnSCPxj wrote: > Good morning Chris, > >>> Let me propose an alternative: swap-on-receive+swap-on-change. >> >> That's an interesting point, thanks for the thought. This scheme might >> not be appropriate for every threat model and use case. >> For example,

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread Chris Belcher via bitcoin-dev
Hello Lee, Thanks for the review. On 10/06/2020 01:43, Mr. Lee Chiffre wrote: > >> >> === Combining multi-transaction with routing === >> >> Routing and multi-transaction must be combined to get both benefits. If >> Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is >>

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris, > > Let me propose an alternative: swap-on-receive+swap-on-change. > > That's an interesting point, thanks for the thought. This scheme might > not be appropriate for every threat model and use case. > For example, if someone wants to use bitcoin just as a foreign currency >

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread Chris Belcher via bitcoin-dev
Good morning ZmnSCPxj, On 06/06/2020 02:40, ZmnSCPxj wrote: > Good morning Chris, > >> I think I'm having trouble understanding this, does it work like this: >> >> Say we're in the 2-party coinswap case (Alice and Bob) >> >> We have Alice's funding transaction: >> Alice UTXO ---> 2of2 multisig

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Mr. Lee, > > === Combining multi-transaction with routing === > > Routing and multi-transaction must be combined to get both benefits. If > > Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is > > easy with this configuration: > > > > Alice > >

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-09 Thread Mr. Lee Chiffre via bitcoin-dev
> > === Combining multi-transaction with routing === > > Routing and multi-transaction must be combined to get both benefits. If > Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is > easy with this configuration: > > Alice > (6 BTC) (8 BTC) (1 BTC) >

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-09 Thread Mr. Lee Chiffre via bitcoin-dev
> Coinjoin on Monero can be > compared to ring signatures in Monero from the view of using decoys to > help conceal the source. From this proposal is this to say that > transactions will be at least 12 times larger in size to achieve the > property of privacy that bitcoin is currently missing? >

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning a third time Chris, Now unrelated to the funding order, but one of the reasons why timeliness is desirable for CoinSwap is that if possible, we want to ensure that sends from a user wallet are not correlatable with receives into that wallet. Thus, there is the strong suggestion

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning again Chris, I am uncertain if you are aware, but some years ago somebody claimed that 2p-ECDSA could use Scriptless Script as well over on lightning-dev. * https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf *

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris, > I think I'm having trouble understanding this, does it work like this: > > Say we're in the 2-party coinswap case (Alice and Bob) > > We have Alice's funding transaction: > Alice UTXO ---> 2of2 multisig (Alice+Bob) > > And we have the regular contract transaction > 2of2

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-05 Thread Chris Belcher via bitcoin-dev
Good day ZmnSCPxj, >>> But S6 has the mild advantage that all the funding transactions paying to >>> 2-of-2s can appear on the same block, whereas chaining swaps will have a >>> particular order of when the transactions appear onchain, which might be >>> used to derive the order of swaps. >>

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-04 Thread ZmnSCPxj via bitcoin-dev
Good morning yet again Chris, > > For the avoidance of theft, it is probably better for Bob to wait for > > Alice-side funding tx to confirm, probably deeply because reorgs suck. I realized that the *other* improvement I proposed in the [CoinSwapCS

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris again, > For the avoidance of theft, it is probably better for Bob to wait for > Alice-side funding tx to confirm, probably deeply because reorgs suck. Over in Lightning-land, we have a concept called "irrevocably committed". This is a state where a newly-created contract

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris, > > Good morning Ruben and Chris, > > > I am not in fact convinced that PayJoin-with-CoinSwap adds that much > > privacy. > > These transactions: > > > > +---+ +---+ > > Alice ---| |--| |--- Bob > > Alice ---| | | | > > Bob ---| | +---+

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-02 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 31/05/2020 03:30, ZmnSCPxj via bitcoin-dev wrote: > Good morning Ruben and Chris, > I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much > privacy. > > These transactions: > > +---+ +---+ > Alice ---| |--| |--- Bob > Alice ---|

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-01 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >If Alice is paying to a non-SAS aware payee Yeah, I agree that this use case is not possible without a third transaction (preferably from the timelocked side, in the case of SAS). My point was merely that you can swap and simultaneously merge some of your outputs into the post-swap

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-31 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, > > That assumes there will be a second transaction. With SAS I believe we can > avoid that, and make it look like this: > >              +---+ >     Alice ---|   |--- Bob >     Alice ---|   | >       Bob ---|   | >              +---+ If Alice is paying to a non-SAS aware

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-31 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >Just to be clear, you mean we can use the MuSig key-combination protocol for the non-timelocked SAS output, but (of course) not the signing protocol which is inherently Schnorr. Then knowledge of both of the original private keys is enough to derive the single combined private key.

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-30 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben and Chris, > >For a much greater anonymity set we can use 2-party ECDSA to create 2-of-2 > >multisignature addresses that look the same as regular single-signature > >addresses > > This may perhaps be counter-intuitive, but SAS doesn't actually require > multisig for one of

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-30 Thread Ruben Somsen via bitcoin-dev
Hey Chris, Excellent write-up. I learned a few new things while reading this (particularly how to overcome the heuristics for address reuse and address types), so thank you for that. I have a few thoughts about how what you wrote relates to Succinct Atomic Swaps (SAS)[0]. Perhaps it's useful.

[bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-25 Thread Chris Belcher via bitcoin-dev
=== Abstract === Imagine a future where a user Alice has bitcoins and wants to send them with maximal privacy, so she creates a special kind of transaction. For anyone looking at the blockchain her transaction appears completely normal with her coins seemingly going from address A to address B.