# V3 and some possible futures

**URL:** <https://delvingbitcoin.org/t/v3-and-some-possible-futures/523>\
**Category:** Protocol Design\
**Created:** [February 6, 2024, 6:11pm UTC](https://delvingbitcoin.org/t/v3-and-some-possible-futures/523 "2024-02-06T18:11:07Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![glozow](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/glozow/32/261_2.png) [@glozow](https://delvingbitcoin.org/u/glozow)\
**Post date:** [February 7, 2024, 5:16pm UTC](https://delvingbitcoin.org/t/v3-and-some-possible-futures/523/2 "2024-02-07T17:16:12Z")

</div>

I like the style of v3.1 and v4.1c, i.e. “you have restricted topology unless you’re creating something that’s ‘top block.’” I think it’s a good example of what relaxations can happen: from “you want to be in the fast lane so you can’t be too complex/big because then we don’t know if you’re still fast” to “you want to be in the fast lane so you can only be complex/big if you’re still fast”.

I am concerned about the (in)ability to support sibling eviction in 3.1, though. From previous discussion, it seems pretty intractable trying to support it for \>2 clusters.

---

_[View the full topic](https://delvingbitcoin.org/t/v3-and-some-possible-futures/523)._