path: root/eb/bb322775651e8ffb7ba7da0b3fa30bfe3c30b6

Return-Path: <rsomsen@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 78F3BC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 12:33:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 6E8A5885DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 12:33:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 78YpXIg4feFn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 12:33:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com
 [209.85.218.65])
 by hemlock.osuosl.org (Postfix) with ESMTPS id E6ACF885CF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 12:33:42 +0000 (UTC)
Received: by mail-ej1-f65.google.com with SMTP id nv1so14056838ejb.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 May 2020 05:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=2oMGTeUhweRfNPGr/gt7Kbt9XBHqlvXLyLpFxDkSSv8=;
 b=KN/NurPfni2vW5WPy8PNEwaxpe+uGaKy5Fcw4xit34pqM5zE2FYT94rsBe5iOVjOSm
 PdlQNZWm1Lh93EgmglQQslh1YyZ/MOxpewT4KFCKtPpWqEhqjiNtxqEP6CzwoURw6QVQ
 /EJs0i2PS3mjmlky9YYK2ItwDnYPqiP9fYCWB6GV2oY0QZ+tAUWBvAeR6pWbJzfKBQSC
 8DpxUh1d0duv/QVr3R8PxaiveAHa1+J+g8+nRc6Cj3e/IEK7g643lmTBAg+92WXSKsGf
 gMC6vJZgrGEoCFdpyp1tmHzkf1z6x8tSegs23GekWAIos93Dg7koKOrXTOYxO4Wb43lU
 p7Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=2oMGTeUhweRfNPGr/gt7Kbt9XBHqlvXLyLpFxDkSSv8=;
 b=ivY6F1DCm0MMSvkRFbwj/UB/41O90RID68v7EtXPDgMKHovGchWnkX5B3AS1PkPIns
 n2df6ipJQQ4ya2qR9LZIFlp1hHMLlv/4u9kFzgZ4fM0gu5VJmHDYbmLQAVKhzWQCzq6q
 5wuv5U48PvhgnPbFVjZWPmkgS4MZ/TFhGADr5g+QUEqb2kl+UYXucpVzjoJCx4BvnEBV
 Zk+fUkohqR9yEEBJxi/e5yUTLjM+/EI+UM/bZel+WrNN/DOMwV8MtL7+R35l0ZmhdTKd
 5xV0Wl71iA05fIZLPAdXb3cckhMu4srAJ5z7N40VRf1VN4XR/oe4DduuSZY+Z5pAzWqg
 Duww==
X-Gm-Message-State: AGi0Pub/Q994zmJeDJ0XPzYsu2KXi28/t0djUVxJ8Qy5IS7LhSMX26KV
 hgk10d7mXKHmfg9dfLk2Bs5HZ7PhntkD5AGAjVwNYZl7
X-Google-Smtp-Source: APiQypLLa97X0J3qlfEa84Pj0awHgkBkyh7ERN5xBM8rdzZ0Ipb2c7Z8vc8tvF7LsxEmlJUNpAi0IteKTcKgLXNPkf0=
X-Received: by 2002:a17:906:7f0d:: with SMTP id
 d13mr22632781ejr.312.1589373220824; 
 Wed, 13 May 2020 05:33:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
 <CAH5Bsr1d57pzmNgakt=Q2M+Ey+PL9jUVUPeJ_aFj0L0TBAHzKw@mail.gmail.com>
 <CAH5Bsr1paP8dmo_z6VoEHYvB_SpD4Piw91LeLJBMgFph7Qrtfg@mail.gmail.com>
 <CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
 <Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com>
 <CAPv7TjbfuV1YvgTS4pjr_56R_-=spb9DzPwqP1HFCBOZpSOq8Q@mail.gmail.com>
 <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com>
 <CAPv7TjZAv_tVn=Wxf3LpfMmAzj8+mWiLr+7HMjjNArD7ThKO_A@mail.gmail.com>
 <CAPv7TjYewKe=Gt8io+uGNzeKmAq758vH9aB2OpFt=rGth8DZEg@mail.gmail.com>
 <oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com>
In-Reply-To: <oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Wed, 13 May 2020 14:33:21 +0200
Message-ID: <CAPv7TjaG3jxCDv5PtSeLeXi3Emo1_hvgYP1KEQg8+LU41SUqqQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003e296105a586ca28"
X-Mailman-Approved-At: Wed, 13 May 2020 12:34:08 +0000
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2020 12:33:44 -0000

--0000000000003e296105a586ca28
Content-Type: text/plain; charset="UTF-8"

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 day" (relative) so if Alice
broadcasts it after protocol completion, she is just giving Bob the key to
her LTC (note: if she's wise she'd move the LTC beforehand), but Bob
doesn't lose the BTC because he has both keys and can just react before the
relative timelock expires. No chaos.

>This is why we eventually decided in Lightning to use two CPFP outpoints
rather than one

I appreciate the explanation. I see the problem now, and yes, that does
seem like a headache.

