pull down to refresh

100 sats \ 0 replies \ @netstatic 17 Jan \ on: Seeking Feedback on a 2106 Overflow Solution Called BitBlend bitdevs
In the situation where both upgraded and non-upgraded nodes coexist in the network at the overflow event in 2106, the non-upgraded nodes will cease to function, unable to process blocks with timestamps exceeding the 32-bit maximum
I don't understand how this is better than existing methods. This will cause a hard fork when old nodes inevitably stop recognizing the lower valued timestamps of the overflow blocks.
The future proofing without the need to store enumerated epochs makes BitBlend an improvement over similar solutions offered by Pieter Wuille [2] and Yanmaani [3].
This paper is way too verbose for a proposal aiming to reduce 32-64 bits of storage per block (the amount of space taken by Yanmaani's proposed 'k') or a lot less if the scheme is implemented cleverly.
With respect to Pieter Wuille's solution it doesn't seem much different besides the inclusion of the Median Time Past* (incorrectly referred to as Median Past Time in your writeup) in the ambiguously defined 'blend' operation.
write
preview