Where does the 33.33% threshold for selfish mining come from?

The process of achieving secure consensus in distributed systems, particularly in blockchain technology, often hinges on the notion that a simple majority (51% hashrate) is not sufficient for genuine security. Instead, a more robust 66.67% majority is typically required due to several underlying conditions that must be met to ensure the integrity and reliability of consensus mechanisms. These conditions include the synchronization of honest clocks to a fraction of the consensus round duration, the inclusion of timestamps on all consensus-related messages, and the necessity for all messages to be digitally signed. The digital signing of messages is a critical component that many consensus schemes overlook; for instance, Bitcoin relies on computationally expensive hashes to fulfill this role, deviating from the ideal requirement.

Bitcoin, as a case study, illustrates the challenges associated with maintaining a strict adherence to these conditions. It fails to meet the first two criteria by allowing timestamps that can be significantly ahead or behind the current time—far beyond the scope of a single consensus round, which is equivalent to the time it takes to mine one block. This leniency towards timestamp ranges undermines the potential for achieving a more secure consensus process.

A proposed solution to mitigate such issues involves enforcing stricter regulations on timestamp validity. By requiring that timestamps be within a narrow window of actual time (e.g., ±5 seconds, with an additional 2-second allowance for propagation delays), blocks that do not comply could be temporarily placed in a "timeout" status. This timeout would last for the duration of one block time, providing an opportunity for proof-of-work (PoW) to rectify any discrepancies caused by network partitions or similar disruptions. This measure would effectively deter selfish mining practices by eliminating the possibility for miners to preemptively assign timestamps without knowing when they will publicly release their blocks.

Furthermore, the article elucidates on the vulnerabilities associated with consensus processes, emphasizing how a minority (less than 33.33%) can disrupt consensus by either misrepresenting the content or timing of messages. This highlights a fundamental weakness in less stringent consensus models, showcasing the intricate balance between operational flexibility and system security within blockchain networks.