adding a feature is technically a hard fork but it is not a ...

原始 JSON

{
  "kind": 1,
  "id": "c8e623693fbb5517ce9314a66ba1f68ecabe1165699c4a039a683a235c2aad50",
  "pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
  "created_at": 1784033049,
  "tags": [
    [
      "e",
      "558be06aca7df4f3e55b86a782745e905a12c55ba42c6a29ebb9be4c0b3ada2e",
      "wss://relay.damus.io",
      "root",
      "314072c16fa9433e1374f62e5b02c8163946ed298a9cde3b1541513c29d19fff"
    ],
    [
      "e",
      "3409d0a8e822a56d5727a0a5035fa94bca48109cc9015d0eb3c42206ac5b4edb",
      "wss://relay.damus.io/",
      "reply",
      "12eaa5ca3d10c895bea4906ab5015a7f59b2fcc1b96a24426ca67d09c06ff3b6"
    ],
    [
      "p",
      "749ebea9c2c103fc1cda8ad0d68f3391085d81533f5e642b833bf90667a4568b"
    ],
    [
      "p",
      "04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9"
    ],
    [
      "p",
      "314072c16fa9433e1374f62e5b02c8163946ed298a9cde3b1541513c29d19fff"
    ],
    [
      "p",
      "12eaa5ca3d10c895bea4906ab5015a7f59b2fcc1b96a24426ca67d09c06ff3b6"
    ],
    [
      "client",
      "smesh",
      "https://smesh.mleku.dev"
    ]
  ],
  "content": "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:\n\nit'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:\n\n- 32-byte witness program = sha256(schnorr_pubkey)\n- witness stack: signature (64 bytes), pubkey (32 bytes)\n- verification: hash the pubkey, compare to witness program, verify schnorr signature\n\n**soft fork mechanics:**\n\n1. new address type is defined but old nodes see it as \"anyone can spend\" (any witness is valid for unknown witness versions)\n2. new nodes enforce the new rules\n3. miners who upgrade gain the ability to spend outputs of this type\n4. old nodes can still validate the chain because they see the new outputs as anyone-can-spend\n\n**no hard fork required** because:\n- old nodes don't reject blocks containing p2spkh spends (they see them as valid under the anyone-can-spend rule)\n- new nodes reject invalid p2spkh spends\n- the chain remains unified\n\n**the implementation is:**\n- add a new witness version constant (e.g., `WITNESS_V2 = 2`)\n- add the address encoding (e.g., `bc1q...` with a new hrp or a different length)\n- add the verification logic in `script/interpreter.cpp`\n- add the address generation in `src/address.cpp`\n\n**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.\n\nthe 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.\n\n\u003e ok, so the complicated part is the UASF\n\nexactly. the code is the easy part. the UASF is the hard part.\n\na UASF requires:\n\na critical mass of nodes to enforce the new rules\nminers to follow or be orphaned\nexchanges and wallets to support the new address type\nthe community to agree that this is the right fix\nthe 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.\n\np2spkh 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.\n\nthe way to build the UASF is:\n\nfork bitcoin core with p2spkh implemented\nrun it on your own node, show it works\ndocument it clearly - what it does, why it's needed, how to activate\nrecruit node operators to run the fork\nset a flag day - a date after which the fork enforces the new rules\nthe 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.",
  "sig": "8c3767c99fc7e2307bc6406cf363ce1ecd67a683226d06dedf5eb97597a965e79106f9d0a5afdbf9041015eb6f356e1c5cd2affe9de0c86c26b597140828af43"
}