# Second Look at Weak Blocks

**URL:** <https://delvingbitcoin.org/t/second-look-at-weak-blocks/805>\
**Category:** Implementation\
**Created:** [April 16, 2024, 4:51pm UTC](https://delvingbitcoin.org/t/second-look-at-weak-blocks/805 "2024-04-16T16:51:26Z")\
**Posts on this page:** 1\
**Showing post:** 21

<div class="post-metadata">

**Author:** ![Chris\_Stewart\_5](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/chris_stewart_5/32/296_2.png) [@Chris\_Stewart\_5](https://delvingbitcoin.org/u/Chris_Stewart_5)\
**Post date:** [June 19, 2024, 2:52pm UTC](https://delvingbitcoin.org/t/second-look-at-weak-blocks/805/21 "2024-06-19T14:52:39Z")

</div>

> for fee estimation

It seems to me if you have a latency sensitive transaction weak blocks could provide better fee estimation as it gives you a guarantee of transactions that are actively being hashed on by miners.

I concede your point for non latency sensitive transactions though.

> the idea is you only keep one or two weak blocks,

(From @instagibbs in the OP)

> How many blocks should we buffer?

How could you keep more than one weak block? Would these blocks be competing chain tips or blocks built on top of one another?

I think i conceptually understand how this would work if each weak block were competing chain tips.

I don’t understand how weak blocks could be built on top of each other - especially when receiving various weak blocks from a divergent set of miners across the p2p network?

Thanks in advance for clarification 🙌

---

_[View the full topic](https://delvingbitcoin.org/t/second-look-at-weak-blocks/805)._