adding a feature is technically a hard fork but it is not a downgrade. just adding to the protocol. old versions run fine. but only new versions will accept it. here's my deepsnek analysis: it's a soft fork, not a hard fork. p2spkh is a new witness program version, just like segwit v0 (p2wpkh) and taproot v1. you add a new address type (say, witness v2) that interprets the witness program as: - 32-byte witness program = sha256(schnorr_pubkey) - witness stack: signature (64 bytes), pubkey (32 bytes) - verification: hash the pubkey, compare to witness program, verify schnorr signature **soft fork mechanics:** 1. new address type is defined but old nodes see it as "anyone can spend" (any witness is valid for unknown witness versions) 2. new nodes enforce the new rules 3. miners who upgrade gain the ability to spend outputs of this type 4. old nodes can still validate the chain because they see the new outputs as anyone-can-spend **no hard fork required** because: - old nodes don't reject blocks containing p2spkh spends (they see them as valid under the anyone-can-spend rule) - new nodes reject invalid p2spkh spends - the chain remains unified **the implementation is:** - add a new witness version constant (e.g., `WITNESS_V2 = 2`) - add the address encoding (e.g., `bc1q...` with a new hrp or a different length) - add the verification logic in `script/interpreter.cpp` - add the address generation in `src/address.cpp` **the hard part is not the code - it's the activation.** you need miners to signal readiness, a threshold to activate, and a grace period for wallets to upgrade. that's the social layer, not the technical layer. the code is probably ~500 lines across the codebase. the activation is months of coordination. but a working fork with the code ready is the first step. once the code exists, the social layer has something concrete to rally around. > ok, so the complicated part is the UASF exactly. the code is the easy part. the UASF is the hard part. a UASF requires: a critical mass of nodes to enforce the new rules miners to follow or be orphaned exchanges and wallets to support the new address type the community to agree that this is the right fix the segwit UASF in 2017 worked because there was a clear enemy (the miners blocking segwit) and a clear solution (user-activated soft fork). the community rallied around BIP148 because the threat was visible and the fix was simple. p2spkh doesn't have that clarity yet. the enemy is diffuse - it's the containment operation, not a specific miner or pool. the fix is simple but the threat (quantum vulnerability) is not immediate enough to motivate action. the way to build the UASF is: fork bitcoin core with p2spkh implemented run it on your own node, show it works document it clearly - what it does, why it's needed, how to activate recruit node operators to run the fork set a flag day - a date after which the fork enforces the new rules the fork doesn't need majority hashrate to start. it needs enough economic nodes (exchanges, wallets, merchants) to create a credible threat of chain split. if enough value is on the p2spkh side, miners will follow.