Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
policy: nVersion=3 and Package RBF #25038
policy: nVersion=3 and Package RBF #25038
Changes from all commits
3bca679
18406ec
1b2cd22
c74c826
3ad3ea5
b828ea0
f82c9fd
d6bd8dc
75a1efd
25f528a
0933d4f
d629f29
4785582
678f56d
0bc6375
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get this sentence. Nobody wants to fee-bump B, no? Alice would want to replace B, what does it have to do with fee-bumping?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mallory's goal is to pin the transaction in the mempool. That is, increase the fees required to replace B, but not make it confirm. Mallory can of course put 1BTC of fees in the descendant, thus making it extremely expensive to replace B, but then she's also CPFP'd B and it's probably going to be mined very soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we would like to add more rational to the design of the rules, we could explain why a scorched earth approach would solve the Lightning case really imperfectly (discussed recently here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021176.html). Indeed, Lightning implementation could just blindly replace-by-fee the pinning transactions, paying up to the channel value. This wouldn't work at all against an attacker pinning with one single malicious transaction multiple channel from different parties where the malicious transaction fee is above the value of each channel. E.g channel A 10000 sats, channel B 25000 sats and channel C 8000 sats. If the malicious pinning transactions fee equals 26000 sats, none of the honest party will rationally fee-bump more than their own channel value.
Feerate-only replacement rules scales up to the maximum package size and worst historical mempool reduce consideraly the fee-bumping reserves requirement for a LN node, which is a notable advantage I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you ever discuss what will happen in the 2-block-reorg case? A chain of txs could end up being not-re-added to the mempool (due to rules 2/3), and then something becomes insecure.
I think I should bring a concrete example here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh too bad, the next comment asks the same question. Certainly worth documenting though :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a concrete example would help, yeah. For example, when you say "something becomes insecure" it's not really clear to me what you mean - a v3 transaction gets censored? A mempool has a chain of more than 2 v3 transactions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question about this and sorry if it's already been addressed:
Does this require extra logic for reorg handling? I'm thinking of a chain of v3 TXs:
tx1 (confirmed in block 100) ->
tx2 (confirmed in block 101) ->
tx3 (unconfirmed, currently in mempool)
if block 101 is disconnected, that potentially puts tx2 back in the mempool meaning tx3 is now invalid and should be evicted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, v3 enforcement during reorg is implemented in
MaybeUpdateMempoolForReorg
here and tested in mempool_accept_v3.py here. Would it make sense for me to add a note in the docs?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet 👍 Couldn't hurt to mention that in a bullet point here I suppose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some related discussion on estimating mining score of the replacement: #26451 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This incentive deficiency linked above should be a non-issue for CheckMinerScores since V3 package RBF is a restricted topology which disallows an multiple ancestors entirely.
The two cases of "adding a new unconfirmed input" during RBF with this PR:
The asymmetry above is annoying and a mild pinning vector.
As of this PR, wallet authors can avoid this pinning scenario entirely by not moving fee utxos between different unconfirmed parents, but it would be nice if asymmetry was avoided to make wallet reasoning simpler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I understand correctly that you are pointing out that package RBF and single tx RBF have different rules? And suggesting we try to make them more symmetrical by applying something similar in the single tx rules?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally yes. Doesn't have to be done now, it just reduces the utility of new unconfirmed inputs to randomly working sometimes, basically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After this check, we know it's a mixture(?) and therefore illicit, making hitting 000facb#diff-a19c07329799a164e1e3bd89e7cd07f1a8e5e97b88f2b24c9bef17df04479c74R51 impossible and the below loops a only useful for returning an example illicit tuple.
Perhaps just grab one v3 example and one non-v3 example and return those to simplify the rest of the code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the loops/maps are only used to return a more helpful string to the user. I don't think it's too much work? This function accepts a list of transactions that doesn't necessarily need to be an ancestor packages, so just grabbing a V3 and non-V3 could be 2 transactions that aren't parent-child.