Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "Replacement rules and Fee Bumping" problem #13

Merged
merged 2 commits into from Jun 13, 2021

Conversation

LLFourn
Copy link
Contributor

@LLFourn LLFourn commented May 27, 2021

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.

@LLFourn LLFourn requested a review from ariard May 27, 2021 05:08
Copy link
Contributor

@ariard ariard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work, another title could be "Secure Fee-Bumping for L2s" though secure fee-bumping is a subset of the tx-relay jammings concerns IMHO

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?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right this is in the "Proposed Solutions" section.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood but as I read it "scenario 2" is CVE-2021-31876 in the link provided? Did you mean scenario 1?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes!

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now, without package relay, it's just a reduction of the pinning surface.


## 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😆


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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@LLFourn LLFourn Jun 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The OG pinning mitigated by the carve-out mechanism : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html

@LLFourn
Copy link
Contributor Author

LLFourn commented Jun 4, 2021

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].
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@ariard ariard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM, i pointed some typos and furnished more links but up to you if you want to take them.
Otherwise, we can land it now.

@ariard ariard merged commit d65c953 into bitcoin-problems:master Jun 13, 2021
@LLFourn LLFourn deleted the fee-bumping branch June 14, 2021 01:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants