I understand and share the fear of rising node costs, but #BIP110 doesn’t actually solve that class of problems. Pruned nodes already discard historic...
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
