Seeking Feedback on a 2106 Overflow Solution Called BitBlend \ stacker news ~bitdevs

Dear Bitcoin Development Community,

I am reaching out to share a solution I have developed to address the anticipated 2106 overflow issue. After a significant development period, I believe the solution is ready for a community review.

Below, you will find an abstract summarizing the key aspects of this proposal, which is titled "BitBlend:A Non-Disruptive Solution to the Bitcoin 2106 Timestamp Overflow.” The abstract aims to provide a concise overview of the solution's approach and objectives. For a more detailed understanding, I have also included a link to the full white paper hosted on GitHub.

Abstract:

The Bitcoin network faces a significant technical challenge as it approaches the year 2106, when the 32-bit field for block timestamps will reach its maximum value. This paper introduces "BitBlend," a solution designed to address this impending overflow without necessitating a coordinated hard fork or consensus change. Similar to the idea by Pieter Wuille [2], BitBlend proposes a novel reinterpretation of the existing 32-bit time field, extending its functionality by representing only the last 32 bits of the full timestamp. The solution incorporates an innovative overflow detection and correction method, named the BitBlend procedure, which seamlessly integrates into the current system. Key to BitBlend is maintaining the original 32-bit format for external communication while employing a 64-bit internal representation for block times. This dual approach ensures backward compatibility and network continuity, allowing nodes to gradually adopt the update without synchronization. Additionally, BitBlend addresses the implications for time locks, advocating for the natural expiration of absolute time locks post-2106 and the continued use of block height and relative time locks. This solution prioritizes minimal alterations to Bitcoin's core components, striving to preserve its foundational principles while ensuring its longevity and functionality. The paper seeks feedback from the Bitcoin development community on the feasibility and potential integration of the BitBlend solution into the Bitcoin protocol.

Link to Full White Paper: https://bitblend2106.github.io/bitcoin/BitBlend2106.pdf

I would greatly appreciate any thoughtful reviews, comments, or suggestions you may have regarding the BitBlend solution.

Thank you for your time and consideration. I look forward to your valuable input.

100 sats \ 0 replies \ @netstatic 17 Jan

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.