-
@ Nyoro~n
2025-05-03 04:54:34
i tend to agree that a scenario exists where 'eventually' OP_Return limits should be relaxed, but in my head that scenario happens like maybe in a decade if a sustained effort to bloat the chain proves to exceed the desire for users to 'use bitcoin' far exceeding the efforts today or historically.
what is the acceptable limit of OP_Return? at what point is loosening the limit no different than removing it altogether?
what is your position on how new nodes on the network should be configured? should these limits (or lack thereof) be set in stone or allow some flexibility through configuration file like how it is done today.
while blocks occasionally (or arguably often) contain arbitrary data transactions that bypass limits set by node policy, those OP_Return transactions are only able to relay on a small subset of nodes on the network (proponents of removing limits often cite libre relay and some miners that accept out of band payments). whether or not there is an actual need for these larger op_returns i have no idea, but it would appear that those transactions have not been able to proliferate across the wider network of legacy nodes and have no way of expanding their use, this probes thay existing policy are effective. i havent seen an argument why new nodes should be expected to join the nodes which relax limits rather than the wider network which overwhelming enforce the limits.
anecdotally i run Core with the patch 28408 for about 18 months, and i send transactions regularly, my fee estimation has worked fine and ive been able to keep up validing blocks containing transactions not in my mempool just fine whether or not my peers include Bitcoin Knots, Libre Relay, or a peer still running v.15
utxo-bloat methods of storing data have only been tolerated on the network because it has been controversial to include those methods under current policy checks. if the concern is to address utxo-bloat perhaps that discussion should be opened up again and a clearer conclusion be made