Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[RPC] Expose ancestor/descendant information over RPC #7292
This adds 3 new RPC calls (
Now that we have policy rules that are tied to transaction chains (including limits on the number of in-mempool ancestors and in-mempool descendants, and mempool eviction and RBF policies that depend on fees of descendants), it seems helpful to be able to expose more information about the chains a given tx is part of over RPC.
This is motivated by the discussion in #7222. @petertodd You mentioned wanting to see specific use-cases for this information; I think there are clear improvements to the fee-bumping tools in your replace-by-fee repo that could be made if we had these functions (the first two tools I looked at just now don't seem to consider transaction chains at all in fee calculations?). I'll try to post a link in this PR to specific proposed improvements when I have something to share that will demonstrate this more clearly.
referenced this pull request
Jan 4, 2016
Here's an example of a tool that would benefit from the getdescendants function:
This is a script that takes two txid's (that are signaling opt-in RBF) and combines them down to one -- consolidating duplicate output addresses (if any) and removing pay-to-self outputs, assumed for demo purposes to be change outputs -- and paying for all fees including those of descendants. The main idea is that this avoids over-paying for descendants -- it calls getdescendants on each transaction and takes the union of the two sets so that each descendant is paid for once. I don't know any simple or straightforward way to do this without this new RPC call.
There are similar benefits to having getancestors, such as if you wanted to understand why a stuck transaction wasn't confirming, then getancestors would give you the set of unconfirmed parents to look at (and you could write a replace-by-fee-tool that was smart enough to drop an input coming from a stuck unconfirmed parent, when possible, to replace a transaction with one likely to confirm sooner; or better still, replace such a stuck parent instead if possible).
The goal was to avoid having to dump the entire mempool if you were only interested in a very small subset of it. But I suppose there's no reason we couldn't also show the txid's of ancestors and descendants when you call
@luke-jr On further thought, the downside to that is that doing the calculation could cause
The other possibility would be to add a new option to
I don't know why Travis WIN32 fails on the unit tests (sadly, It seems that the unit-test log is missing in the travis dump).
Tested ACK 69c9553586befdbc9ca6a474ae294bebe998163b modulo nits.