public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ruben Somsen <rsomsen@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Date: Tue, 12 May 2020 13:30:38 +0200	[thread overview]
Message-ID: <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com> (raw)
In-Reply-To: <CAH5Bsr1paP8dmo_z6VoEHYvB_SpD4Piw91LeLJBMgFph7Qrtfg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

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 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 relative locktimes are used as often as absolute locktimes for
block-sniping-prevention and a decent Scriptless Script system, then all
protocol aborts should be doable with no information leaks

I see your point, interesting observation.

>A sidenote as well, that if Alice typically uses an HD wallet, the UTXO on
the LTC side would not be in that HD, and if Alice wants to cold-store the
LTC, it should move the money as well into an HD pubkey.

Agreed, I had that listed as one of the disadvantages: "Access to money is
contingent on remembering secrets (backup complexity)"

Cheers,
Ruben


On Tue, May 12, 2020 at 8:50 AM Lloyd Fournier <lloyd.fourn@gmail•com>
wrote:

> 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. Alice refund after T1 with refund secret
> 3. Bob redeem without secret after T2
>
> The fact that Alice reveals a secret when she refunds is crucial.
>
> LL
>

[-- Attachment #2: Type: text/html, Size: 3064 bytes --]

  reply	other threads:[~2020-05-12 11:30 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 [this message]
2020-05-12 11:34       ` Ruben Somsen
2020-05-12 15:05       ` ZmnSCPxj
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=CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com \
    --to=rsomsen@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /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