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"
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Precedence: list

--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--