I understand and share the fear of rising node costs, but #B...

npub129puxu7lrd2g5a7hnmr57fe9t5ffk62m2gklkkl5xjvt5j6srhuswhhud3
hex
0c4e646e92beae34cd59918cf707ca8a187339f2d77d75360f3850ca15827f91nevent
nevent1qqsqcnnyd6ftat35e4verr8hql9g5xrn88edwlt4xc8ns5x2zkp8lygprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgs9zs7rw003k4y2wltea360yuj46y5md9d4yt0mt06rfx96fdgpm7gdag8ueKind-1 (TextNote)
I understand and share the fear of rising node costs, but #BIP110 doesn’t actually solve that class of problems. Pruned nodes already discard historical block data, so large witness fields or OP-RETURN blobs are a temporary validation cost, not a permanent burden. The real long-term cost is UTXO growth, because UTXO entries live in RAM and cannot be pruned. By hard-capping prunable fields, BIP110 creates an incentive for motivated spammers who want to store more than the allowed bytes to shift part of the payload into fake outputs or synthetic keys. That moves data from the prunable side of the system into the non-prunable side. Several demonstrated constructions show that the node ends up carrying more bytes in UTXO than it would have stored in a single prunable OP_RETURN, while the fee delta for the spammer is minimal. So the proposal tightens some superficial limits but risks worsening the one part of the system that actually matters for long-term decentralisation: UTXO size, not raw block weight.
That’s not obviously a win for decentralisation, and it’s a very weird hill to die on if our stated goal is keeping node costs low. Sending a message to spammers that they are not welcome is futile as the spammers do not care about our messages; they will just move to more destructive methods, and the cat and mouse game will continue.
nostr:nevent1qqsg6kyjj6fcp87pnzz66tfcjhsglf83j2rv3nvpfw5acvxzxmve42cpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyqy4r7nc3ftfrvnjvrp9djfl25xv9yyc3wdmyseznvpj4ar0plr5gqcyqqqqqqggew760
原始 JSON
{
"kind": 1,
"id": "0c4e646e92beae34cd59918cf707ca8a187339f2d77d75360f3850ca15827f91",
"pubkey": "5143c373df1b548a77d79ec74f27255d129b695b522dfb5bf43498ba4b501df9",
"created_at": 1772355245,
"tags": [
[
"alt",
"A short note: I understand and share the fear of rising node cos..."
],
[
"p",
"0951fa788a5691b27260c256c93f550cc290988b9bb243229b032af46f0fc744",
"wss://relay.protest.net/"
],
[
"t",
"BIP110"
],
[
"t",
"bip110"
],
[
"q",
"8d58929693809fc19885ad2d3895e08fa4f19286c8cd814ba9dc30c236d99aab",
"wss://relay.primal.net/",
"0951fa788a5691b27260c256c93f550cc290988b9bb243229b032af46f0fc744"
],
[
"zap",
"5143c373df1b548a77d79ec74f27255d129b695b522dfb5bf43498ba4b501df9",
"wss://primus.nostr1.com/",
"0.99"
]
],
"content": "I understand and share the fear of rising node costs, but #BIP110 doesn’t actually solve that class of problems. Pruned nodes already discard historical block data, so large witness fields or OP-RETURN blobs are a temporary validation cost, not a permanent burden. The real long-term cost is UTXO growth, because UTXO entries live in RAM and cannot be pruned. By hard-capping prunable fields, BIP110 creates an incentive for motivated spammers who want to store more than the allowed bytes to shift part of the payload into fake outputs or synthetic keys. That moves data from the prunable side of the system into the non-prunable side. Several demonstrated constructions show that the node ends up carrying more bytes in UTXO than it would have stored in a single prunable OP_RETURN, while the fee delta for the spammer is minimal. So the proposal tightens some superficial limits but risks worsening the one part of the system that actually matters for long-term decentralisation: UTXO size, not raw block weight.\n\nThat’s not obviously a win for decentralisation, and it’s a very weird hill to die on if our stated goal is keeping node costs low. Sending a message to spammers that they are not welcome is futile as the spammers do not care about our messages; they will just move to more destructive methods, and the cat and mouse game will continue. \n\nnostr:nevent1qqsg6kyjj6fcp87pnzz66tfcjhsglf83j2rv3nvpfw5acvxzxmve42cpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyqy4r7nc3ftfrvnjvrp9djfl25xv9yyc3wdmyseznvpj4ar0plr5gqcyqqqqqqggew760",
"sig": "daf27341dc0d22c4aabe9a7223d5fc55e0a0f88241a74231d5019dbf12a8a85aef3abb39c321d000ed5200231fa336a72c1a87ae674d72e3ad2ba13cd5b4df50"
}