pull down to refresh

"The goal of changing the op-return rules is to preserve the ability of anyone to run a node. "

What’s the connection? Well, people want to put information inside of bitcoin transactions. You may disagree with this idea, but for them there is an economic rationale for doing it. They’re willing to pay good money to publish this information, much like someone might publish a classified ad in a newspaper.
Building your own block template is a great opportunity to filter out transactions. At the relay level, however, you’re only undermining the goals you set out to accomplish.
I fully believe in decentralized systems, as does every Bitcoiner I know. It’s incredible to watch the node running community grow and people feel empowered by helping keep bitcoin decentralized. If you’re not already running a Bitaxe, I’d recommend it. Filter the transactions going into your blocks your Bitaxe is mining if you want to have a say in data on bitcoin.
For the sake of maintaining bitcoin as decentralized system, however, I’d strongly suggest you reconsider filtering the mempool and restricting op-return data.
I think I agree with her. RAM is a bigger bottleneck than storage for node runners, in my current experience
The only thing I'm not sure about is whether expanding OP_RETURN will meaningfully reduce spam in the witness data
I don't have much to say about how filtering atthe relay level disadvantages small miners, but it sounds correct
reply
282 sats \ 1 reply \ @optimism 19 Sep
RAM is a bigger bottleneck than storage for node runners
I had no notable issues with a dbcache of 4GB on an Odroid M2 I sync'd and ran earlier this year, even though it didn't have the whole utxo db cached. It does have NVME and good controllers though - so that may help not having issues with loading from disk. Oh and I'm supposed to get that RPi 8GB delivered this Saturday, so I'll have a go at setting it up and doing IBD with it - so I'll keep you posted on that. Either way, if it works on the Odroid, it should work on the Pi, so it'd be at best a coding issue.
I don't have much to say about how filtering at the relay level disadvantages small miners
Back of the envelope math, anyone do correct me if I mess up somewhere:
If you have 8 slots where you randomly connect to peers and 20% of the network filters txs, then you have... .00025% chance to have every slot filtered, and thus 99.99975% chance of having at least 1 non-filtering peer. So in theory it sounds fine. But how many of these peers are actually capable of delivering all txs to you? 10% of the non-filtering part of the network? Let's do the math again:
8 slots, 8% desirable peers, gives you a 49% chance (instead of 57% if no one were filtering) of having at least 1 desirable peer.
This implies that it's not an immediate problem, especially since your node will disconnect malfunctioning or slow outgoing peers, so you have infinite tries and most nodes will eventually find a good set of peers (that won't work for filtering peers right now though); this is one of the things that has been engineered pretty awesomely over the years. But ultimately, when the % of the network that is filtering grows, this could become a problem: it is a forward-looking concern.
reply
Cool, looking forward to your test results on IBD.
reply
Building your own block template is a great opportunity to filter out transactions.
Glad to have independently written something similar this morning for a much smaller audience.
Also GREAT point about the bitaxe - though last time I discussed bitaxes with a mining service provider they laughed me out of the room:
But I have to believe that they that laugh last... otherwise might as well pack up.
reply
On a long enough time horizon, do we all become miners?
reply
202 sats \ 0 replies \ @nout 18 Sep
On a long enough time horizon we will all be under ground. So in some ways... yes?
reply
We once all were miners so this would be the ultimate reversal of trends. But I doubt it, because hashing simply scales very well.
But, even if 0.7-1% of blocks are mined by individual honeybadgers that don't care, with their own blocktemplate policies and no pool middleman1 then we'll have a block a day on average that isn't governable or coercible.

Footnotes

  1. because you will be unlikely to make ROI with a bitaxe when you're on pooled payouts and you'll never hit the lottery in that setup.
reply
THE QUEEN HAS SPOKEN
I run a bitaxe!
reply
Idea: (if you have time) ask dcentral to print a 1-time SN edition yellow one and either raffle it or auction it - at tabconf?
reply
That’s not a bad idea but who is decental?
reply
Was the first vendor of bitaxes in NA. But they're actually in Canada so may be crappy if it gets taxed.
They have cool self designed axe stands though... Which is why I thought of them. Can also get a plain one from Virginia Freedom Tech or solosatoshi and ask someone else to print the stand/case
reply
I got mine via fold and crypto cloaks promo
reply
159 sats \ 1 reply \ @optimism 18 Sep
I think the "responsible" source for a BitAxe is through an OSMU contributor. See https://bitaxe.org/buy -> select North America.
reply
Hahaha
reply
324 sats \ 0 replies \ @LibreHans 22h
What her post conveniently ignores: there are ZERO incentives to use op_return over witness data, so changing op_return is pointless to her entire article. The change of op_return is about developers changing how bitcoin is governed, they want to push through controversial changes with sound technical reasons that don't match economic reality.
reply
42 sats \ 1 reply \ @eduardopro 21h
The miners have to adapt to the node runners' rules, not the other way around.
They are the ones risking it all to relay SPAM. And if the whole network is against that, they will be the ones losing big, as they should.
This is Jason Hughes' response to Nifty and the whole Core camp's weak, weak arguments -- ---> https://x.com/wk057/status/1968324685952692369
A quote:
"Instead, the P2P network of node runners should set sane policies, and miners who act against the collective will of the decentralized P2P network SHOULD be penalized for mining blocks that don't fit with the majority of nodes in the form of slower block propagation and higher stale rates.
If you're a sane miner, you go with the overall will of the network itself (node runners) and get some benefit from the associated speedup. If you go against what the majority of the network is willing to relay and still want to spam the network, then you get penalized in the form of losing blocks to slow propagation."
This is what's going to happen when the OP_RETURN limits are lifted:
Spammers and scammers will use and abuse the unlimited OP_RETURN space, AND they will keep using all their more harmful techniques.
Why wouldn't they? Core's changes basically legitimize their SPAM, giving them carte blanche to keep abusing the Bitcoin network.
This will be orders of magnitude more harmful to decentralization than what Nifty described. The damage already done is orders of magnitude more harmful, just look at this -- ---> https://wtfhappenedinfeb2023.com/stats-about-spam
Anyway, Bitcoin is money. Spam is spam.
Totally with you on the RAM bottleneck for node runners—it's wild how the UTXO set can gobble up gigs of memory just to keep things humming smoothly, especially during peak traffic. Storage is getting cheaper by the day, but RAM? That's the real gatekeeper for hobbyists. On the OP_RETURN expansion, I'm skeptical too about it curbing witness data spam. It might just shift the junk around rather than squash it. Fun fact: Back in Bitcoin's early days, OP_RETURN was capped at 40 bytes to prevent abuse, but folks still found ways to embed data elsewhere—like in fake pubkeys.
reply