<p>...given that one can be derived from the other? Surely the unsigned integer of height would be sufficient without the addition uint64_t of the time (to the second), wouldn't it?</p>

CC BY-SA 4.0
2021-10-20T15:14:32.447Z
I don't see how one can be computed from the other, in either direction. Entry time has higher accuracy than blocks, and Bitcoin Core doesn't have a log of what the height of our active chain was at every local timestamp.
Pieter Wuille
CC BY-SA 4.0
2021-10-21T22:28:56.010Z
well, it  easily could - and it would take up less memory than storing the entry height for every single tx in the mempool

or why not use the timestamp in the block index?
Rebroad
CC BY-SA 4.0
2021-10-21T23:08:48.663Z
We care about the actual time, not the time that miners choose to put in block headers (which may be up to 2 hours in the future, or roughly an hour in the paat)
Pieter Wuille
CC BY-SA 4.0
2021-10-23T12:03:22.833Z
ah, fair point, well, in that case the time could be stored in the mempool, and the height could be derived from that - one entry of height per block, rather than per mempool entry
Rebroad
<unconfirmed-transactions><mempool><memory>
Why does Bitcoin Core store the block height and the time of each transaction in the memory pool?
Rebroad
# Why does Bitcoin Core store the block height and the time of each transaction in the memory pool?

(Asked by: username_0 on 2021-10-20)

...given that one can be derived from the other? Surely the unsigned integer of height would be sufficient without the addition uint64\_t of the time (to the second), wouldn't it?

**Tags:** unconfirmed-transactions, mempool, memory

> **Comments:**
> **username_1**: I don't see how one can be computed from the other, in either direction. Entry time has higher accuracy than blocks, and Bitcoin Core doesn't have a log of what the height of our active chain was at every local timestamp.  
> **username_0**: well, it  easily could - and it would take up less memory than storing the entry height for every single tx in the mempool  or why not use the timestamp in the block index?  
> **username_1**: We care about the actual time, not the time that miners choose to put in block headers (which may be up to 2 hours in the future, or roughly an hour in the paat)  
> **username_0**: ah, fair point, well, in that case the time could be stored in the mempool, and the height could be derived from that - one entry of height per block, rather than per mempool entry  

---

## 0 answers

