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
>
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
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
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
>
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
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
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
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
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
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.
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
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.
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
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
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.
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
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
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
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
Works today with single signer ECDSA adaptor signatures[0], or with
Schnorr + MuSig.
Diagram here:
https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file-succinctatomicswap-svg
Advantages:
- Requires merely two on-chain transactions for successful completion,
as opposed to
20 matches
Mail list logo
