From: Gleb Naumenko <naumenko.gs@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Costless bribes against time-sensitive protocols
Date: Thu, 2 Feb 2023 10:40:04 +0200 [thread overview]
Message-ID: <f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark> (raw)
In-Reply-To: <a0898fd1-88db-41b0-97b3-a1c7a1640b39@Spark>
[-- Attachment #1: Type: text/plain, Size: 7009 bytes --]
## Intro
Most of it feels like implicit knowledge, but I couldn't find anything written so here it is. The ideas towards anchor outputs and the conclusions probably have some new perspectives.
This post is about the game-theoretic security of time-sensitive protocols if miners are open to censorship for a reward. To become practical, the following has to happen.
1) a substantial hashrate has to be willing to participate in this behaviour, according to the known formula from the Whitepaper. The more blocks it takes to attack (defined by a particular protocol configuration and could be tuned), the exponentially higher % hashrate is required.
2) a communication layer is required to send bribes to these miners. This could be a private transaction relay network, or a mempool allowing still-time-locked transactions. It could be even an announcement board (e.g., submitting raw txs under a Twitter hashtag and inviting miners to monitor it).
3) a bribe transaction construction (will be explained later).
In this post, I talk about the case when:
1. a significant hashrate (e.g., 95%+) is open to take these bribes;
2. but miners don't trust each other;
3. and there is no reorgs.
Assumption \*(2) is more nuanced. What I mean here is roughly "miner X would rather take an immediate gain than commit to a lenghty scenario where many miners coordinate to take reward on behalf of each other and then distribute it accordingly to the hashrate". The game theory of this assumption should be better defined in the future.
We will see, how widely known tweaks lift the bar for (2) and (3) and how this could be further improved.
*A special case of this scenario is miners withholding Alice's transaction to force her to bump fees, even if Bob hasn't submitted a bribe. Here I assume miners won't do it unless there is an external incentive (Bob's bribe), although this issue is also interesting.*
## Simple opcode-based construction
The simplest time-sensitive two-party contract is PowSwap (a bet on the future block issuance rate), a single on-chain UTXO with the following spending conditions:
- Alice’s key can spend if height=H is reached;
- Bob’s key can spend if Time=T is reached.
Say H is approaching quickly, and T is far behind. Bob now uses a private mining relay to submit his non-mineable transaction paying e.g. half of the UTXO value towards fees.
Alice has two problems: 1) she can’t figure out why her transaction isn’t mined and how much fee to overpay; 2) the attack is free for Bob (he has nothing to lose), while Alice loses everything up to the full UTXO value.
## Simple nLockTime-based construction
If parties use pre-signed transactions with nLockTime (instead of the opcodes), Bob’s fee can be pre-signed to a rather low value, so that Alice can reasonably overbid it without much loss (she probably doesn't even need to take any action).
Bob can, however, bump the fee by creating a CPFP transaction with super-high fee. All it requires now is submitting twice as much data to the private mining relay (and burning slightly more in fees).
## nLockTime-based construction with OP_CSV output
If Bob’s output can’t be spent right away, but is forced to be deterred to even one block in the future, it makes taking this bribe not rational: a censoring miner can’t be sure about the deferred reward (remember, miners don't trust each other). At the same time, mining the honest transaction and taking its fee is always available earlier.
Smart contracts could possibly make it rational for miners (see [1]), e.g. by allowing Bob to allocate the bribe based on the historic hashrate distribution linked to coinbase pubkeys.
At the same time, this approach makes dynamic fee management impossible.
## Anchor outputs
Anchor outputs allow bringing external capital for fee management while locking internal capital. Bob can use this capital for a bribe. If the attack fails, Bob's external capital remains safe, so this is not so bad for Bob.
The attack can be more costly if this external capital was claimable:
- by Alice: e.g., Alice can steal a (covenanted) anchor output if it's revealed before Bob's nLockTime makes it mineable (requires her to monitor the private relay);
- or by miners, e.g. if Alice forces Bob, at contract setup, to use a reverse time-lock (the anchor can be stolen by miner if seen before time=T); or if mining Alice's honest transaction also allows miners to take Bob's fee output (e.g., Alice's honest transaction *could* act as a parent/preimage, conditionally, although this may require reverse time-locking Alice to protect Bob...)
*Ephemeral anchors doesn’t do much w.r.t. our trade-off, as it is a mempool-oriented thing.*
## Lightning
Lightning is different from the described protocol in two things:
1) It relies on intermediate transactions (e.g., Commitment in Poon-Dryja);
2) Usually both parties have some balance in the channel.
I believe that (1) doesn’t change the situation much, it just makes it more nuanced.
(2) is irrelevant because an attacker can just spend the entire channel before the attack.
Thus, most of these concerns apply to lightning equally.
## Related work
The LN paper briefly mentioned this problem, although it was claimed impractical due to a high degree of required collusion. We already see private mining relay in mevwatch.info (ethereum), and we had FIBRE (I think it was neutral).
[2] discussed constructions and economics for bribing miners. [1] suggests more practical considerations for achieving this. Both don’t focus on the risks of particular time-sensitive protocol constructions.
[3] highlighted a similar protocol risk, but the proposed solution seems to work only if an attacker has funds to lose locked in the contract (e.g., collateral, lightning balance, powswap payout).
## Conclusions
To increase the attack bar w.r.t the configuration described in the intro, we should either:
- stick to the *nLockTime-based construction with OP_CSV output*, forget about dynamic fee management, and hope that bribe allocation smart contracts doesn't work out;
- use anchor outputs (or another external fee scheme), but enforce a way to steal/burn the external fee if it's an attack;
- design new fee/channel constructions.
These ideas may also be helpful for alternative payment channels designs as well (v3+ephemeral anchors, SIGHASH_GROUP, etc.), or in the future to protect against more powerful covenants allowing stronger bribes (see [1]).
Thanks to Antoine Riard and Greg Sanders for initial discussion.
-------------------------
## References
1. TxWithhold Smart Contracts by Gleb Naumenko | BitMEX Blog (https://blog.bitmex.com/txwithhold-smart-contracts/)
2. Temporary Censorship Attacks in the Presence of Rational Miners (https://eprint.iacr.org/2019/748.pdf)
3. MAD-HTLC: Because HTLC is Crazy-Cheap to Attack (https://arxiv.org/pdf/2006.12031.pdf)
[-- Attachment #2: Type: text/html, Size: 8004 bytes --]
parent reply other threads:[~2023-02-02 8:40 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <a0898fd1-88db-41b0-97b3-a1c7a1640b39@Spark>]
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=f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark \
--to=naumenko.gs@gmail$(echo .)com \
--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