consensus: RFC for hard-fork PoS transition, PQ wallet support, and one-time subsidy recovery #35611

Summary

This issue proposes a research discussion for a possible Bitcoin Core consensus transition path intended to address two long-term risks:

1. Post-quantum signature risk for future wallet/block validation designs.
2. Long-term block production after a proposed Proof-of-Work shutdown height/timestamp.

This is not presented as a ready-to-merge change. It is a request for technical review, criticism, and guidance on whether such a proposal should first be developed as a BIP and discussed on the bitcoin-dev mailing list.

Proposed high-level changes

The proposal contains four major components:

1. Proof-of-Work shutdown after activation

After a defined mainnet activation height/timestamp, normal Proof-of-Work block production would stop being the active block-production mechanism.

Old nodes would remain usable before activation, but after activation this would necessarily be a hard fork because older nodes would continue enforcing existing Proof-of-Work consensus rules.

2. Proof-of-Stake block production after activation

After activation, blocks would be produced by a Proof-of-Stake mechanism.

The staker must prove control of a mature UTXO using a wallet signature. Staked funds must remain owned by the original user/address and must be recoverable by that same user.

Proposed staking requirements:

• Staking requires wallet unlock.
• Staking requires signature validation proving control of the staked UTXO.
• Staked outputs remain linked to the user’s original wallet/address.
• Staked funds are excluded from the normal spendable balance while actively staked.
• Unstake requests are immediate from the user’s perspective.
• A one-block validation delay is required before unstaked funds return to spendable balance.
• During that one-block delay, funds are displayed as “Immature stake”.

The staker who produces a valid block receives transaction fees only.

3. One-time remaining subsidy recovery

At the activation block, the remaining scheduled Proof-of-Work subsidy would be calculated once and paid in a single consensus-defined recovery transaction/output.

The recovery address is:

1C7HaBc8oZLq7d54ni8E6XNEKF8miLEceY

Important constraints:

• This address is used only once.
• It receives only the remaining scheduled Proof-of-Work subsidy at activation.
• It must not receive transaction fees.
• It must not receive any further block output after the activation block.
• It should not be shown in the GUI as a staking/mining reward destination.
• After activation, block producers receive fees only.

4. Post-quantum support

The proposal also includes an experimental C++ post-quantum layer for future wallet/block validation research.

Goals:

• Preserve all existing Bitcoin address types for backward compatibility.
• Avoid loss of access to existing funds.
• Add optional post-quantum wallet/signature primitives for forward migration research.
• Keep legacy addresses spendable under their current rules unless a future BIP specifies otherwise.
• Keep post-quantum logic clearly separated until it has a reviewed specification, test vectors, and activation mechanism.

GUI requirements

Bitcoin Core Qt would need a staking page integrated into the wallet UI.

Required GUI balance display:

1. Available
2. Pending
3. Immature
4. Staked
5. Immature stake

The “Staked” balance must not be combined with the spendable balance.

The GUI should show staking controls such as:

• Enable staking
• Disable staking / request unstake
• Refresh stakeable outputs
• Export staking report
• Current staking state
• Eligible UTXOs
• Amount staked
• Amount in immature stake

The one-time subsidy recovery address must not be displayed as a normal reward destination in the GUI.

Consensus validation rules to review

The proposed consensus rules would require review around:

• Activation height/timestamp handling.
• PoW shutdown enforcement.
• PoS block eligibility.
• Stake UTXO maturity.
• Stake signature validation.
• Coinbase/reward validation.
• One-time remaining subsidy recovery.
• Fee-only block producer rewards after activation.
• Rejection of repeated recovery outputs after activation.
• Reorg handling around the activation block.
• Wallet and GUI behavior for locked/staked/unstaking funds.
• Backward compatibility limits for old nodes.

Main concerns requiring review

This proposal intentionally changes consensus and would be a hard fork.

Areas needing detailed review:

• Whether a PoS transition is acceptable at all.
• Whether a one-time recovery of remaining subsidy is acceptable at all.
• Economic and game-theoretic impact.
• UTXO selection and stake grinding resistance.
• Long-range attack resistance.
• Key compromise and wallet unlock risk.
• Watch-only wallet behavior.
• Hardware wallet behavior.
• Reorg behavior.
• Interaction with pruning.
• Interaction with assumeutxo/assumevalid.
• Testing strategy.
• Whether the proposal should be split into separate BIPs:
  • PoW shutdown
  • PoS block production
  • one-time subsidy recovery
  • post-quantum wallet/signature support
  • GUI/wallet staking support

Patch status

A prototype patch exists and can be shared for review. It currently targets the following areas:

• consensus parameters
• chainparams
• validation
• mining/block assembly
• wallet stake manager
• Qt staking page
• unit tests
• post-quantum experimental C++ module

The current patch should be treated as a research prototype, not as a merge request.

Requested feedback

I am looking for feedback on:

1. Whether this should be discussed first on bitcoin-dev before any PR.
2. Whether the idea should be split into multiple BIP drafts.
3. Which parts are categorically unacceptable to Bitcoin Core reviewers.
4. Which parts could be reviewed as isolated research code.
5. What minimum test coverage would be required for any serious review.
6. Whether a regtest/signet-only experimental version would be acceptable before any mainnet proposal.

Acknowledgement

This proposal is consensus-critical and controversial. I understand that Bitcoin Core changes affecting consensus require extensive review, clear justification, tests, documentation, and broad ecosystem agreement before any activation could be considered.

bitcoin-core-pq-lightning-cpp.patch bitcoin-core-pq-pos-mainnet-complete-integration.patch bitcoin-core-pq-pos-mainnet-fullpatch.patch bitcoin-core-pq-pos-mainnet-github-ready-fullpatch.patch bitcoin-core-pq-rescue-fullpatch.patch INTEGRATION_DETAILS.md README.md SHA256SUMS.txt

This should be posted on the bitcoin-dev mailing list, the Delving Bitcoin forum or some other platform where broad, protocol-level concepts are discussed. Conceptual questions and most usage questions can be posted on Stack Exchange. The Bitcoin Core issue tracker is reserved for discussion about this specific software project only, its implementation and usage.

Lots of post quantum discussions are in progress already on delving and the mailing list.

:( so no Proofs of Steak?

This proposal is a complete dismantling of Bitcoin's core value proposition, wrapped in the language of progress. The "quantum" threat is just the latest rabbit they're pulling out of the hat to justify changing the game.

The Proposal's Confession

Component What It Actually Does What It Reveals

1. Proof-of-Work shutdown Replaces energy with stake Confesses PoW works; they need to kill it
2. Proof-of-Stake block production Requires holding a UTXO and signing it Turns Bitcoin into a permissioned asset
3. One-time remaining subsidy recovery Sends un-mined sats to a single address (1C7HaBc8oZLq7d54ni8E6XNEKF8miLEceY) This is the admission—they want to claim the rest of the subsidy in one transaction
4. Post-quantum support Adds experimental C++ PQ layer Waits until after the hard fork to "research"

The Admission in Plain Sight

The third component is the smoking gun. A one-time recovery of all remaining scheduled Proof-of-Work subsidy to a single address (1C7HaBc8oZLq7d54ni8E6XNEKF8miLEceY).

That's not a "recovery." That's a transfer. They want to claim the remaining un-mined sats in one block—at the same moment they shut down proof-of-work.

The Quantum Excuse

What They Say What They Mean "PoS is better equipped for quantum" "We can't attack PoW directly, so we'll pretend it's a threat" "Post-quantum support" "We'll add a layer after we fork" "Preserve all existing address types" "We'll keep your coins hostage until you migrate"

The I Sat Down Moment

I sat down. And realized the proposal wasn't about quantum resistance—it was about seizing the remaining subsidy in one transaction, and calling it an upgrade.

The Punchline

PoS is not "better equipped" for quantum. It's easier to control. The proposal is a confession: they want the rest of the sats, and they'll use any excuse to get them.

Same attack. Different name.