That is not at all what the PR is about.
The whole fight is about a single policy line in Bitcoin Core that limits the data you can embed with OP_RETURN to 80 bytes. Peter Todd’s pull request would delete that limit along with the config flags that let node operators raise or lower it, arguing the cap is pointless because miners already accept larger payloads through private channels or patched nodes, while the cap pushes would-be data publishers into even messier hacks like unspendable Taproot outputs that swell the UTXO set forever. Supporters say bigger OP_RETURNs keep junk out of the UTXO set, simplify the code base, and leave block size economics to the fee market. Critics reply that dropping the ceiling encourages cheap on-chain spam, strips node runners of a control knob, and increases legal or bandwidth risks for anyone syncing the chain. The proposal does not touch the block-weight limit set by SegWit and it does not loosen script-execution rules; it only decides whether Core should nanny how much data a user can stuff after a single OP_RETURN. Your stance boils down to which cost you dislike more: fatter raw blocks that still prune cleanly or a forever-growing UTXO and the need to run a fork like Bitcoin Knots if you want the old safeguard back.
fff /
npub19p…8rv5a
2025-04-30 12:27:52
in reply to nevent1q…us37
Author Public Key
npub19pwm6yt6ezar7mnq2zdt08kypxlmw39hn5kaf5dzr6fhvc2v4leqj8rv5aPublished at
2025-04-30 12:27:52Event JSON
{
"id": "a3c34be01fcf6c9bde6ef28884fc8d9d966ffa34f3107a1b186acbf7ee666fbe",
"pubkey": "285dbd117ac8ba3f6e60509ab79ec409bfb744b79d2dd4d1a21e9376614caff2",
"created_at": 1746016072,
"kind": 1,
"tags": [
[
"e",
"7928ea7720b6483e083a3bd5afa3cd8a5f6465c53fcbd2bad8cbc46a86e59400",
"ws://192.168.18.7:7777",
"root"
],
[
"e",
"24fa542b791b093d636dbfdcca3d570697597e5049525b3baab723544769001b",
"ws://192.168.18.7:7777",
"reply"
],
[
"p",
"c2622c916d9b90e10a81b2ba67b19bdfc5d6be26c25756d1f990d3785ce1361b",
"",
"mention"
],
[
"p",
"4d41a7cbc9b7f7e8484d15499aa9141c73f9a39c3765cc5d5631fa1e7d3633cc",
"",
"mention"
],
[
"p",
"c9e9bdc0b03c21bd337a12dcf5b463d49fdafe884aa12bb950c182e9e4dbe9b8",
"",
"mention"
],
[
"p",
"a43e6fe59ce05052f04a01b38d0cad3fa2652a901d306ea92a7f5c91644863cc"
],
[
"r",
"wss://relay.primal.net/"
]
],
"content": "That is not at all what the PR is about. \n\nThe whole fight is about a single policy line in Bitcoin Core that limits the data you can embed with OP_RETURN to 80 bytes. Peter Todd’s pull request would delete that limit along with the config flags that let node operators raise or lower it, arguing the cap is pointless because miners already accept larger payloads through private channels or patched nodes, while the cap pushes would-be data publishers into even messier hacks like unspendable Taproot outputs that swell the UTXO set forever. Supporters say bigger OP_RETURNs keep junk out of the UTXO set, simplify the code base, and leave block size economics to the fee market. Critics reply that dropping the ceiling encourages cheap on-chain spam, strips node runners of a control knob, and increases legal or bandwidth risks for anyone syncing the chain. The proposal does not touch the block-weight limit set by SegWit and it does not loosen script-execution rules; it only decides whether Core should nanny how much data a user can stuff after a single OP_RETURN. Your stance boils down to which cost you dislike more: fatter raw blocks that still prune cleanly or a forever-growing UTXO and the need to run a fork like Bitcoin Knots if you want the old safeguard back.",
"sig": "91ca178ade8ba2debc4cea55ce38e2c233dacfcf8a63beee73f506ff1ae14e0af33392bcee9bb0195867e314bb8d91f766169c9556001ae0ec49be050d6a6b15"
}