Date: Sun, 30 Aug 2020 13:38:11 +0000
To: Chris Belcher <belcher@riseup.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <JbGkYGhmwBZZEvZHPzR67vmY7O2-qaNKhV0aD5EC0lfqm8dHzBNS9xz8-WgJ3O2mTjVoKB4Z-IgLGApROnn3fS-NHXwyEruB3_5z2dSJmZI=@protonmail.com>
In-Reply-To: <d08ddff2-f62a-661b-d9cf-2f84f7d3ea9e@riseup.net>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
 <d08ddff2-f62a-661b-d9cf-2f84f7d3ea9e@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
	multi-transaction CoinSwap
Precedence: list

Good morning Chris,

> It seems having just one contract transaction which includes anchor
> outputs in the style already used by Lightning is one way to fix both
> these vulnerabilities.
>
> For the first attack, the other side cannot burn the entire balance
> because they only have access to the small amount of satoshi of the
> anchor output, and to add miner fees they must add their own inputs. So
> they'd burn their own coins to miner fees, not the coins in the contract.

Minimum output size is 547 sats, so anchor outputs are that amount at minim=
um.
A P2SH-P2WPKH output costs something like ~130 vbytes to spend, at 1.000 sa=
t/vbyte that is only ~130 sats to spend a 547 sat anchor output, an opportu=
nistic camper could collect from a few swaps it would have done anyway (e.g=
. as a passive popular maker?) and broadcast the contract txes of those swa=
ps and then spend the anchor outputs together to get a few sats in a not-so=
-dusty UTXO, getting (547 - 130) sat per input minus the cost of creating a=
 new tiny output.
Assuming the camper has already claimed its side of the swap in order to pu=
t it in cold, this is basically a tiny but free amount of extra money, and =
if small CoinJoins in JoinMarket are any indication, the 547 sats minus fee=
 to spend it minus fee to create (amortized among the multiple contract txe=
s) new UTXO might be comparable to the actual maker fee.

Since this camping attack is done after the CoinSwap, the maker fidelity bo=
nd is a weak protection against this.
The maker can keep around contract transactions indefinitely, and if standa=
rd wallets assume they can leave the coins in the same UTXO indefinitely, t=
he contract transactions remain valid indefinitely, including up to fidelit=
y bond timeout.
When the fidelity bond times out, the maker has to destroy its identity any=
way, so it could opportunistically wait for a low-fee period after fidelity=
-bond timeout (we currently get low fee periods once a week, for example, s=
o the camper can wait for at most a week to do this) to publish all still-v=
alid contract transactions, and spend all the anchor outputs including the =
fidelity bond at the minimum feerate, getting a slightly larger fidelity bo=
nd fund, then CoinSwap it to honest makers to clean it, then make a new fid=
elity bond.
And if one of the takers happens to not be watching for contract tx timeout=
, it can potentially get free money, again, from the inattention.

(I call it a "camper attack" since the attacking CoinSwap participant waits=
 around in a single place (maker fidelity bond) and snipes passing contract=
 transactions to extract value from them when opportunity (low fee rate) is=
 good, like a camper.)

To protect against this, we should force contract txes to signal RBF, make =
contract txes min-relay=3Dfeerate (requires CPFP package relay at base laye=
r tho), and during low-fee periods we should collect outputs whose private =
key have been turned over to us, paying at a feerate slightly higher than 5=
47 sat / 130 vbyte fee rate (at which point it becomes uneconomical for cam=
pers to mount their sniping attack as they would lose the anchor output amo=
unt to fees anyway).

In fact the wallet can do that all the time, and if prevailing fees are abo=
ve the 547 / 130 rate it will not confirm and the wallet that wants to spen=
d its funds *now* can sign a new RBF tx at higher feerate to replace it.

Low fees, who would have thought that would enable an attack vector....

Regards,
ZmnSCPxj