(my final reply on this video)

原始 JSON

{
  "kind": 1,
  "id": "f40b0456656b2ada6a23eb8b213d82185f99c1cd6c3dc12b4ad99b2aaf4ff36c",
  "pubkey": "12ee03d11684a125dd87be879c28190415be3f3b1eca6b4ed743bd74ffd880e6",
  "created_at": 1771082206,
  "tags": [
    [
      "e",
      "0d24db4b429469a2c1171cb3988c738ad5fdff51d80a09df21f69be5d63c6c9b",
      "wss://nos.lol/",
      "root",
      "b9e76546ba06456ed301d9e52bc49fa48e70a6bf2282be7a1ae72947612023dc"
    ],
    [
      "p",
      "85f28d3a968e7c7a224e96e7be37c1a073e0bbd734a2cc3779075293f26d2b41"
    ],
    [
      "p",
      "b9e76546ba06456ed301d9e52bc49fa48e70a6bf2282be7a1ae72947612023dc"
    ]
  ],
  "content": "(my final reply on this video)\n\nGuy is right at 1:38:10 (and Mechanic wrong) when Guy said that a URSF will do something like require that the block at the activation height must have a large OP_RETURN.\n\nSimilarly, there will be a two-week period where BIP-110 has a consensus rule requiring that blocks signal for BIP-110 (version bit 4, IIRC) and reject blocks that don't signal. A URSF could reject the blocks that do signal and accept those that don't\n\nThere are lots of different ways that URSF could work. A URSF only has to apply to one block, forcing that block to do something that is rejected by BIP-110, and that is sufficient to ensure that the BIP-110 chain will never be accepted by the URSF clients, no matter how long it gets\n\nTo give one very simple and understandable example. We could code and release and run a URSF client today which requires that block 965664 contain at least one large OP_RETURN",
  "sig": "ad442e6f78a8b83958342faf4864127043610acc292e7155b6004060e50fdd96a445c894f5b5b5e0fd0ab1755b52e9be2003f4a52939faedba3963aa3a80a9c0"
}