rpc: add wtxid to mempool entry output

[sdaftuar]

We already cache this information in the mempool, so including it in the output of rpc calls is basically free.

[promag]

Ideally this change should affect some functional tests. IMO there should be a test that asserts the entry keys.

[instagibbs]

utACK 7e5d596

[sdaftuar]

@promag Added a test.

[luke-jr]

Should be "hash" (not "wxtxid") to be clear and consistent with the rest of the RPC interface.

[sdaftuar]

wtxid is defined in BIP 141. Perhaps we should fix the rest of the RPC interface instead (how many places do we return this currently?); hash seems less informative to me...

[luke-jr]

It's a hash of the transaction. It's not a transaction id. wtxid makes no sense.

[sipa]

@luke-jr Imagine that at some point a new piece of extra witness data gets added in a softfork way. At that point there will be 3 hashes; the txid, the hash-with-witness-but-not-witness2, and the hash-of-everything. If we have a field for "overall hash, with everything included", it will break software that knows about witnesses but not witness2.

So, while I don't care much about hash vs txid nomenclature, it makes sense to have a name that is segwit-specific. Just "hash" sets the wrong expectation going further, and given that BIP141 calls it wtxid, I think that's perfectly good choice.

[jonasschnelli]

utACK 617c459.

[luke-jr]

@sipa It would seem there are two things right now: txid and hash of the entire tx. If we add a third state, both of these things would remain the same. Hashes are opaque, so it's not like software can see it and fail to try to decode it...? What use case(s) do you have in mind?

[MeshCollider]

utACK 617c459, agree with sipa on the hash v. wtxid because I think consistency with BIP 141 is clearer

[sipa]

@luke-jr My point is that a "hash of all the data, regardless of what you think it contains" is not useful to anyone. It arbitrarily changes meaning as witnesses are added (if ever).

[promag]

Still missing tests for getrawmempool, getmempooldescendants and getmempoolancestors (with verbose=true) as these also use entryToJSON().

[sdaftuar]

@promag If you think that's important then I think it'd make more sense to have a separate test that checks the output of those rpc's to ensure they are consistent; I'm going to leave this PR alone.

[laanwj]

Is it guaranteed that the entry exists in mempool.vTxHashes? if not, using [] will potentially cause a leak by adding an empty record.

[sdaftuar]

Yes, it's guaranteed -- this is used in compact block reconstruction.

See CTxMemPool::removeUnchecked() and ::addUnchecked() for the code that keeps this in sync with the mempool entries.

[laanwj]

Thanks for the explanation, that makes sense.
Maybe we could add an assertion here assert(mempool.vTxHashes.count(e.vTxHashesIdx)), just in case. But I don't insist.

[sipa]

@laanwj vTxHashes is a vector - calling [] out of bounds doesn't add an empty record, it's just undefined behaviour.

[laanwj]

Oh, oops, never mind.