Date: Wed, 13 May 2020 11:39:10 +0000
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com>
In-Reply-To: <CAPv7TjYewKe=Gt8io+uGNzeKmAq758vH9aB2OpFt=rGth8DZEg@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
Precedence: list

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 re=
fund 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 beco=
mes 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 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.

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, Al=
ice *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 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.
And if Bob is already going to do that, then Alice and Bob might as well ju=
st 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 part=
y, but I'm not sure I see it... Why would a single output spendable by eith=
er 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 s=
omething like "the replacing transaction should also have a higher absolute=
 fee than *all* the transactions it replaces", meaning the fee jump that th=
e other side has to offer *has to be* pretty big.

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.

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.

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.
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. Refun=
d 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=C2=
=A0about, 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 prefe=
rable. As long as less than half of all valid (i.e. the timelock was reache=
d)=C2=A0revoke transactions get broadcast, you'll be saving on fees.

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.

Regards,
ZmnSCPxj