Zero-Knowledge Goof on Nostr: My 2 sats of quantum slop. In Bitcoin, signature schemes are there to authenticate ...

My 2 sats of quantum slop.

In Bitcoin, signature schemes are there to authenticate the owner of coins. If there is a quantum computer they don't work. Code that doesn't work should be disabled and removed. Removing broken things is not confiscation but leaving them in is since it allows confiscation by the quantum computer operator.

The plan:
- Soft fork in SHRINCS into a tapleaf. Require both internal key BIP340 signature + SHRINCS signature.
- People slowly migrate to addresses that include taproot + SHRINCS (but don't actually use it to spend other than to test).
- Set up 200 bit ECC puzzle as part of bitcoin consensus. If solved, ECC is disabled in Bitcoin and it auto triggers the availability of pure PQ address SHRINCS (or whatever this can be changed as we go).
- Encourage the development of prediction markets on the 200bit ECC puzzle so that QC developers have a nice incentive. A liquid or other sidechain prediciton market would be good but you could add an OP on main chain to inspect whether it had been solved or not.
- You could add challenges in a range from 150-200 bit to keep things interesting for prediction markets. Solving 160 bit would be a major red flag. Only 200 bit solution triggers the ECC disabling.
- After ECC disables, over time plan a hard fork so people who hadn't migrated to taproot+SHRINCS can get their coins back via guy fawkes signatures or ZKPs etc.
- sunset the disabling after 40 years (the quantum question is assumed to have been sorted out by then).

Why:
- QC developers will almost certainly not use their capability to attack bitcoin as a first step.
- If honest researchers pull it off we have an incentive which gives them money and prestige
- QC may never happen. Sunsets or anything relying on a social assessment is misguided.
- In the unfathomably unlikely event that a QC is kept secret and developed just to attack bitcoin AND no honest party can hit 200bit before them then we'll have to manually do the emergency ECC disable softfork and perhaps roll back the chain a bit. Still in a better position since all the code is already in there and most people have migrated to taproot + SHRINCS
- Hashed keys are just as vulnerable. The first QC that can solve secp256k1 DLOG given our current state of knowledge will be able to do it quickly -- few seem to understand this. If they are going to attack bitcoin with it they might as well set up a few of them and steal every mempool coin they can to cause maximum panic. Would be better than stealing satoshi's coins.