Bump unconfirmed ancestor transactions to target feerate#26152
Bump unconfirmed ancestor transactions to target feerate#26152achow101 merged 8 commits intobitcoin:masterfrom
Conversation
db2c0f7 to
54fd46b
Compare
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
54fd46b to
a07ac02
Compare
|
Thanks @fanquake, I fixed the two issues. I also added a test for a transaction using |
There was a problem hiding this comment.
HUGE Concept ACK obviously 🥳 🥳
This needs to obey -maxtxfee, so I'd suggest that coin selection keeps track of what ancestors the tx has and how much of the fees is ancestors vs this transaction. And we'd want a test where the target feerate is just below maxtxfee and there are low-feerate ancestors to bump, and so total fees paid / size of this tx is higher than maxtxfee, but actually you're just paying to bump.
Also, given that there is a (small) chance of overpayment, it would be good to check that -maxtxfee protects against something drastic. For example, a test where all the coins share 1 large parent? It will overestimate and -maxtxfee should make sure the tx isn't sent? edit: this is totally wrong
t-bast
left a comment
There was a problem hiding this comment.
Concept ACK, thanks a lot for working on this, it will be very helpful!
And this set of internal utility functions will very likely be useful for many things in the future.
I'll create a set of E2E tests in eclair to run against this branch when I have a bit more time, I'll let you know the results.
|
I ran a first set of tests from within eclair against a07ac02, and everything is looking good 👍 |
a07ac02 to
a720b50
Compare
a720b50 to
337a24e
Compare
|
@glozow: Maybe for
Maybe we can add a @jonatack, @t-bast: |
There was a problem hiding this comment.
This needs to obey -maxtxfee
Maybe we can add a maxtxfee check to the filter introduced in #25729 for max weight after input sets are produced for different subsets of the available coins. Perhaps a separate PR that builds both on this one here and #25729.
Not sure if this is scope creep, but seems like breaking maxtxfee would be a bug and should probably be done in the same PR? Why not build this on top of #25729? ignore
970c848 to
f9979ef
Compare
Todos:
|
|
@glozow: looking more into this, I realized that the |
Ah for some reason I thought it was a feerate, apologies. Question: is it better to only enforce |
I think that |
|
Rebased, and fixed comment to mollify |
|
re ACK 1b2fb54d5c18579e013b1dfd061c2b29d8cffdc2 Reviewed up to acb6aaeac49dd4543280653f19d2377ffb175c9e and functional test |
|
ACK 1b2fb54d5c18579e013b1dfd061c2b29d8cffdc2 |
S3RK
left a comment
There was a problem hiding this comment.
Started re-review. Besides few nits, I have a doubt about waste calculation with bump fee and excess. Could you take a look, please?
murchandamus
left a comment
There was a problem hiding this comment.
Addressed @S3RK’s review
Follow-up from bitcoin#27021: In the prior commit, the vector started counting at 0, but the transaction names started with 1. This commit matches the names to the transactions’ vector indices for better readability. Co-authored-by: theStack <[email protected]>
Follow-up from bitcoin#27021. Also included is an ASCII art visualization of the test’s transaction topology by theStack. Co-authored-by: theStack <[email protected]>
Follow-up from bitcoin#27021
Follow-up from bitcoin#27021: accessing of fields in MiniMinerMempoolEntry was done inconsistently. Even though we had a getter, we would directly write to the fields when we needed to update them. This commits sets the fields to private and introduces a method for updating the ancestor information in transactions using the same method name as used for Mempool Entries.
GetSelectionWaste will need to access more context within a selection result, and so should be a private member function rather than a static function. It's only use outside of SelectionResult was for tests which have now been updated to just make a SelectionResult. Co-authored-by: Murch <[email protected]>
When a transaction uses an unconfirmed input, preceding this commit it would not consider the feerate of the parent transaction. Given a parent transaction with a lower ancestor feerate, this resulted in the new transaction's ancestor feerate undershooting the target feerate. This commit changes how we calculate the effective value of unconfirmed UTXOs. The effective value of unconfirmed UTXOs is decreased by the fee necessary to bump its ancestry to the target feerate. This also impacts the calculation of the waste metric: since the estimate for the current fee is increased by the bump fees, unconfirmed UTXOs current fees appear less favorable compared to their unchanged long term fees. This has one caveat: if multiple UTXOs have overlapping ancestries, each of their individual estimates will account for bumping all ancestors.
murchandamus
left a comment
There was a problem hiding this comment.
I pulled the part of the waste test that dealt with bump fees without group discount into the earlier commit and fixed an issue in the waste calculation in that commit. The final code is unchanged.
At the end of coin selection reduce the fees by the difference between the individual bump fee estimates and the collective bump fee estimate.
|
@S3RK noticed that I removed the obsolete method. |
|
ACK f18f9ef Great work! This PR not only makes our wallet work properly with unconfirmed inputs, but it also improved the factoring of the code. Happy to see waste calculations as a member function of |
|
@t-bast, @ismaelsadeeq, @achow101: Changes since 1b2fb54d5c18579e013b1dfd061c2b29d8cffdc2
|
|
ACK f18f9ef |
|
ACK f18f9ef |
Includes some commits to address follow-ups from #27021: #27021 (comment)
Reduces the effective value of unconfirmed UTXOs by the fees necessary to bump their ancestor transactions to the same feerate.
While the individual UTXOs always account for their full ancestry before coin-selection, we can correct potential overestimates with a second pass where we establish the ancestry and bump fee for the whole input set collectively.
Fixes #9645
Fixes #9864
Fixes #15553