Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-06-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Dmitry, > I made a version of the TLA+ spec according to the suggested variant, > as I understood it from your description. This version is in > the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1] > > If I understood and specified your variant correctly, there is a >

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-06-03 Thread Dmitry Petukhov via bitcoin-dev
I made a version of the TLA+ spec according to the suggested variant, as I understood it from your description. This version is in the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1] If I understood and specified your variant correctly, there is a deadlock possible after step 9, if Bob

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-15 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >The proper response here is that Bob should broadcast success tx before the refund tx #1 becomes valid. That's right. And even if Bob neglects to do that, it still won't cause chaos for Alice as long as she chooses the path for refund tx #2. >at least part of the fund must be lost

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-14 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, > Hi ZmnSCPxj, > > >on completion of the protocol, if Bob lets the refund tx#1 become valid > >(i.e. does not spend the BTC txo) then Alice can broadcast it, putting both > >their funds into chaos > > You forget, refund tx #1 has a script (which btw won't be visible with >

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-13 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >on completion of the protocol, if Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) then Alice can broadcast it, putting both their funds into chaos You forget, refund tx #1 has a script (which btw won't be visible with taproot): "Alice & Bob OR Alice in +1

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, > Hi ZmnSCPxj, > > >potentially both Alice and Bob know all the secrets on the LTC side and end > >up competing over it > > That's exactly right. > > >Bob can thus give a copy of the revoke tx with signature directly to its > >favorite miner, forcing Alice to take 3

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-13 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >potentially both Alice and Bob know all the secrets on the LTC side and end up competing over it That's exactly right. >Bob can thus give a copy of the revoke tx with signature directly to its favorite miner, forcing Alice to take 3 transactions Note that the timelock on the

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-13 Thread Ruben Somsen via bitcoin-dev
Hi Chris, Thanks for taking a look :) >it also improves privacy because the coins could stay unspend for a long time, potentially indefinitely Excellent point. The pre-swap setup transactions would still be subject to timing/amount analysis, but it's clearly a lot less problematic than the

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, > >If the shortened refund transaction exists (labeled "refund transaction #1" > >in the SVG) then the same issue still occurs  > > Yes, but there is one crucial difference: at that point in the protocol (Bob > has the success transaction and then stops cooperating) Alice

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Chris Belcher via bitcoin-dev
Hello list, This proposal is very cool. It is very useful to have a coinswap scheme requiring only two transactions. As well as improving the scalability of the system by saving block space, it also improves privacy because the coins could stay unspend for a long time, potentially indefinitely.

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >If the shortened refund transaction exists (labeled "refund transaction #1" in the SVG) then the same issue still occurs Yes, but there is one crucial difference: at that point in the protocol (Bob has the success transaction and then stops cooperating) Alice and Bob both had the

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, > >Would this not work? > > I considered and rejected that model for the following reason: there are > moments where both Alice and Bob can claim the BTC. If they both attempt to > do so, it also reveals both secrets, causing the LTC to also be claimable by > both parties.

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Ruben Somsen via bitcoin-dev
Hi Lloyd, >In my opinion, this protocol is theoretical breakthrough as well as a practical protocol. Well done! Thanks for the kind praise, and for providing a summary of what you think makes the protocol useful. Your different perspective is undoubtedly useful for others who are trying to

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, >Would this not work? I considered and rejected that model for the following reason: there are moments where both Alice and Bob can claim the BTC. If they both attempt to do so, it also reveals both secrets, causing the LTC to also be claimable by both parties. This chaotic scenario

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Lloyd Fournier via bitcoin-dev
A quick correction to my post: > > Here's where the truly novel part comes in. Ruben solves this by extending > the standard *TLC contract: > 1. Bob redeem with secret > 2. Alice refund after T1 > 3. Bob redeem without secret after T2 > > This is actually: 1. Bob redeem with redeem secret 2.

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Lloyd Fournier via bitcoin-dev
Ruben, In my opinion, this protocol is theoretical breakthrough as well as a practical protocol. Well done! I want to try and distil the core abstract ideas here as they appear to me. From my view, the protocol is a combination of two existing ideas and one new one: 1. In atomic swaps you can

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-11 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, > Hi ZmnSCPxj, > > Thanks for your feedback :) > > > CoinSwap for privacy is practically a "cross" chain atomic swap with the > > same chain and token for both sides of the swap > > I agree, I didn't mean to imply that was new, only that this protocol > makes it more

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-11 Thread Ruben Somsen via bitcoin-dev
Hi ZmnSCPxj, Thanks for your feedback :) >CoinSwap for privacy is practically a "cross" chain atomic swap with the same >chain and token for both sides of the swap I agree, I didn't mean to imply that was new, only that this protocol makes it more efficient. >"Instead, Bob simply hands

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-11 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap, see also this set of ideas: https://github.com/AdamISZ/CoinSwapCS/issues/53 "Instead, Bob simply hands secretBob to Alice" is basically the same as