Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Prefer coins that have fewer ancestors, sanity check txn before ATMP #9262
This does a few extra possible runs of SelectCoinsMinConf, each with larger allowable mempool ancestor numbers, up to the acceptable mempool limit. As long as each input is not above this value, it passes. This means the sum of the history could actually be larger.
This is why I then catch the transaction at the end of CreateTransaction, and directly check. It simply fails, and does not retry. This logic is gated by a new command line argument
changed the title
Don't consider coins available if too many ancestors in mempool
Dec 2, 2016
Looks good! -- so, I think the additional test in "Don't return success" should be controlled by an option, since the failure is only temporary (at least once we fix the rebroadcast bug) and many callers handle failure to create a transaction poorly. I might even go as far as to suggest that this option be set in 0.13.2 to continue to create the transaction because that would be less of an API change. Perhaps @sdaftuar or @laanwj has an opinion on that?
Other than that, utACK.
Couple of fixes/changes:
so it actually filters correctly on the very last call of SelectCoinsMinConf.
I also revamped the tests to catch the various cases.
@gmaxwell we'll have to catch that logic in two places, SelectCoinsMinConf(at the last instance of it) and at the end of CreateTransaction. I suppose once rebroadcasting is fixed, we can set the default to "false" and let it take care of it. I'll wait to see what others are thinking. I think current behavior is horrendous :)
@gmaxwell No strong opinion on the issue of default behavior for 0.13.2, but given that you currently have to restart your node in order to rebroadcast, I'd lean towards making the default behavior be to enforce this new restriction, rather than create a tx that doesn't make it to the mempool.