Cheers,
Ruben

On Wed, May 13, 2020 at 1:39 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> 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 transactions
> >
> > Note that the timelock on the revoke tx is longer than the timelock on
> refund tx #1. The idea is that Alice aborts the protocol by publishing
> refund tx #1 if the protocol hasn't reached step 4 in the svg by the time
> it becomes valid. This should entirely mitigate the issue you're describing.
>
> But if refund tx #1 at all exists, then you drop to the same issue you
> objected to with my proposal, which is that, 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.
>
> So you might as well just use my counterproposal instead, which is
> simpler, gets bring-your-own-fees for free, etc.
>
> I suppose there is some *slight* improvement in that with your proposal,
> Alice *can* use revoke tx -> refund tx #2, but still, if Alice is insane
> then it could very well mess with the protocol by instead using refund tx
> #1.
> Thus, if Bob wants to survive in an environment where Alices are possibly
> insane (e.g. the real world), it should do everything in its power to
> ensure that the BTC txo is spent before the timeout of refund tx #1, if
> refund tx #1 exists at all.
> And if Bob is already going to do that, then Alice and Bob might as well
> just use my counterproposal etc etc.
>
> > >adding two CPFP outputs (one for each participant)
> >
> > There seems to be a situation where RBF can be disabled by the other
> party, but I'm not sure I see it... Why would a single output spendable by
> either key be insufficient?
>
> If one party quickly broadcasts a long chain of low-feerate transactions
> on top of the single output, then the output is "pinned".
>
> Low feerate means it is undesirable for miners to mine it, because it pays
> low for the amount of blockspace it has.
> But because there is a long chain of transactions, the absolute fee of
> that chain can be sizable, and we have a rule in RBF which, paraphrased,
> goes something like "the replacing transaction should also have a higher
> absolute fee than *all* the transactions it replaces", meaning the fee jump
> that the other side has to offer *has to be* pretty big.
>
> If the other outputs of the tx are then multisig, then the pinning
> participant can simply refuse to sign for those, and if the existing txes
> spending the other outputs are relative-time-locked, they cannot be used to
> CPFP the revoke tx onchain.
>
> This is why we eventually decided in Lightning to use two CPFP outpoints
> rather than one, and are also realizing just how much of a headache the RBF
> rules are, sigh.
>
> Still, in your proposed protocol the dependent transactions are all
> relative-timelocked, so timely confirmation of the revoke tx is not
> necessary, unlike in the case of Lightning where all HTLCs have to use an
> absolute timelock because we have to coordinate multiple HTLCs in
> forwarding and violation of the timelocks can lead to headaches and fund
> loss and so on.
> So maybe a single hook output, or even none at all, is workable.
>
> >
> > >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well
> >
> > Allowing others to add inputs/outputs would introduce malleability.
> Refund tx #2 and the timeout tx would become invalid.
>
> Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that.
>
> > >Bob cannot safely perform step 2 before getting both signatures for the
> revoke tx
> >
> > That's right, as you guessed, he does receive a copy of the signed
> revoke tx at protocol start.
> >
> > >>alternatively Bob can just spend before the timelock expires.
> > >This seems to be the safest alternative
> >
> > I agree not giving Alice time to publish the revoke tx is safest, but
> one does not preclude the other. The revoke tx is on an absolute timelock,
> so spending it before that time means you don't have anything to
> worry about, and spending it later means you'll have to be online and keep
> an eye out. If staying online is not a problem, then fee wise that seems
> preferable. As long as less than half of all valid (i.e. the timelock was
> reached) revoke transactions get broadcast, you'll be saving on fees.
>
> In a world where Alice may be insane and mess with the protocol just to
> grief Bob even if Alice loses its money (e.g. the real world), Bob should
> not depend on Alice behaving correctly or politely, so it should still have
> backup watchers set up in case it accidentally goes to sleep and so on.
>
> Regards,
> ZmnSCPxj
>

