Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
[RPC] Expose ancestor/descendant information over RPC #7292
Conversation
sdaftuar
referenced this pull request
Jan 4, 2016
Merged
RPC: Indicate which transactions are signaling opt-in RBF #7222
|
Concept ACK |
|
Concept ACK. |
jonasschnelli
added
the
RPC/REST/ZMQ
label
Jan 5, 2016
|
Updated to remove dead code I inadvertently left in |
|
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). |
|
Ultra nit before reading the code: it's not obvious from the RPC names that
it's about the mempool.
|
|
Updated with new RPC names ( |
|
Any reason not to just add the ancestors/descendants info to getrawmempool (and also the getmempoolentry)? |
|
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 (edited) |
|
@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 |
|
Concept ACK |
|
Needs rebase. |
|
Rebased. There weren't any actual conflicts though, so not sure why github thought it wouldn't merge cleanly? |
|
Thanks! |
added a commit
to luke-jr/bitcoin
that referenced
this pull request
Feb 13, 2016
added a commit
to luke-jr/bitcoin
that referenced
this pull request
Feb 13, 2016
added a commit
to luke-jr/bitcoin
that referenced
this pull request
Feb 13, 2016
added a commit
to luke-jr/bitcoin
that referenced
this pull request
Feb 13, 2016
added a commit
to luke-jr/bitcoin
that referenced
this pull request
Feb 13, 2016
sdaftuar
referenced this pull request
Feb 24, 2016
Merged
Mempool: Add tracking of ancestor packages #7594
|
Rebase needed. |
|
Rebased. Also added a commit that extends the mempool entry output to include the ancestor state (added by #7594), as well as a brief update to the release notes. |
jonasschnelli
commented on an outdated diff
May 17, 2016
| + return o; | ||
| + } | ||
| +} | ||
| + | ||
| +UniValue getmempooldescendants(const UniValue& params, bool fHelp) | ||
| +{ | ||
| + if (fHelp || params.size() < 1 || params.size() > 2) { | ||
| + throw runtime_error( | ||
| + "getmempooldescendants txid (verbose)\n" | ||
| + "\nIf txid is in the mempool, returns all in-mempool descendants.\n" | ||
| + "\nArguments:\n" | ||
| + "1. \"txid\" (string, required) The transaction id (must be in mempool)\n" | ||
| + "2. verbose (boolean, optional, default=false) true for a json object, false for array of transaction ids\n" | ||
| + "\nResult (for verbose=false):\n" | ||
| + "[ (json array of string)\n" | ||
| + " \"transactionid\" (string) The transaction id of an in-mempool descendant transaction\n" |
|
|
|
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. |
|
Fixed @jonasschnelli's nits. No idea how these changes could affect the unit tests on any platform; the travis failure seems disturbing... |
paveljanik
commented on an outdated diff
May 17, 2016
| @@ -292,6 +292,70 @@ UniValue getrawmempool(const UniValue& params, bool fHelp) | ||
| return mempoolToJSON(fVerbose); | ||
| } | ||
| +UniValue getmempoolancestors(const UniValue& params, bool fHelp) | ||
| +{ | ||
| + if (fHelp || params.size() < 1 || params.size() > 2) { | ||
| + throw runtime_error( | ||
| + "getmempoolancestors txid (verbose)\n" | ||
| + "\nIf txid is in the mempool, returns all in-mempool ancestors.\n" | ||
| + "\nArguments:\n" | ||
| + "1. \"txid\" (string, required) The transaction id (must be in mempool)\n" | ||
| + "2. verbose (boolean, optional, default=false) true for a json object, false for array of transaction ids\n" | ||
| + "\nResult (for verbose=false):\n" | ||
| + "[ (json array of string)\n" |
|
|
|
ACK 170bfea |
|
Pushed a fix to address @paveljanik's nit |
|
Unit tests are now failing on linux. I'll see if I can reproduce locally. |
|
Oh, I suppose it could be this: #8069 (comment) |
|
Looks like the travis issue was fixed by #8070, so I think this is ready now. |
|
reACK 5379307 |
|
utACK 5379307 |
|
Can one of the admins verify this patch? |
|
utACK 5379307a23177c33b5a869513d1d1d09790b0269 |
|
Is there anything holding this up? |
|
Can you squash the typo? |
sdaftuar
added some commits
Jan 4, 2016
|
@sipa done |
|
utACK 176e19b (same tree as before) |
sdaftuar commentedJan 4, 2016
This adds 3 new RPC calls (
getancestorsgetmempoolancestors,getdescendantsgetmempooldescendants, getmempoolentry) to expose more mempool information over RPC.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.