Date: Wed, 13 May 2020 08:39:37 +0000
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com>
In-Reply-To: <CAPv7TjbfuV1YvgTS4pjr_56R_-=spb9DzPwqP1HFCBOZpSOq8Q@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>
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,

> >If the shortened refund transaction exists (labeled "refund transaction =
#1" in the SVG) then the same issue still occurs=C2=A0
>
> Yes, but there is one crucial difference: at that point in the protocol (=
Bob has the success transaction and then stops cooperating) Alice and Bob b=
oth had the opportunity not to take that path. Bob could have sent the succ=
ess transaction, and Alice could have waited and sent the revoke transactio=
n. They would essentially be "colluding" to fail.

Okay, so the concern is basically, that Bob misses the deadline, then Alice=
 feels obligated to reclaim the funds.
In your proposal, the tx competition is between the secret-revealing succes=
s TX and the non-secret-revealing revoke tx.
Whereas in my counterproposal, under the same conditions, the tx competitio=
n is between the secret-revealing success tx and the secret-revealing backo=
ut tx, and both transactions becoming visible on P2P network means potentia=
lly both Alice and Bob know all the secrets on the LTC side and end up comp=
eting over it, RBFing each other until the entire fund goes to miners.


> >Without the refund#1 in your proposal, Bob refusing cooperation after Al=
ice puts the BTC into lock for 3 days and 2 further onchain transactions
>
> I'm not sure if I correctly understood what you're saying, but it's as fo=
llows:
>
> Refund #1 can only safely be used before the signed success tx is given t=
o Bob. The cost to Alice at this point if Bob aborts is two on-chain transa=
ctions while Bob hasn't put anything on-chain yet.
>
> Refund #2 needs to be used after Bob receives the signed success tx. The =
cost to Alice is now three transactions, but Bob also went-on-chain by this=
 point, so causing this wasn't costless to Bob and is thus a similar failur=
e mode.

I think it is not accurate that Bob is already on-chain before Alice can be=
 forced to use 3 transactions to fail.

The revoke tx signatures are shared at step 0 of your protocol description.
Thus Bob has a copy of the revoke tx that is valid once Alice signs and con=
firms the funding transaction.
Bob can thus give a copy of the revoke tx with signature directly to its fa=
vorite miner, forcing Alice to take 3 transactions to back out of the swap.

Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There ain=
't no such thing as a global mempool"), Alice will only know about this eve=
nt when the revoke tx is confirmed once, at which point it is very difficul=
t to reverse, even if Alice has a refund#1 tx prepared.

Bob can do this before step 2 in your protocol description, meaning before =
Bob locks up any funds, so Bob can do this for free, and will even use fund=
s going back to Alice to pay for confirmation of the revoke tx.
Because Bob can do this for free, there is no disincentive for trolling Bob=
s to exist whose sole life goal is to just grief possible Alices.

This can be slightly mitigated by adding two CPFP outputs (one for each par=
ticipant) and using the minimum relayable feerate for the revoke tx so that=
 Bob is forced to bring its own fees in order to incentivize miners.
This is similar to the "bring your own fees" currently proposed for Lightni=
ng, but note the recent hand-wringing about the various problems this adds =
to mempools and CPFP and RBF rules and etc etc: https://lists.linuxfoundati=
on.org/pipermail/bitcoin-dev/2020-April/017757.html

We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a bring-yo=
ur-own-fees, but that is not `SIGHASH_ALL` and thus marks the transaction g=
raph as special.
And forcing bring-your-own-fees means neither Alice nor Bob can swap all th=
eir funds in a single operation, they have to keep a reserve.


Bob cannot safely perform step 2 before getting both signatures for the rev=
oke tx, as without Bob having access to the rveoke tx, if Bob locks up LTC,=
 Alice can stop responding and lock both their funds indefinitely with Bob =
not having any way to recover its funds, which a rich Alice can use to comp=
letely lock out an impoverished Bob.
But if Bob is given both signatures for the revoke tx before step 2, then B=
ob can send the revoke tx to its favorite miner, forcing Alice to take 3 tr=
ansactions to back out, before Bob locks any funds in LTC side.

>
> I also agree with your observation that alternatively Bob can just spend =
before the timelock expires.

This seems to be the safest alternative; in my context, where Bob is a Coin=
Swap server/maker, Bob can wait a short while for new clients/takers, and i=
f no new clients arrive, spend.
Bob can run multiple servers, each of which are given the completed success=
 transaction, and the servers can check that if the timeout is near, to spa=
m the Bitcoin P2P network with the completed success transactions.
(these servers need not even run fullnodes, they could just periodically po=
ll a number of blockchain explorers and electrum servers, and when the bloc=
kheight approaches, attempt broadcast; if the "main" server that accepts cl=
ients/takers has already spent the TXO the broadcast of the completed succe=
ss tx is simply rejected by the Bitcoin P2P network; if the timeout is base=
d on sidereal time then the backup servers only need to be running NTP)


Regards,
ZmnSCPxj