Bitcoin OP_RETURN War: Will There Be A Hard Fork?
Pull request 32359 proposes removing the 83-byte data limit set for the OP_RETURN function in Bitcoin
Supporters think the limit is outdated and bypassed after Taproot activation
Opposers maintain that lifting this limit will allow people to embed spam files
Will this war lead to a hard fork?
Yes
One fork would have bigger op_returns? Interesting. I like maximizing my returns.
I dont think it will cause a hard fork but this kind of war will have to be re-fought repeatedly if we want to keep bitcoin as a decentralised money.
The less decentralised it becomes and the less money it becomes, the more risk that bitcoin fails to deliver what we all want it to.
I tend to fall into this camp. For me, Bitcoin is money. I believe that's where the focus should be. My problem is with censorship/cancellation/omission.
Yep, bitcoin is money as the white paper stated, and that is the intention of the protocol.
Censorship and spam filtration are not the same thing.
Censorship is X node/wallet/address cannot broadcast transactions to my mempool.
Spam filtration is I will not include non financial transactions in my mempool, even if they are otherwise protocol compliant.
The irony is with knots you can do whatever you like because it's completely configurable. You could set mempool policy to only include non-financial transactions if that was your desire.
Yes that is irony. My beliefs say you should be allowed to do what you want but I'm a little torn. Why reinvent the wheel? My head is hurting, its like I'm letting my teenage son drive my classic car!
The way I see it, the only thing that needs to happen is to add nostr:nprofile1qqs0m40g76hqmwqhhc9hrk3qfxxpsp5k3k9xgk24nsjf7v305u6xffcpp4mhxue69uhkyunz9e5k7tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7l3vw43's anti inscriptions filter. This is essentially a bug that was introduced as a result of changes that were needed for lightning to work and it makes sense the fix the bug.
Once that is done I think bitcoin should ossify as much as possible and the innovation should happen higher in the protocol stack.
I can see that argument but I'm not sold. Filter seems anti for me. I like lightning but if it/taproot has damaged the base layer... As I have said, my head hurts
I get it, it's a huge topic. I've watched a lot of what nostr:nprofile1qqs8fl79rnpsz5x00xmvkvtd8g2u7ve2k2dr3lkfadyy4v24r4k3s4sppemhxue69uhkummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshscy566r has had to say about it on his YouTube channel and I think he lays it all out very honestly and makes an iron clad case.
Ultimately, spam filters have always been a part of bitcoin, but in changing bitcoin for lightning a bug was introduced that allowed a new way to spam. We should just add a filter to cover that too.
https://x.com/boomer_btc/status/1918320027192664349
This is quite good.
Yeah Bob is a legend
Has anyone noticed that Bitvmv2 has been putting abritary data into the UTXO set rather than OP Return like Casey and his ordinals. Not a fan of Lukes 83 byte cap limit filters as this introduces "permission" into a permissionless network. But can't help but wonder why everyone are so focused on arbitary data on the OP Return when recent activity has mainly been Bitvmv2. These arguments are best had at bitdevs ๐งก
The real concern IMHO as stated by LaurentMT:
"Concerns about jpeg and ordinals spamming the Bitcoin blockchain are a distraction.
You should be concerned about a state-backed usd coin using the Bitcoin blockchain as its data availability layer and outpricing the monetary use of bitcoin."
๐ค
If people look at blocks. Most ordinals activity are like 0.00000400 BTC at the moment. Not really a concern? ๐คท
I don't see the need to lift the cap, if that's what you want, as workarounds exist. So, for me, that's a vote in the no change camp.
On the other hand, as workarounds exist, is it not better for the smoothoperations of the block chain to grease the rails?
