Replies (31)
Hi, I've got some exciting news for you, I can teach you how you can turn your $300 into a whopping $9,700 with Bitcoin in just 4 hours! without interrupting your daily activities or sending money to anyone TEXT ME IF YOU ARE INTERESTED FOR MORE INFORMATION:📱WhatsApp Number: +1 (740) 961‑0440
Telegram Username :
Telegram
Rachel Hill
You can contact @Rachelhills017 right away.
Google chat: officialprivate803@gmail.com
allowing an additional method of storing data will increase data storage on Bitcoin. the network should resist attacks, not encourage them.
Okay, do you also have an opinion on what I asked?
It’s a totally valid concern if you’ve never run a node and are blissfully unaware that you can just prune stuff
most spam is still required to be stored, such as the utxo bloat. pruning means you can't verify your own txs if they are far back enough and we need full nodes to bootstrap new nodes.
apologies, i forgot devs don't want to talk to normal node runners. i don't want *more* arbitrary data stored on my drive. i don't want *more* avenues for spam or denial of service for normal transactions. at worst we should have options for our mempool and node so we can decide, not be told, how things will be.
A bitcoin node still downloads and validates all transactions and blocks, even if pruning is enabled. And if you set up your node to track your wallet history, it will store those transactions even if they're past the prune period.
Op_returns are provably unspendable thus, pruneable. If it’s in a block you have to accept it or you’re out of sync with the rest of the network.
To win your war you need to fork bitcoin. Or you can just ignore it and let your node prune it.
The fact they will remove the option for us node runners to decide what will go trough our nodes is shady. I want option to change OP_RETURN value in settings.
Increasing the Blockchain size by allowing arbitrary data transactions. It's true they'll pay more but that won't stop them and major miners arent against that.
The cost of running a node will increase because 2TB drive will not be enough if they keep spamming the Bitcoin.
Look at the Ethereum for example. Their full archive node requires 12TB of disk space I believe. It might be even more today. And even they have OPTIONS to run 3 kinds of nodes.
I'm not seeing the reason why in the hell #Core devs need to remove this option. Leave it there. I'll decide how much shit I want to broadcast.
I hope people won't blindly update to new core 29 release after knowing what that brings.
That feels unfair, I didn't say I didn't want to talk to you because you were a "normal node runner". I indicated that your answer did not match the topic I asked about.
I get that people don't like data in the blockchain—I'm not excited about that either—but I've already heard all about that for the past two weeks. Here, I'm specifically trying to I understand why people argue that OP_RETURN transactions make nodes more expensive to run. I don't get where that is coming from or what the line of thought is.
the issue from the normie side is pushing changes on node runners and taking away config options. this started getting on people's radar when the inscription spam kept going on and on with no action taken.
op_return as is today is fine but increasing the limit just invites more spam and more cost. this is what upset everyone.
as far as op_return existing at all, yeah those people are unserious or not informed. thank you for being patient with me in your responses, this spam debate has everyone worked up, including me with having a lot of skin in the game for Bitcoin's success.
No, a pruned node verifies everything, no matter how far back it is.
The only (informed) argument I see for that position is something along the lines of "this acts as an endorsement that such data storage is fine, and will encourage people to do more of it. You can observe that this effect has already happened with a large increase in op_return activity since the pr was opened, and the creation of a new "op20" token scheme. That endorsement will flow over to schemes that use witness data, increasing their use as well. That will make it less likely that will have non-full blocks (due to more token usage of either type) and increase the data storage requirements of non-pruned nodes due to increased witness usage"
Personally, I think the immediate observable effect is due solely to the publicity the issue has generated and will disappear when attention moves elsewhere.
Yeah, agree, it seems mostly like trolling to make a point or riding on the attention.
Have you been on nostr all this time??
It doesn't.
It doesn't change what blocks validate or block size limits in any way which means it doesn't change drive consumption or hardware requirements on a node with default settings.
They are misinformed or lying to score points for their side.
I think it's just an increase of data storage takeup from jpgs and etc, which the blockchain is not used for. But, correct me if I’m wrong here.
Correct, it has to verify every transaction.
The moment it reads the OP_RETURN byte it sees the transaction as valid and the UTXO unspendable. It doesn’t read the arbitrary data afterwards because it doesn’t need to and can prune the output immediately.
Honestly, I think my node has to do more work verifying a stranger’s multisig spend than some op_return bible verse
That argument would make more sense to me, but that's why I was asking about the other argument, which doesn't. ;)
A lot to unpack here.
> The fact they will remove the option for us node runners to decide what will go trough our nodes is shady. I want option to change OP_RETURN value in settings.
The latest version of the pull request only deprecates, but does not remove the configuration option.
> Increasing the Blockchain size by allowing arbitrary data transactions. It's true they'll pay more but that won't stop them and major miners arent against that.
OP_RETURN data is written to output scripts. Output scripts are not subject to the witness discount. More OP_RETURN data would likely reduce blockchain growth, so as I was asking in the above post, I am not sure where this idea is coming from.
> The cost of running a node will increase because 2TB drive will not be enough if they keep spamming the Bitcoin.
Blocks are limited to 4'000'000 weight units. OP_RETURN data bytes weigh four weight units, so a block filled with OP_RETURN outputs would come in close to 1MB, which is significantly less than the latest 30-day average of 1.64 MB. It’s unlear to me how more OP_RETURN data would increase the blockchain growth.
> Look at the Ethereum for example. Their full archive node requires 12TB of disk space I believe. It might be even more today. And even they have OPTIONS to run 3 kinds of nodes.
No clue, they have made a lot of strange decisions, but I don’t see how it’s relevant as the things that lead to bloat there are completely different.
> I'm not seeing the reason why in the hell #Core devs need to remove this option. Leave it there. I'll decide how much shit I want to broadcast.
I think there have been several books worth of explanations written at this point, so I don’t think it’s useful to elaborate, but if you are earnestly interested, I can provide a few links.
> I hope people won't blindly update to new core 29 release after knowing what that brings.
Bitcoin Core 29.0 came out in April and did not change the OP_RETURN limit. If the currently open pull request should get merged, the change would at the earliest be released with Bitcoin Core 30.0 in October.
Yeah, I get that all the hype around silly pictures in the blockchain gets on the nerves. FWIW, all the Bitcoin Core devs are working on the native currency for the Internet, as far as I can tell, they largely feel the same.
To us it mostly feels like a question of priorities and benefit per cost. Except for Luke, I don't know if any Bitcoin Core contributors that think filters have any effect at all on transactions for which there is sufficient economic demand. 53% of all transactions in the last year have had inscriptions or op_return outputs. These transactions paid hundreds of millions of dollars in transaction fees.
I don't think there is an appetite for crippling Bitcoin Script over this by soft forking in mitigations. So, Bitcoin Core devs mostly choose to spend their time on other things.
Most Bitcoin Core devs have plenty skin in the game, with their careers tied up in Bitcoin for many years. Don't get too worked up, it's not as big of a deal as some make it sound.
If you mean me, my first post with this account was in December 2022, but I haven't been active for most of the time since then. If you meant AJ, he should answer that himself.
Yea i meant aj. Ive noticed you posting a lot to answer questions re opreturn drama and i appreciate it. Thank you.
Also, i hear you every week on the recap so it's hard to miss you 😅
I really appreciate you took the time and wrote the explanations. It's clear to me that I don't have the technical knowledge about this. I'd be happy to read and learn more if you point me in the right direction 🙏🏻
Thank you
My thinking is as follows:
1. UTXO bloat (4 GB -> 12 GB in the last year?) has already increased the growth and hardware requirements (I had to replace my Pi4 8 GB)
2. Bitcoin core has done nothing to fight against it.
3. Now they want to invite more spammers and it's not going to help with Problem1 because it is financially wise to put data in witness than OP_RETURN.
Thanks, let's dive in, shall we?
What issue were you experiencing with the Pi4?
I'm asking because there is a common misunderstanding that the entire UTXO set needs to fit into RAM, but that is not the case. The UTXO set is mostly stopped on disk. You only need a couple gigs of RAM for Bitcoin Core to run decently, although more is certainly helpful. UTXO set growth means slower IBD and generally more disk reads during validation, but it's a graceful degradation, not a cliff.
A general synopsis is that with 8Gb Pi4, I cannot add some other apps on my Umbrel OS on top of Core + Lightning + Electrum and some other apps like Jam, Mempool, Nostr relay and Pi-hole. Thats my point, a slow degradation that has made me upgrade to mini-PC within 4 years.
Rather than diving further in that aspect, what are core developers doing to resist or prevent further UTXO bloat?
What we're doing is significantly improving the performance of Bitcoin Core with many releases.
Maybe you're just expecting a little much out of such a low-powered device?
