From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Date: Tue, 12 May 2020 15:05:57 +0000 [thread overview]
Message-ID: <Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
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. This chaotic scenario is a failure mode that did not seem acceptable to me. The revoke transaction was specifically added to mitigate that issue (invalidating any attempt of Bob to claim the coins and reveal his secret). That said, it doesn't particularly seem in either party's interest wait until a moment where two timelocks become valid, so maybe it is not quite as bad as I thought. However, it still means that the incompetence/malevolence of one party can lead to losses for both parties. I have my doubts a gain in privacy in the uncooperative case is worth that risk.
>
> Of course it also reverts the protocol to 3 transactions, instead of 2, but regardless, not having to watch the chain is probably more practical in many cases. As an aside, if both chains support timelocks then we can ensure that the more expensive chain only receives one transaction.
If the shortened refund transaction exists (labeled "refund transaction #1" in the SVG) then the same issue still occurs: after 1 day it is possible for either success or refund#1 to be broadcasted, leading to revelation of both secrets, leading to the same failure mode you described.
Without the refund#1 in your proposal, Bob refusing cooperation after Alice puts the BTC into lock for 3 days and 2 further onchain transactions (with the refund#2 transaction being relative-locked, meaning it cannot be used to CPFP the revoke transaction; my formulation allows any of the result transactions to be CPFP directly by their beneficiaries).
It seems to me that there is still an onlineness requirement in case Bob does not complete the protocol: once the revoke tx becomes valid an online Bob can cheat an offline Alice by broadcasting the revoke tx (which, if my understanding of the protocol is correct, the signatures are shared to both Alice and Bob).
So Alice needs to be online starting at 2 days to 3 days in order to ensure it reclaims it funds.
I have not seen the 2-tx variant video yet, as I prefer to read than listen, but I will also check it if I can find an opportunity.
Regardless, the overall protocol of using 3 clauses in the swap, and reusing the privkey as the payment secret demanded by the pointlocks, is still a significant innovation.
In the context of CoinSwap, a proposal is that a CoinSwap server would provide swapping service to incoming clients.
Using my counterproposal, the Bob position can be taken by the server and the Alice position taken by the client.
In this context, the L1 can be made reasonably close in the future and L2 far in the future, in which case Alice the client can be "weakly offline" most of the time until L2, and even in a protocol abort would be able to recover its funds.
If the protocol completes, the server Bob can claim its funds before L1, and (with knowledge of Alice[0]) can immediately put it in a new funding tx for a new incoming client before L1, which is a fine tradeoff for server Bob since presumably Bob is always online.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-05-12 15:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 15:29 Ruben Somsen
2020-05-11 16:45 ` ZmnSCPxj
2020-05-11 17:50 ` Ruben Somsen
2020-05-12 4:41 ` ZmnSCPxj
2020-06-03 9:04 ` Dmitry Petukhov
2020-06-03 14:36 ` ZmnSCPxj
2020-05-12 22:50 ` Chris Belcher
2020-05-12 6:10 ` Lloyd Fournier
2020-05-12 6:50 ` Lloyd Fournier
2020-05-12 11:30 ` Ruben Somsen
2020-05-12 11:34 ` Ruben Somsen
2020-05-12 15:05 ` ZmnSCPxj [this message]
2020-05-12 16:30 ` Ruben Somsen
2020-05-13 8:39 ` ZmnSCPxj
2020-05-13 9:57 ` Ruben Somsen
2020-05-13 9:58 ` Ruben Somsen
2020-05-13 11:39 ` ZmnSCPxj
2020-05-13 12:33 ` Ruben Somsen
2020-05-15 4:39 ` ZmnSCPxj
2020-05-15 19:47 ` Ruben Somsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rsomsen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox