Implement auto-fee leveling when spending unconfirmed outputs #15553

1. 
   gmaxwell commented at 0:47 am on March 7, 2019: contributor

   Right now if a user makes a low feerate payment then later makes a higher feerate payment that spends the unconfirmed output from the prior payment the wallet is just completely blind to the prior low feerate.

   This can contribute to long unconfirmed chains forming when the necessary feerates go up because later payments, though paying a higher rate, don’t pay enough to pull their ancestors up to their target rate.

   Instead, we should probably reduce the effective value of unconfirmed outputs by the amount needed to bring them up to the target feerate, and increase fees by that much, so that when a feerate of x s/b is set, the actual effect rate delivered is actually x s/b.

2. fanquake added the label TX fees and policy on Mar 7, 2019
3. 
   promag commented at 0:06 am on March 23, 2019: member

   the actual effect rate delivered is actually x s/b.

   Makes sense. In a way it would promote CPFP right?

4. 
   xaaaak commented at 9:31 am on May 6, 2019: none

   But how to send unconfirmed transaction? ‘sendmany’ with ‘minconf 0’ is not working.
5. 
   Sjors commented at 8:52 am on August 2, 2019: member

   Concept ACK.

   We should not automatically pay for previous transactions from strangers. However our wallet only spends our own unconfirmed change, so there’s no abuse risk here.

   There is risk of confusion when the total fee is higher than a user would expect, but the total fee already varies as a result of coin selection.

   In the GUI we can make it clear in the send screen, when a user selects a fee rate, that the total fee includes compensation for n parent transactions. Currently the expected confirmation time displayed in the GUI is plain wrong if there’s a parent.

   In the RPC we could make this new behavior clear in the documentation.

6. 
   instagibbs commented at 2:41 pm on August 13, 2019: member

   One issue is that we have a mixed bag of coin selection, BnB which uses effective value, and the legacy “loop” one which does not. In the loopy setup we’d have to just make sure that the nFeeNeeeded goes up by the proper fee amount IFF that unconfirmed output is selected.
7. 
   murchandamus commented at 8:01 pm on June 24, 2021: contributor

   Concept ACK

   The additional cost of bumping the parent should be taken into account when calculating the effective value of the unconfirmed UTXO. This would additionally dissuade selection of UTXOs with low fee rate parent transactions, especially when we start preferring coin selection results with a lower waste as proposed in #22009.

   I am goint to take a stab at implementing the auto-fee leveling.

8. 
   t-bast commented at 12:53 pm on June 13, 2022: contributor

   @Xekyo were you able to make some progress on this? More people are realizing this limitation and hitting this in the wild, is this still being actively worked on? Is there a more detailed discussion about this somewhere else?
9. 
   murchandamus commented at 8:56 pm on June 14, 2022: contributor

   Sorry for the slow progress. @glozow implemented an interface so that we can access mempool information about unconfirmed ancestor transactions and my next step is to use this information in the waste metric and coinselection functions. I aspire to have a PR by the end of the month.
10. 
    t-bast commented at 7:00 am on June 15, 2022: contributor

    Great, thanks to you both!
11. 
    murchandamus commented at 7:55 pm on June 15, 2022: contributor

    @t-bast, I got a branch here: https://github.com/Xekyo/bitcoin/commits/2022-06-ancestor-aware-funding, but PR is still pending
12. achow101 closed this on Sep 14, 2023

    ---

Contributors
gmaxwell promag xaaaak Sjors instagibbs murchandamus t-bast

Labels
TX fees and policy