feerate not taking into consideration that of unspent parents #9645

1. 
   FrozenPrincess commented at 5:23 pm on January 27, 2017: none

   Certain actions (sendtoaddress, sendmany, fundrawtransaction) will sometimes source unconfirmed inputs, especially trusted ones. However the resultant transaction doesn’t appear to be taking into consideration the feerate of the overall mempool “ancestoral feerate”. I believe the desired behavior would be that it transparently does “child pays for parent” on any unconfirmed inputs it happens to source so the overall feerate is what ever the target is
2. fanquake added the label TX fees and policy on Jan 28, 2017
3. 
   morcos commented at 7:46 pm on February 6, 2017: member

   This is an idea we’ve discussed before. There are a couple of complications.

   • If the transaction has multiple low fee parents the resultant increase in total fee paid could be substantial.
   • Now imagine that you place a second transaction which spends other outputs from those same parents. You will end up “paying for the parent” again, which is likely not necessary any more.

   I think in the GUI it should be possible to design a smarter system that warns you that the ancestor fee rate of the transaction you are about to place is lower than what is indicated by fee estimation. And even give you an option to bump it higher to pay for parents (while showing you how much extra fee this is and warning you that you might be paying for the parents multiple times). But without this extra level of user interaction, it’s not clear to me how you would do this from the RPC API.

4. 
   FrozenPrincess commented at 8:10 pm on February 6, 2017: none

   If the transaction has multiple low fee parents the resultant increase in total fee paid could be substantial.

   If you’re using unconfirmed outputs, this is probably a big improvement though

   Now imagine that you place a second transaction which spends other outputs from those same parents. You will end up “paying for the parent” again, which is likely not necessary any more.

   It’s annoying to code, but I don’t think it’s a theoretical problem. When considering the fee rate of a transaction, you can compute it with awareness of other transactions that spend from it. Actually I already have code that is already doing this in production by querying bitcoin with getmempoolentry and looking at all its ancestors and children.

   Looking at my logic it takes me O(n^2) time to compute the fee rate of a transaction, where n = how many unconfirmed transactions are in the graph. I’m not that that would ever be a problem, but I’m sure someone smarter than me could make it linear time too

5. 
   Sjors commented at 3:22 pm on March 16, 2018: member

   See also #9864
6. 
   MarcoFalke commented at 7:24 pm on May 8, 2020: member

   Duplicate with #15553 ?
7. 
   murchandamus commented at 8:04 pm on June 24, 2021: contributor

   @morcos: I think I have a viable approach how to correctly assess the fees for complex ancestries with lower feerate. @MarcoFalke: yeah, this is a duplicate of #15553.
8. MarcoFalke closed this on Aug 22, 2022

   ---

9. bitcoin locked this on Aug 22, 2023

Contributors
FrozenPrincess morcos Sjors MarcoFalke murchandamus

Labels
TX fees and policy