From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Chris Belcher <belcher@riseup•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Date: Sun, 30 Aug 2020 13:38:11 +0000 [thread overview]
Message-ID: <JbGkYGhmwBZZEvZHPzR67vmY7O2-qaNKhV0aD5EC0lfqm8dHzBNS9xz8-WgJ3O2mTjVoKB4Z-IgLGApROnn3fS-NHXwyEruB3_5z2dSJmZI=@protonmail.com> (raw)
In-Reply-To: <d08ddff2-f62a-661b-d9cf-2f84f7d3ea9e@riseup.net>
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 minimum.
A P2SH-P2WPKH output costs something like ~130 vbytes to spend, at 1.000 sat/vbyte that is only ~130 sats to spend a 547 sat anchor output, an opportunistic 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 swaps 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 put 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 txes) new UTXO might be comparable to the actual maker fee.
Since this camping attack is done after the CoinSwap, the maker fidelity bond is a weak protection against this.
The maker can keep around contract transactions indefinitely, and if standard wallets assume they can leave the coins in the same UTXO indefinitely, the contract transactions remain valid indefinitely, including up to fidelity bond timeout.
When the fidelity bond times out, the maker has to destroy its identity anyway, 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, so the camper can wait for at most a week to do this) to publish all still-valid contract transactions, and spend all the anchor outputs including the fidelity bond at the minimum feerate, getting a slightly larger fidelity bond fund, then CoinSwap it to honest makers to clean it, then make a new fidelity 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=feerate (requires CPFP package relay at base layer 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 547 sat / 130 vbyte fee rate (at which point it becomes uneconomical for campers to mount their sniping attack as they would lose the anchor output amount to fees anyway).
In fact the wallet can do that all the time, and if prevailing fees are above the 547 / 130 rate it will not confirm and the wallet that wants to spend 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
next prev parent reply other threads:[~2020-08-30 13:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 12:05 Chris Belcher
2020-08-20 11:17 ` ZmnSCPxj
2020-08-20 15:28 ` Nadav Kohen
2020-08-20 21:38 ` ZmnSCPxj
2020-08-20 22:37 ` Chris Belcher
2020-08-20 22:15 ` Chris Belcher
2020-08-21 4:20 ` ZmnSCPxj
2020-08-21 9:47 ` Chris Belcher
2020-08-22 1:09 ` ZmnSCPxj
2020-08-24 19:30 ` Antoine Riard
2020-08-25 3:16 ` ZmnSCPxj
2020-09-03 9:00 ` Chris Belcher
2020-09-03 9:45 ` ZmnSCPxj
2020-09-03 10:50 ` Chris Belcher
2020-09-03 23:39 ` ZmnSCPxj
2020-09-05 2:45 ` ZmnSCPxj
2020-09-05 1:10 ` Antoine Riard
2020-09-05 2:29 ` ZmnSCPxj
2020-08-29 22:03 ` Chris Belcher
2020-08-30 13:38 ` ZmnSCPxj [this message]
2020-09-05 1:07 ` Antoine Riard
2020-09-06 3:06 ` seid Mohammed
2020-10-03 10:36 ` [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium Chris Belcher
2020-10-03 13:31 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='JbGkYGhmwBZZEvZHPzR67vmY7O2-qaNKhV0aD5EC0lfqm8dHzBNS9xz8-WgJ3O2mTjVoKB4Z-IgLGApROnn3fS-NHXwyEruB3_5z2dSJmZI=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox