Bitcoin has risks both known and unknown. Finding perfect consensus on the urgency and impact on any given risk is impossible. They can only be estimated. And some of them only emerge under certain conditions or specific contexts, each of those having their own probabilities that change over time.
Making protocol changes in a neutral and unbiased way has become increasingly difficult. We are approaching laissez-faire-by-default, via ossification.
The crown-joule of Bitcoin is the ticker and the immaculate conception of it's issuance. We can never get these back if we lose them. Laissez-faire could cost us both.
The Bitcoin community creates an indefinite series of hardforks at a planned frequency, under a certain set of safer conditions than testing on the main-chain, such that the new chain ("Satellite Chain") can serve as both a sandbox and undo-point, for the main chain. To achieve this safety to innovate, and remove the contentiousness, all the satellite chains get launched with an oracle from the main-chain that feed into difficulty bombs on the new chain. These difficulty bombs would be disarmed under only two conditions. Either an extended problem with the main-chain is detected (Eg. 52 sequential negative difficulty adjustments), or a community consensus to hard-fork the "satellite"-chain, to remove the difficulty bomb.
It would be like A/B testing in production, except we plan to destroy B, unless it proves that A has a material flaw, such that B is the next best logical choice. It's the backup plan.
It would take the contentious-ness out of planning/lobbying for new ideas. Instead of people screaming "YOUR DUMB! GFY and your drivechain.". People could calm down and say "I disagree with the idea, but put it on the next satellite that's scheduled to go out.". It's effectively a framework for innovating. And I don't think the entire community has to even support this framework, as it's permissionless in it's approach. Although it could likely be made stronger if the main-chain added features to help the oracle.
The satellite should not be seen as a threat to the ticker, nor attempt to "takeover" or become "the real bitcoin".
There would be pressure to hold more Bitcoin around those blocks.
There would be an infinite stream of dividend-like cashflows to holder, presuming there is demand for the features of the new chain.
Any new "risk", could be dismissed as "solvable in the next satellite".
Community could calm down.
Businesses could plan properly, and there would be no contention over the ticker. Eg. Coinbase might say, "We follow the satellite framework, the ticker for the chain with the difficulty bomb will be BTC-945. Here is how to claim your BTC-945... you can sell... or hold it... by electing..."
The immaculate conception is preserved for eternity.
Miners may or may not route hashing capacity to the new chain.
In the event of a problem on the main-chain, the hashing power would have an alternate use-case, that would be more valuable than selling out to attack the main chain.
Like a planet that is running out of resources (eg. time until it's own sun burns out), one solution would be to launch satellites to help look for a new inhabitable planet. The satellites likely don't come back. They send data, but that's likely it. They might be a total waste. But we'll learn something every time we launch one. And if we're lucky, one of them, might find a new inhabitable planet before the one we're on runs out.
Bitcoin Satellites
Problem Statement
Proposed Idea & Potential Technical Tactic
Examples
Block # 945K - Satellite Chain 1
Block # 1155K - Satellite Chain 2
Block # 1365K - Satellite Chain 3
Impact on Incentives
Why "Satellites"?