--0000000000003e296105a586ca28
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi ZmnSCPxj,<br><div><br></div><div>&gt;on completion of t=
he 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 cha=
os</div><div><br></div><div>You forget, refund tx #1 has a script (which bt=
w won&#39;t be visible with taproot): &quot;Alice &amp; Bob OR Alice in=C2=
=A0+1 day&quot; (relative) so if Alice broadcasts it after protocol complet=
ion, she is just giving Bob the key to her LTC (note: if she&#39;s wise she=
&#39;d move the LTC beforehand), but Bob doesn&#39;t lose the BTC because h=
e has both keys and can just react before the relative timelock expires. No=
 chaos.</div><div><br></div><div>&gt;This is why we eventually decided in L=
ightning to use two CPFP outpoints rather than one</div><div><br></div><div=
>I appreciate the explanation. I see the problem now, and yes, that does se=
em like a headache.</div><div><br></div><div>Cheers,</div><div>Ruben</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Wed, May 13, 2020 at 1:39 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@prot=
onmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Good morning Ruben,<br>
<br>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; &gt;potentially both Alice and Bob know all the secrets on the LTC sid=
e and end up competing over it<br>
&gt;<br>
&gt; That&#39;s exactly right.<br>
&gt;<br>
&gt; &gt;Bob can thus give a copy of the revoke tx with signature directly =
to its favorite miner, forcing Alice to take 3 transactions<br>
&gt;<br>
&gt; Note that the timelock on the revoke tx is longer than the timelock on=
 refund tx #1. The idea is that Alice aborts the protocol by publishing ref=
und tx #1 if the protocol hasn&#39;t reached step 4 in the svg by the time =
it becomes valid. This should entirely mitigate the issue you&#39;re descri=
bing.<br>
<br>
But if refund tx #1 at all exists, then you drop to the same issue you obje=
cted to with my proposal, which is that, on completion of the protocol, if =
Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) the=
n Alice can broadcast it, putting both their funds into chaos.<br>
<br>
So you might as well just use my counterproposal instead, which is simpler,=
 gets bring-your-own-fees for free, etc.<br>
<br>
I suppose there is some *slight* improvement in that with your proposal, Al=
ice *can* use revoke tx -&gt; refund tx #2, but still, if Alice is insane t=
hen it could very well mess with the protocol by instead using refund tx #1=
.<br>
Thus, if Bob wants to survive in an environment where Alices are possibly i=
nsane (e.g. the real world), it should do everything in its power to ensure=
 that the BTC txo is spent before the timeout of refund tx #1, if refund tx=
 #1 exists at all.<br>
And if Bob is already going to do that, then Alice and Bob might as well ju=
st use my counterproposal etc etc.<br>
<br>
&gt; &gt;adding two CPFP outputs (one for each participant)<br>
&gt;<br>
&gt; There seems to be a situation where RBF can be disabled by the other p=
arty, but I&#39;m not sure I see it... Why would a single output spendable =
by either key be insufficient?<br>
<br>
If one party quickly broadcasts a long chain of low-feerate transactions on=
 top of the single output, then the output is &quot;pinned&quot;.<br>
<br>
Low feerate means it is undesirable for miners to mine it, because it pays =
low for the amount of blockspace it has.<br>
But because there is a long chain of transactions, the absolute fee of that=
 chain can be sizable, and we have a rule in RBF which, paraphrased, goes s=
omething like &quot;the replacing transaction should also have a higher abs=
olute fee than *all* the transactions it replaces&quot;, meaning the fee ju=
mp that the other side has to offer *has to be* pretty big.<br>
<br>
If the other outputs of the tx are then multisig, then the pinning particip=
ant can simply refuse to sign for those, and if the existing txes spending =
the other outputs are relative-time-locked, they cannot be used to CPFP the=
 revoke tx onchain.<br>
<br>
This is why we eventually decided in Lightning to use two CPFP outpoints ra=
ther than one, and are also realizing just how much of a headache the RBF r=
ules are, sigh.<br>
<br>
Still, in your proposed protocol the dependent transactions are all relativ=
e-timelocked, so timely confirmation of the revoke tx is not necessary, unl=
ike in the case of Lightning where all HTLCs have to use an absolute timelo=
ck because we have to coordinate multiple HTLCs in forwarding and violation=
 of the timelocks can lead to headaches and fund loss and so on.<br>
So maybe a single hook output, or even none at all, is workable.<br>
<br>
&gt;<br>
&gt; &gt;We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well<br>
&gt;<br>
&gt; Allowing others to add inputs/outputs would introduce malleability. Re=
fund tx #2 and the timeout tx would become invalid.<br>
<br>
Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that.<=
br>
<br>
&gt; &gt;Bob cannot safely perform step 2 before getting both signatures fo=
r the revoke tx<br>
&gt;<br>
&gt; That&#39;s right, as you guessed, he does receive a copy of the signed=
 revoke tx at protocol start.<br>
&gt;<br>
&gt; &gt;&gt;alternatively Bob can just spend before the timelock expires.<=
br>
&gt; &gt;This seems to be the safest alternative<br>
&gt;<br>
&gt; I agree not giving Alice time to publish the revoke tx is safest, but =
one does not preclude the other. The revoke tx is on an absolute timelock, =
so spending it before that time means you don&#39;t have anything to worry=
=C2=A0about, and spending it later means you&#39;ll have to be online and k=
eep an eye out. If staying online is not a problem, then fee wise that seem=
s preferable. As long as less than half of all valid (i.e. the timelock was=
 reached)=C2=A0revoke transactions get broadcast, you&#39;ll be saving on f=
ees.<br>
<br>
In a world where Alice may be insane and mess with the protocol just to gri=
ef Bob even if Alice loses its money (e.g. the real world), Bob should not =
depend on Alice behaving correctly or politely, so it should still have bac=
kup watchers set up in case it accidentally goes to sleep and so on.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--0000000000003e296105a586ca28--