getrawmempool verbose mode should return “size” and “disksize” for segwit transactions #11218

1. 
   junderw commented at 10:27 am on September 2, 2017: contributor

   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:

   1. Run getrawmempool with verbose set to true
   2. Notice it only gives size

   Expected behaviour

   It should show:

   1. effective feerate “size” (ceil(weight/4))
   2. disk size “disksize” (total number of bytes in the serialized segwit transaction. (since “disksize” and “size” will be equal for non-segwit transactions, “disksize” should only appear for segwit transactions)

   Actual behaviour

   It shows size only (effective size for fees ceil(weight/4))

   Screenshots.

   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?

   0.14.2

2. fanquake added the label RPC/REST/ZMQ on Sep 2, 2017
3. 
   sipa commented at 7:04 pm on September 2, 2017: member

   The only thing that counts towards the block limit (and by extension, what matters for feerate) is vsize. That’s also what is reported, as it’s the only thing the mempool cares about.
4. 
   junderw commented at 10:17 am on September 3, 2017: contributor

   I guess I’ll take that as an “out of scope” response. The mempool only cares about vsize, so “size” is always vsize… makes sense.

   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.

5. junderw renamed this:
   getrawmempool verbose mode should return "size" "vsize" (or weight) and "bsize"
   getrawmempool verbose mode should return "size" and "disksize" for segwit transactions
   on Sep 3, 2017
6. 
   sdaftuar commented at 12:54 pm on September 6, 2017: member

   I’m skeptical of disksize being a useful quantity, because that is implementation specific and not protocol-enforced; for instance if we implemented compression to store the transaction on disk, would we then return a smaller value for disksize?

   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.

7. 
   sipa commented at 4:21 pm on September 6, 2017: member

   Perhaps we should however rename the “size” field to “vsize” there, for consistency?
8. 
   FelixWeis commented at 4:40 pm on November 9, 2017: contributor

   +1 renaming it vsize

   maybe +/-0.5 splitting it to weigth and adding disksize

9. 
   jnewbery commented at 8:51 pm on March 27, 2018: member

   Agree that we should rename size -> vsize (perhaps behind deprecation flag).

   There’s a PR to expose transaction weight in getrawtransaction here: #12791. Perhaps we could do the same for getrawmempool

   No need for disksize IMO.

   Suggest tagging this as ‘good first issue’

10. MarcoFalke added the label good first issue on Mar 27, 2018
11. MarcoFalke referenced this in commit e14cd04abb on Mar 26, 2019
12. 
    hebasto commented at 9:21 am on April 25, 2019: member

    Is this still an issue?
13. 
    junderw commented at 9:43 am on April 25, 2019: contributor

    No. It’s fine.
14. junderw closed this on Apr 25, 2019

    ---

15. vijaydasmp referenced this in commit 68c792220a on Oct 5, 2021
16. vijaydasmp referenced this in commit 72b7ecd663 on Oct 12, 2021
17. vijaydasmp referenced this in commit 7627e2b014 on Nov 10, 2021
18. vijaydasmp referenced this in commit 893504beeb on Dec 5, 2021
19. vijaydasmp referenced this in commit 68c20f08c1 on Dec 6, 2021
20. vijaydasmp referenced this in commit 7b82200393 on Dec 6, 2021
21. vijaydasmp referenced this in commit 4b95057642 on Dec 13, 2021
22. vijaydasmp referenced this in commit 6f422f961a on Dec 13, 2021
23. DrahtBot locked this on Dec 16, 2021

Contributors
junderw sipa sdaftuar FelixWeis jnewbery hebasto

Labels
RPC/REST/ZMQ good first issue