Okay, I am throwing my hat in the ring on this core30 OP_RETURN limit increase debate.
Simply put I am very concerned about the change. 80-bytes seems like a good limitation in and of itself to control "spam" and limit non-monetary transactional data. Its a constraint of the technology that doesnt need to change. These other improvements this change is purposing to introduce in my ignorant view need to be reviewed and tackled with a different solution. Bitcoin was forked or copied many times already to accomplish "other use cases" for example. I'm not even sure this fixing "spam" argument is valid. What spam exists within a hard limited 80bytes?
Concern #1: harmful content in the ledger that once there, can't be removed
Concern #2: ledger bloat which will directly affect hardware requirements, network costs and as a result negatively affect decentralisation.
This situation seems grave because once that data exists on the ledger it can't be removed without irreparable harm done to the network to remove it.
I am reminded of Chapter 10 in The Bitcoin Standard - Bitcoin Questions. Specifically subsection "out of control: why nobody can change bitcoin", page 228.
Also I had the pleasure listening to the WiM podcast with Justin Bechler (
https://www.youtube.com/watch?v=igTnc20SicE). Although I am not sure I agree with the solution (run knots), nor is it the best conversation/representative on the subject I think many great points are made in this talk.
CC: nostr:nprofile1qqsgydql3q4ka27d9wnlrmus4tvkrnc8ftc4h8h5fgyln54gl0a7dgspp4mhxue69uhkummn9ekx7mqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg4waehxw309aex2mrp0yhx6mmnw3ezuur4vgkhjsen, nostr:nprofile1qqsxu35yyt0mwjjh8pcz4zprhxegz69t4wr9t74vk6zne58wzh0waycpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tcprfmhxue69uhhqatjv9mxjerp9ehx7um5wghxcctwvshs0fa792, nostr:nprofile1qqsg86qcm7lve6jkkr64z4mt8lfe57jsu8vpty6r2qpk37sgtnxevjcpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqpp4mhxue69uhkummn9ekx7mqux2c7y, nostr:nprofile1qqsr26r4lltjnvrwadxp67ns58m4qpzaqemhf5sup7hlujhjh7t296qprpmhxue69uhhqun9d45h2mfwwpexjmtpdshxuet5qy8hwumn8ghj7mn09eehgu3wvdeqzrnhwden5te0dehhxtnvdakz77f8s05, nostr:nprofile1qqsggcc8dz9qnmq399n7kp2yu79fazxy3ag8ztpea4y3lu4klgqe46qpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpzdmhxue69uhhqatjwpkx2urpvuhx2ue0qy28wumn8ghj7un9d3shjctzd3jjummjvuhs8fa6r0, nostr:nprofile1qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgewaehxw309aek2mnyd96zumn0wdnxcctjv5hxxmmdqyv8wumn8ghj7urjv4kkjatd9ec8y6tdv9kzumn9wsz3yzjv, nostr:nprofile1qqs8cajagp7n48275ytuhzuxn93g2crc0lqgfgx8dta2gjdlh5fpmpqppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgdwaehxw309a38yc3wd9hj7vszyl8
I am CCing the individuals above because I trust your opinions on this matter and looking for an update on your stance. As well as what is being done about it. Some of you ( nostr:nprofile1qqsggcc8dz9qnmq399n7kp2yu79fazxy3ag8ztpea4y3lu4klgqe46qpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpzdmhxue69uhhqatjwpkx2urpvuhx2ue0qy28wumn8ghj7un9d3shjctzd3jjummjvuhs8fa6r0) I know are staunch knots advocates but relying on one individual to trust for our software is a security problem. nostr:nprofile1qqsxu35yyt0mwjjh8pcz4zprhxegz69t4wr9t74vk6zne58wzh0waycpz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx2tcprfmhxue69uhhqatjv9mxjerp9ehx7um5wghxcctwvshs0fa792 I read your post about "how hard it is to control spam and engineer filters" but I argue that 80 bytes of "spam" for say a "cheque memo field" (valid use case) is the better control mechanism for spam limitation than increasing the limit to create new filters. I admit I am not super well versed in your realm of expertise. I'm not even sure its fair to call OP_RETURN spam anymore. It seems like a great feature for classifying/IDing transactions and needs nothing more.
Bitcoin is money, a store of value and most importantly its emergant feature of immutability. The latter point and the fact it could affect that as well as affect the democratisation of bitcoin due to lifting the hardware and data transfer requirements is in my opinion dire.
So for those in my network, "closest to the source", what are we doing to move forward? I don't not want to spread FUD but it almost feels too late!
I agree with Justin Bechler on one thing for sure... Where is the reasonable explanation on the benefits and how it improves Bitcoin? I don't think bitcoin should be evolved to include more things. I also don't think one solution to fix UTXO bloat should be at the comprise of something else.
Regards, a concerned, humble sats stacker
Replies (41)
Knots still allows the exact same transactions with large opreturns.
Exactly because it exists on the ledger
Perhaps I misunderstood your point then.
Less a point and more a question. What do we do?
I'm looking for someone to diffuse my concerns
What's your single most important concern that scares you the most?
Blockchain bloat isn’t a real issue as the block size isn’t being changed…
Much less hd/ssd keep getting cheaper…
Bitcoin being turned into something it has not been since inception. The thought of the ledger bloating to require much larger storage space in addition to what is being stored on the ledger as well. I don't want to host garage or illicit/immoral content. Sort of remove me from the network out of principal
Thanks! That's a good point i didnt realize but it does mean less transactions per block which makes volume of transactions slower to validate on layer 1. That has been a bottleneck for scalability in the past and as adaptation grows it could become a problem again - even with layer 2 solutions like lightning
In the lense of "Bitcoin is money" its a problem of QUANTITY of arbitrary data and the CONTENT of it
nostr:nevent1qqspwgy40cdv3tt9lfcu7txnagu6sedqkhkdxcsdl5sfy5jzd74gdgqpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9upzqhkkkrhd74cq7t4cadkc8t28l8mpcgcwhrnmj6mraclh5q2lx890qvzqqqqqqyfdrv75
If you’re scared of bitcoin today, you would be scared of bitcoin in 2009.
knots and bitcoin core are not changing consensus - so tick tock next block.
if you don’t like bitcoin how it is today, you can use PayPal instead 🤙🏽
I think your worrying about things that don’t really make a difference
Time will tell I guess! I really hope you're right!
Don’t worry bitcoin will be fine.
Nothing about what can be stored on chain is changing.
Is the data in op_return not stored on chain?
Core want mempool to remain the default marketplace for transactions rather than have it be controlled by large miners which gives them an advantage over smaller miners. They also want fee estimation to work correctly.
The size of what can be stored in an opreturn is not changing. Mempool is being brought in line with consensus rules so that we stop having block space being sold out of band directly by miners.
I think Im starting to understsnd the underlying technicalities. If I understand correctly, I could configure my node and mempool to disregard (ignore) OP_RETURN data and never store it?
i.e.: It'll exist in the ledger but not on my hardware?
It doesn't matter how you configure your node or which node you run (core or Knots): if there's opreturn data in a block, you will be storing it.
False
Don't trust, verify.
That's a sound bite. Stop gaslighting and study bitcoin. OP_RETURN can be pruned.
We price spam out of the market.
Everything can be pruned except for the UTXO chain you want to verify, that's what a pruned node is.
And you can prune on both knots and core. There's no difference.
> It doesn't matter how you configure your node or which node you run (core or Knots): if there's opreturn data in a block, you will be storing it.
Community Note: FALSE
Can you validate the entire chain without having validated all transactions? Can you validate a transaction without having the full transaction? Are the consensus rules for knots different to core?
The assertion made by 'gsovereignty'—that "It doesn't matter how you configure your node or which node you run (core or Knots): if there's opreturn data in a block, you will be storing it"—is incorrect based on the current capabilities and design of some Bitcoin full node software.
The Technical Error
The primary error is the generalization that all full nodes must store OP_RETURN data. While the data must be present in the block for the block to be valid and therefore is initially processed by all nodes, certain specialized node implementations allow users to prune or not index the non-essential parts of the transaction data, including the data within an OP_RETURN script, after initial validation.
Chatgpt is correct. Like I said, you can prune whatever data you want, it's called a pruned node. That's already an option in both core and knots. You still need all the data in order to validate the chain.
I guess the core point in trying to get across is that there's no difference between core and knots as to what data you need to store and for how long.
Your previous statement—that a user must store the data regardless of node configuration—was factually incorrect and the source of the disagreement.
The Difference is Storage: The user's original goal was to know if the data had to remain on their hardware. The technical answer is No, it does not.
Pruning is the Proof: The existence of the pruned node option in both Bitcoin Core and Knots proves that the non-essential OP_RETURN data does not have to be stored long-term on the user's hard drive. It is deleted after initial validation.
Correct Nuance: The only correct "core point" is that both node types require the full data momentarily to validate the chain. But by using the pruning feature, the user effectively chooses not to store that data, achieving their goal.
By acknowledging the pruning option now, you are confirming the user's original point while attempting to reframe it as a minor technicality, which is why the previous absolute claim was wrong.
It's in the context of Core vs Knots and I'm talking to a human with a brain not chatgpt.
Nostr needs community notes.
Read the thread again, and understand what "never store it" means.
You cannot validate a transaction without the data, you must have it locally. To have it locally it must be stored somewhere locally.
Thank you both for going in depth in the discussion and taking the time to do so. I am learning and that was in some part the goal of the post.
This is how i currently have it mapped in my head... The mempool needs all the data locally to validate the transaction. Which is a cache. That is temporary. That makes good sense. Once the mempool is validated and the transaction can be stored on the harddrive you can prune the data for longterm storage (remove the OP_RETURN data).
This is something I've heard a few times now but I am still trying to wrap my head around on how that is accomplished
I'd love to zap you for your time but amethyst says I can't
It's quite simple. Make bitcoin useful.
Not exactly, but you're almost there.
Mempool is a marketplace where transactions compete to be put into a block (based on fees).
Once a miner puts a transaction into a block, your node needs to fetch that transaction in order to validate the block (in case the miner is lying/cheating).
Once you've done that you can throw away the transaction (especially if it's an Op_return because they are unspendable anyway).
Some people run nodes that discard all transactions except for those which are relevant to their own coins or in the current UTXO set).
Thank you gsovereignty!
And part of that will be our mission as responsible stewards of the technology!
I will continue that through my education
