One key insight of Bitcoin is that transaction fees control ...

原始 JSON

{
  "kind": 1,
  "id": "cf378b9bd4a0f2e60b86a621b49b64dadc3952040d9975894fc9bdb2a164f9e0",
  "pubkey": "46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d",
  "created_at": 1770750171,
  "tags": [
    [
      "e",
      "dfcea7e09ae2a5c2edad284f536419c79abf52604eb5cae76e3f895ed0f4b3eb",
      "wss://relay.primal.net/",
      "root",
      "846307688a09ec112967eb0544e78a9e88c48f50712c39ed491ff2b6fa019ae8"
    ],
    [
      "e",
      "d6f3df75fd0c871e55d99bc9a9290a39759681298cfc69e4acf9a209efdccca2",
      "wss://relay.primal.net/",
      "reply",
      "314072c16fa9433e1374f62e5b02c8163946ed298a9cde3b1541513c29d19fff"
    ],
    [
      "p",
      "846307688a09ec112967eb0544e78a9e88c48f50712c39ed491ff2b6fa019ae8"
    ],
    [
      "p",
      "314072c16fa9433e1374f62e5b02c8163946ed298a9cde3b1541513c29d19fff"
    ],
    [
      "client",
      "jumble"
    ]
  ],
  "content": "One key insight of Bitcoin is that transaction fees control spam and that's how we treated it on the consensus layer since day one. Nodes had policy to fight spam if they wanted to but spam in blocks was never the target of preventative measures. Never was a block rejected because it contained spam.\n\nSpammers increasingly worked around the Bitcoin broadcast mechanism for transactions driving miners to seek tools to get those mining fees. This put small miners at a financial disadvantage leading to mining consolidation in big pools.\n\nEnter bip110: It's proponents want to stop spam through consensus. But fighting spam is a notoriously tedious arms race where in this case, the defender would be at a disadvantage of galactic proportions. Any spam counter-measure would get deployed through a months long fork process with real risk for people building actual money tools using OP_IF or anything a fork would ban willy nilly from tomorrow on while the spammers would get plenty of head notice to change how they store their rock pictures on Bitcoin starting at that and that block height.\n\nThat said, was the OP_RETURN limit removal sensitive? No! I wish we had kept it at some 200B or something where it would not limit anybody building selfishly data storage tools but also it would not have signaled to retards that Bitcoin was open to 100kB file storage.\n\nIn the end, bip110 is crazy madness promising to fix spam which it can't and it will do more harm than good if it wins or if it looses:\n\n1. If it gets largely ignored, spammers will say \"see, Bitcoin loves us!\".\n2. If it gets some fork chain to wither for some years, spammers will say \"great, now that Bitcoin Knotzy forked off, Bitcoin loves us!\".\n3. If it gets enough traction for nobody wanting to risk being on the re-orged side of the chain split, Bitcoin will die because we will have anti-spam forks every other week, we will not talk about anything but fighting spam and Bitcoin will turn into a total joke.\n4. If Knotzy gets some scary 30% and decides to still build their chain and through whatever freaky incident they get their chain to grow faster than Bitcoin later, Bitcoin would defensively hard fork which would be the absolutely worst of all outcomes but the one, Knotzies allude to in their marketing.\n\nSo clearly I hope we go with option 1 and not being in the Knotzy bubble I'm pretty convinced that's what's going to happen but maybe I'm in the Core bubble and wrong?",
  "sig": "1d55c395905d6db6f1208bcfcfae33a0bb85c78d5760043a75169265a46fc31429e095de7ac964abe250146a3e4771d9868162133fd372e362a7151cbb77f972"
}