Add "Replacement rules and Fee Bumping" problem #13
Conversation
_problems/fee-bumping.md
Outdated
| Layer-2 protocols like [Lightning] treat the blockchain as a dispute resolution and settlement layer. | ||
| Only when their counterparty is unreachable or uncooperative does a participant have to unilaterally broadcast a transaction. | ||
| The protocol often requires a party to confirm a transaction within a certain time so the funds are distributed fairly. | ||
| So how can layer-2 protocol designers guarantee their users are able to confirm their transaction before the deadline? |
There was a problem hiding this comment.
I think we should reevaluate this point. I don't think as a L2 dev you can require "confirmation guarantees" from a distributed system such as Bitcoin. The best you can do is increasing the odds of confirmation by offering an accurate feerate bid for your transactions.
That said as of today, we're even devoid of safe fee-bumping primitives matching L2 protocols semantics. We lack basic security mechanisms but even implemented their efficiency is still function of global blockspace demand.
Ideally, we would define the security properties of L2 protocols through a sequence of security games :
- a zero-sum two-participants game with incomplete information, with only the Lightning holder and its counterparty. Corresponding security property : tx-relay jamming safety (pinning, standardness malleability, witness malleability, ...)
- a zero-sum three-participants game with incomplete information, with the Lightning holder, its counterparty and third-party blockspace bidders. Corresponding security property : congestion safety (feerate reserve)
- a zero-sum four-participants game with incomplete information, with the Lightning holder, its counterparty, third-party blockspace bidders and the miners. Corresponding security property : miner-manipulation resistance
- DLC bonus point : a zero-sum five-participants game with incomplete information, with the Lightning holder, its counterparty, third-party blockspace bidders, the miners, the oracles. Corresponding security property : ?
Of far such security analysis could rely on notions from current framework on cryptographic protocols like the UC model ? That's a good question.
There was a problem hiding this comment.
Well lightning should come with "security guarantees" under certain assumptions. Your efforts and the goal of this problem are to make these assumptions clear, simple and have a reasonable chance of being realized in practice. This will never be to the same degree as cryptographic hardness assumptions but I still think it's fair to talk about guarantees in this sense for l2 protocols.
I think your assessment of some likely security games with which to define these assumptions in is useful. I'll add a link in the commentary section.
WRT to UC I am not a big fan for these types of systems (I prefer security games). The reason being is that UC is suited to secure computation -- stuff with secret inputs and outputs. Whenever people stray out of this it tends to be really hard to get an intuition for security (for me at least). When you are interacting with a chain you don't really have meaningful secret input. In terms of security you are just trying to make sure that you don't end up in an unacceptable state. To do this you can simply rule out certain types of bad states with a proof by contradiction (and hope you thought of all types of bad states!). Proof assistants can probably help you find all bad states if you have language where you can express l2 protocols easily. It's probably an interesting research topic and deserves a page!
There was a problem hiding this comment.
I think your assessment of some likely security games with which to define these assumptions in is useful. I'll add a link in the commentary section.
Sure, I was thinking more a first draw to answer #12, I'll turn it as a real problem page.
In terms of security you are just trying to make sure that you don't end up in an unacceptable state.
Contract halting, contract burning, balance burning, ... we may be far to have met in practice most of the unacceptable states.
When you are interacting with a chain you don't really have meaningful secret input.
I share the opinion, I've always been willingly to model the chain as a game's "umpire", assigning coins to "players" in function of their onchain "moves" (or pre-signed transactions).
It's probably an interesting research topic and deserves a page!
Linking this thread in #12.
| There are two approaches available in Bitcoin today. | ||
|
|
||
| 1. *Replace-by-Fee* ([RBF]): The user simply signs a new transaction that is likely to replace the old one since it pays a higher fee. | ||
| 2. *Child-Pays-For-Parent* ([CPFP]): The original transaction remains unchanged but a new transaction with a higher fee is signed which spends from the old one increasing the average feerate of the pair. |
There was a problem hiding this comment.
A third know proposal is sponsorship : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
There was a problem hiding this comment.
Right this is in the "Proposed Solutions" section.
_problems/fee-bumping.md
Outdated
| In particular a replacement transaction must pay a higher absolute fee and a higher feerate than the transactions they are evicting and it must not evict more than 100 transactions. | ||
|
|
||
| For layer-2 protocols this rules had the unintended consequence of introducing "pinning" attacks (see [Related Research](#related-research)). | ||
| This is usually done by adding a lot of descendants to a transaction that conflicts with the one the honest party needs confirm. |
There was a problem hiding this comment.
Actually, the most straightforward pinning against a lot of L2 protocols is abuse of BIP125 rule 3 (absolute fee requirement). It's documented as scenario 2 on this branch : ariard/bitcoin@67cbb70 :)
There was a problem hiding this comment.
Hmm but is this still the case if CVE-2021-31876 is fixed? I changed the sentence to imply that adding descendants is just an example of how to do it and that the other rules can be abused too.
There was a problem hiding this comment.
Note that CVE-2021-31876 and BIP125 rule 3 are two differing pinning vectors. CVE-2021-31876 is quite easy to mitigate from a l2 protocol designer viewpoint by just signaling RBF on all in-protocol transactions.
There was a problem hiding this comment.
Understood but as I read it "scenario 2" is CVE-2021-31876 in the link provided? Did you mean scenario 1?
_problems/fee-bumping.md
Outdated
| This is usually done by adding a lot of descendants to a transaction that conflicts with the one the honest party needs confirm. | ||
| As we have said an honest party needs to confirm a transactions in a certain time -- if it can't evict a maliciously crafted transaction then they are in a helpless position. | ||
|
|
||
| An instinctive exception to [BIP125]'s rules called the [CPFP carve out] was introduced to allow lightning designers to avoid pinning attacks with some extra design effort. |
There was a problem hiding this comment.
For now, without package relay, it's just a reduction of the pinning surface.
_problems/fee-bumping.md
Outdated
|
|
||
| ## Impact | ||
|
|
||
| The principles layer-2 protocol designers should use to enable transactions to confirm on time are an esoteric domain understood by only a handful of people. |
|
|
||
| 1. **Reconsidering mempool and relay rules**: It is possible that mempool rules could be made less problematic for layer-2 protocol designers without harming the Bitcoin system. | ||
| The main concern with this approach is that the rules that are optimal for layer-2 protocols may not be the rules that are optimal for miner profit or preventing DoS attacks. | ||
| However, if tweaked relay rules were to allow layer-2 Bitcoin protocols to thrive then the increased value of the Bitcoin network could more than compensate miners for using a slightly suboptimal algorithm (as long as they don't introduce DoS attacks). |
There was a problem hiding this comment.
I believe that a mempool acceptance rules revamp can still combine security mechanism for L2s and miner incentives. In anyway, fee-bumping is good for miners as you're making the blockspace demand more competitive.
There was a problem hiding this comment.
I agree and I think this concern can be dismissed in a different way: per-utxo transactions fee optimization is not important for miners as it will create negligible revenue. It is about making sure they have the highest fee paying transaction set from different utxos (i.e. different users are competing for blockspace). There is no need to necessarily resolve two transactions that share the same input strictly in favor of the one that pays the highest fee in absolute terms of feerate. Or at least DoS is the only concern here not revenue.
Hmm never mind this comment. I am going to try and refine my thoughts and add them as commentary (and possibly shrink the quoted sentence so it contains less of my personal commentary).
There was a problem hiding this comment.
I'm curious about more refined thoughts on this issue as I think we might have to switch from replace-by-fee to replace-by-feerate to solve some pinnings.
Further, having a consistent miner model w.r.t to conflicting transactions is an interesting research, likely deserves its own page too.
There was a problem hiding this comment.
I'm curious about more refined thoughts on this issue as I think we might have to switch from replace-by-fee to replace-by-feerate to solve some pinnings.
Actually this was going to be the gist of my commentary! Along with how to better deal with the mass descendants eviction problem than BIP125.
Further, having a consistent miner model w.r.t to conflicting transactions is an interesting research, likely deserves its own page too.
Is this actually that deep of a topic? I'd say unless it turns out that there is a lot more than meets the eye then it's part of this.
_problems/fee-bumping.md
Outdated
|
|
||
| 1. In *[RBF Pinning with Counterparties and Competing Interest]* Corallo introduces the idea of a pinning attack. | ||
| 2. In *[Pinning : The Good, The Bad, The Ugly]* Riard describes the problem of pinning attacks and gives several examples relevant to Lightning. | ||
| 3. The *[Mempool and mining]* article on the Bitcoin core development wiki Daftuar provides the rationale for why the mempool rules are the way they are. |
There was a problem hiding this comment.
The OG pinning mitigated by the carve-out mechanism : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html
|
I pushed a new revision which integrates your feedback and adds other fixes. Before merging I want to mention your recent mailing list proposal first. Further feedback welcome. [edit] and thanks very much for the review :) |
| The other [BIP125] rules may be abused as well. | ||
|
|
||
| The Bitcoin core developers instincitvely introduced an exception to [BIP125]'s rules called the *[CPFP carve out]* to allow lightning designers to mitigate pinning attacks to some extent. | ||
| Unfortunately, using CPFP required a siginficant lightning protocol redesgin and will not be an effective solution until the Bitcoin network supports [package relay]. |
There was a problem hiding this comment.
nit: s/siginficant/significant/g, s/redesgin/redesign/g
Also input-based fee-bumping as roughly described in "A Stroll through Fee-Bumping Techniques" is another solution, equivalent to package-relay, though require softfork(s).
| ## Impact | ||
|
|
||
| The principles layer-2 protocol designers use to work around the [BIP125] rules an esoteric domain understood by only a handful of people. | ||
| Even those practiced in the occult [have made mistakes](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html) trying to design around them. |
There was a problem hiding this comment.
Another pitfall around malleability for fee-bumping : revault/practical-revault#83
Could be nice to track it.
|
|
||
| The principles layer-2 protocol designers use to work around the [BIP125] rules an esoteric domain understood by only a handful of people. | ||
| Even those practiced in the occult [have made mistakes](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html) trying to design around them. | ||
| Having a simple set of principles would increase the confidence in the resulting protocols and allow a wider group to understand and build layer-2 systems. |
There was a problem hiding this comment.
Another concern is base-layer protocols dev restraining tx-relay rules in a way hammering L2s, as an example : bitcoin/bitcoin#8279
| In *[A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring]* Rubin proposes allowing a transaction to sponsor another. | ||
| The sponsor transaction can only be included in a block if the transaction it is sponsoring is in it too. | ||
| The sponsor transaction's fees then increase the overall feerate of the pair of transactions. | ||
| The advantage of this idea is that it is always available to any transaction without the protocol designer having to consider fee bumping. |
There was a problem hiding this comment.
Maybe you can mention "A Stroll through Fee-Bumping Techniques" where SIGHASH_ANYPREVOUT + SIGHASH_IOMAP as another solution to address those issues. I'll do a proper write-up on SIGHASH_IOMAP soon.
_problems/fee-bumping.md
Outdated
| Layer-2 protocols like [Lightning] treat the blockchain as a dispute resolution and settlement layer. | ||
| Only when their counterparty is unreachable or uncooperative does a participant have to unilaterally broadcast a transaction. | ||
| The protocol often requires a party to confirm a transaction within a certain time so the funds are distributed fairly. | ||
| So how can layer-2 protocol designers guarantee their users are able to confirm their transaction before the deadline? |
There was a problem hiding this comment.
I think your assessment of some likely security games with which to define these assumptions in is useful. I'll add a link in the commentary section.
Sure, I was thinking more a first draw to answer #12, I'll turn it as a real problem page.
In terms of security you are just trying to make sure that you don't end up in an unacceptable state.
Contract halting, contract burning, balance burning, ... we may be far to have met in practice most of the unacceptable states.
When you are interacting with a chain you don't really have meaningful secret input.
I share the opinion, I've always been willingly to model the chain as a game's "umpire", assigning coins to "players" in function of their onchain "moves" (or pre-signed transactions).
It's probably an interesting research topic and deserves a page!
Linking this thread in #12.
I wrote this up as part of preparation for following along with the "relay workshop" being organized by @ariard. I think it is a really important problem. Perhaps it is shortly solved by discussions coming out of the sessions but it was at least worth writing for me to get some of the details down.