Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
getrawmempool verbose mode should return "size" and "disksize" for segwit transactions #11218
Describe the issue
getrawmempool verbose mode only returns "size" rather than "size" and "disksize" (the size on disk for segwit transactions)
Can you reliably reproduce the issue?
If so, please list the steps to reproduce below:
It should show:
It shows size only (effective size for fees ceil(weight/4))
If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.
What version of bitcoin-core are you using?
I guess I'll take that as an "out of scope" response.
However, this is a "verbose" mode which imo should "give as much information as possible so the user/coder can decide what's useful and what's not"...
In regards to segwit transactions, the only missing info regarding the possible effect on the blockchain (for sites looking to record or watch these statistics) is how much disk space it will take up.
Thinking it through. You would only really need 2 of the 3, and the other one can be calculated.
Perhaps segwit transactions can have an extra key which is "disksize"... since non-segwit disksize == size, it can be removed.
I'm skeptical of
Perhaps you mean "serialized size", which is well-defined because the serialization is part of the protocol, but we don't cache this in the mempool because we don't need it for anything. I'd prefer not to cache this in the mempool to avoid wasting memory, and I'm not sure it's worth reserializing the mempool contents to calculate this value whenever a user calls getrawmempool, because that rpc is already slow enough, and I don't know what the use case here would be... Note that users can always calculate the serialized size themselves by asking for the serialized transaction directly, eg with getrawtransaction.
Agree that we should rename
There's a PR to expose transaction weight in
No need for disksize IMO.
Suggest tagging this as 'good first issue'