ethereum · etan-status · Apr 1, 2024
@@ -0,0 +1,118 @@
+---
+eip: 7671
+title: Bitcoin Proof-of-Stake
+description: Bitcoin transition from Proof-of-Work to Proof-of-Stake
+author: Etan Kissling (@etan-status)
+discussions-to: https://ethereum-magicians.org/t/eip-7671-bitcoin-proof-of-stake/19477
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-04-01
+---
+
+## Abstract
+
+This EIP defines a voluntary mechanism for transitioning Bitcoin to Ethereum's Proof-of-Stake mechanism.
+
+## Motivation
+
+Regardless of one's opinion about climate change, Bitcoin consumes a significant amount of power that could be used for other computations. Furthermore, a handful of Bitcoin miners control a significant portion of hash power, making it less decentralized than originally envisioned.
+
+Ethereum has a similar focus on decentralization than Bitcoin, both networks can be run on commodity hardware down to single-board computers. Therefore, it is practical to run Bitcoin side-by-side with Ethereum on the same hardware. Provided that node operators are willing to do that, it becomes possible to replace the Bitcoin Proof-of-Work system with Ethereum's Proof-of-Stake system while keeping Bitcoin's core values intact.
+
+Namely, the following aspects are not affected by this EIP:
+
+- Supply cap: Bitcoin retains its 21 million BTC supply cap
+- Block duration: Bitcoin retains its 10 minute average block timing
+- Data structures: Bitcoin retains its data structures and APIs
+- Independent syncing: Syncing a Bitcoin node will not require running an Ethereum full node
+
+The only aspect that is proposed to be changed is the validity rule of a block. Instead of the hash having to meet a certain compute difficulty for a block to be valid (Proof-of-Work), it is now assumed valid when a majority of Ethereum validators vote for it to be valid (Proof-of-Stake). This frees up the electricity used to compute Proof-of-Work for other compute tasks, such as Machine Learning, Artificial Intelligence, or Big Data algorithms.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+The specification is defined in multiple stages building on top of each other. Later stages can be refined as earlier stages are achieved.
+
+### Stage 1: Determining community interest and feasibility
+
+First, Ethereum node operators need to show interest in providing the necessary infrastructure for Bitcoin. Node operators are encouraged to run a Bitcoin node side-by-side next to their Ethereum node, and SHOULD voice their support or concerns with this EIP. This stage determines the willingness by the community to follow through with this EIP, as well as determines feasibility to run on a wide selection of hardware.
+
+### Stage 2: Signalling support in Ethereum blocks
+
+Ethereum beacon node software SHALL be updated to support fetching the latest head of the Bitcoin blockchain as part of the block proposal flow. For node operators who opted in to supporting this EIP, beacon node software SHALL include a partial hash in the graffiti, attesting to that head.
+
+The graffiti SHALL follow this format: 24 bytes of user-defined content, followed by 3 bytes representing the Bitcoin Sign ₿ (U+20BF) in UTF-8 encoding (`0xe282bf`), followed by the last 5 bytes of the latest Bitcoin block hash in binary form.
+
+```
+012345678901234567890123|45678901 (32 bytes total)
+User-defined portion    | ₿ ABCDE
+```
+
+Ethereum block explorer software SHOULD identify these blocks and visualize whether they vote for a recent Bitcoin block around the time that the block was produced. Note that there are no consensus validation rules that ensure correctness of the block hash in this stage, this solely indicates support for this EIP in a more formal way.
+
+Furthermore, Ethereum block explorer software SHOULD track and report the percentage of blocks attesting to a recent valid Bitcoin block over time.
+
+### Stage 3: Signalling support in Bitcoin blocks
+
+When >= 30% of produced Ethereum blocks over a sliding 4-week period (`6*24*7*4` = 4'032 blocks) indicate support for this EIP by including a valid Bitcoin block hash in their graffiti, a Bitcoin Improvement Proposal (BIP) SHALL be created defining a version bit that represents support by miners to eventually transition to Ethereum Proof-of-Stake.
+
+As Bitcoin miners would eventually surrender control over Bitcoin by supporting this EIP, it is not required for them to extend their infrastructure with Ethereum nodes. The version bit is used voluntarily and solely indicates interest in progressing this EIP. It is not used to transition the network to Proof-of-Stake.
+
+### Stage 4: User-activated hard fork
+
+When more than 30% of produced Bitcoin blocks over a sliding 4-week period indicate support for this EIP by including the version bit from stage 3 in their block version, it is concluded that there is significant interest by both Ethereum node operators and Bitcoin miners to formalize the transition to Proof-of-Stake.
+
+Formal specifications SHALL be defined and implemented across both Ethereum and Bitcoin clients, to support a permanent API similar to the `engine` API that is used for Ethereum's own Proof-of-Stake mechanism to inform the Bitcoin implementation software about new blocks, to update its head, and to produce new blocks. This API is used after the transition to Proof-of-Stake and replaces Proof-of-Work.
+
+An additional Bitcoin version bit SHALL be defined for Bitcoin to signal readiness for the transition to Proof-of-Stake. When >= 85% of Bitcoin blocks over a sliding quarter year / 13-week period (`6*24*7*13` = 13'104 blocks) signal readiness, the following two consensus changes SHALL be activated on Bitcoin:
+
+1. Blocks without signalling the additional Bitcoin version bit SHALL be deemed invalid, regardless of their block hash. All Bitcoin blocks MUST continue signalling the additional Bitcoin version bit.
+2. The current Bitcoin difficulty SHALL be used to compute a projected terminal total difficulty value in another 84'672 blocks. Proof-of-Work SHALL continue until the terminal total difficulty value is hit, after which blocks are produced using the `engine` API.
+
+An Ethereum proposer is elected to be a potential Bitcoin proposer using a selection proof, reusing a similar mechanism as for selecting aggregators for attestations or contributions for sync committee messages. The selection proof is adapted to target an average rate of 10 minutes. The configuration
+
+An Ethereum proposer that is elected as a Bitcoin proposer for a given slot MAY produce a Bitcoin block. Ethereum block proposers will receive Bitcoin rewards at the selected `coinbase` destination of their produced Bitcoin block according to the Bitcoin protocol. There is no interaction with Ethereum besides providing the consensus infrastructure. The economic model of Bitcoin is not altered. If the Ethereum block proposer chooses not to produce a Bitcoin block, any rewards to it are forfeited, and Bitcoin's state remains unchanged.
+
+Ethereum validators SHALL only attest to blocks that contain a Bitcoin block if the selection proof is valid, and if the Bitcoin `engine` API indicates that the Bitcoin block is valid. This is in line with how Ethereum honest validator specifications are defined for Ethereum's execution engine.
+
+As Bitcoin miners have invested significant resources into their operations, the `coinbase` recipient of the final 13'104 blocks leading to the computation of the terminal total difficulty is collected, and filtered to only include `coinbase` recipients that signalled readiness for Proof-of-Stake. This results in a list of 11'139 (85%) - 13'104 (100%) `coinbase` recipients.
+
+Ethereum consensus rules are extended to select the `coinbase` recipient for new Bitcoin blocks from this list of recipients in a round-robin way, until each entry was selected 4 times. This guarantees that existing Bitcoin miners will receive a compensation similar to their current revenue within the first ~year of the transition to Proof-of-Stake, while they can wind down mining operations and liquidate their existing mining equipment. After every `coinbase` recipient from the initial list was selected 4 times, Ethereum block proposer MAY freely choose a `coinbase` recipient.
+
+### Stage 5: Supporting infrastructure
+
+The Ethereum light client protocol SHALL be extended to also provide the latest Bitcoin block header. The fork schedule SHALL be signed by the sync committee so that regular software updates to the light client software are not needed with every new fork. Light client data SHALL be made available in a format and network location convenient for Bitcoin.
+
+Bitcoin implementations SHOULD integrate the Ethereum light client protocol to support tracking the latest Bitcoin header without requiring Bitcoin node operators to run an Ethereum full node.
+
+## Rationale
+
+### Why assist Bitcoin in this transition?
+
+Proof-of-Stake systems require incentives to promote honest validator behaviour. Adding such incentives on Bitcoin itself is incompatible with its current economic model that is built on a fixed maximum supply of 21 million BTC.
+
+### Why Ethereum and not a different blockchain?
+
+Ethereum has similar principles as Bitcoin regarding decentralization and shares the same low hardware requirements. Ethereum's architecture with split consensus and execution layers allows a clean integration of Bitcoin without affecting either of the networks. Conceptually, Bitcoin simply becomes a second execution layer. Furthermore, Ethereum is a blockchain with high maturity and has proven itself to be among the most resilient and reliable blockchains available.
+
+### Finality
+
+With Proof-of-Stake, Bitcoin will get a concept of finality beyond which transactions cannot be reverted unless one third of all Ethereum balance gets slashed. This makes interactions on exchanges and bridges faster, as they no longer need to wait for N confirmations but only need to typically wait for 2 epochs (~12 minutes) to get finality. This is the same concept for Ethereum itself, and may further improve with other research such as single-slot finality (< 30 seconds).
+
+## Backwards Compatibility
+
+This change is not backwards compatible and requires a hard fork to introduce on both Bitcoin and Ethereum.
+
+As backwards compatibility is among the core methodologies of Bitcoin (see how Segregated Witness were implemented), it is essential to respect that as far as possible. On Bitcoin, the proposed changes only affect the validity rule of block hashes in a backwards incompatible ways. Furthermore, the light client component that tracks the signatures for the latest block header on the Ethereum network is proposed to be forward compatible so that after this one-time transition, no software updates are needed to continue to operate Bitcoin.
+
+## Security Considerations
+
+Proof-of-Stake systems have different security considerations than Proof-of-Work. Namely, they introduce the concept of a weak subjectivity period. To be secure, syncing must start during this rolling period, or must use trusted bootstrap nodes that ensure that the canonical history is provided. These security properties are unrelated to Bitcoin, they are the same for Ethereum itself and need to be taken into account when deciding on support for this EIP.
+
+Split consensus/execution blockchains trust the execution layer to validate execution payloads before attesting to their validity. If there is a bug in an execution implementation with a supermajority adoption, an invalid execution payload may get finalized. As finality cannot be reverted without intervention, it is vital that no implementation reaches a supermajority adoption. With Bitcoin becoming an additional execution layer, it may be necessary to develop alternative Bitcoin full node implementations other than Bitcoin Core to significantly reduce the security risk of finalizing an invalid chain.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).