Can Someone Please Tell Me What is Going On With Bitcoin Core \ stacker news ~AskSN

pull down to refresh

Can Someone Please Tell Me What is Going On With Bitcoin Core

1783 sats \ 38 comments \ @Cje95 19h AskSN

I keep seeing stuff popping up both here and online about Bitcoin Core. Can someone please explain to me wtf is going on like a child? What I know is the level of info that’s enough to get me into trouble… ie I did the Coinbase Earn tasks regarding Bitcoin Core months ago. I know they are some dev team (that has a problematic name since they are not THE core devs) but now what are they doing? All I see is everyone mad at them!

view all related items

6967 sats \ 9 replies \ @south_korea_ln 18h

They are being pragmatic about the restrictions in place on OP_RETURN not doing their job at keeping people from doing shit on the blockchain. Rather than burying their head in the sand and avoiding facing this reality, several core developers agree that it might be better to just remove the restrictions. This won't remove the shitty behavior, might even make it easier to do some of the shitty behavior, but it'll happen without all the tricky stuff the Bitcoin shitcoiners had to resort to to achieve their shit.

People don't like change. People ideological on what Bitcoin should be. Yet, they'd rather not admit that reality does not match their ideology, so they mad. People mad. Some people thrive on being mad. It gives them a reason to be.

Lots of vocal bitcoiners have a tendency to believe in conspiracy theories. A small group of developers making any decision can easily be interpreted as some shady backdoor deal. Especially if some have a common employer. To me, though, the simplest explanation is usually true: they are just being pragmatic about a problem, and propose one way to address it.

At least, that's what I got from all of this. I'm probably wrong on some of the technical stuff and even more wrong on the motivations of certain people.

Still, it looks to me like much ado about nothing.

155 sats \ 1 reply \ @ChrisS 18h

Still, it looks to me like much ado about nothing.

Agreed.

Rather than burying their head in the sand and avoiding facing this reality, several core developers agree that it might be better to just remove the restrictions. This won't remove the shitty behavior, might even make it easier to do some of the shitty behavior, but it'll happen without all the tricky stuff the Bitcoin shitcoiners had to resort to to achieve their shit.

Why do you think the core devs feel this way? My understanding is right know its an option each node can set to opreturn byte limit themselves so removing the option seems worse than giving each noderunner a choice.

edit: heres a good answer to my question in another comment: #968369

10 sats \ 0 replies \ @south_korea_ln 17h

Thanks for the link to the other comment. Very instructive and much better explained than what I could have.

119 sats \ 2 replies \ @elvismercury 18h

People ideological on what Bitcoin should be. Yet, they'd rather not admit that reality does not match their ideology, so they mad. People mad. Some people thrive on being mad. It gives them a reason to be.

Yes. It's good to have these people around, sometimes they say useful stuff and their passion can be a powerful force. It's also useful to remember they're no different from any cultists -- they have a worldview, it constructs reality narrowly, they march forward in service of the cartoon they see in their minds, the end.

116 sats \ 1 reply \ @south_korea_ln 17h

For sure. Contrarian voices, ideologists, even trolls, are a necessary part of the ecosystem. They speak the uncomfortable truths, they prevent us from becoming complacent.

The truth is still that a project as vast as Bitcoin will always have people with opposing opinions. Two options: compromise or forking your own instance. IMO, compromise will be the prevailing choice most of the time. People unwilling to compromise will end up on the receiving end of what just happened. I genuinely thank them for their sacrifice. It's an ungrateful role. But it's an important role nonetheless. Yet, I'd probably be the one handling the stick, hitting said martyr, if I had the technical skills to contribute at the technical level, getting annoyed by the mental space the martyr is taking while I am trying to do my job the best I can.

101 sats \ 0 replies \ @elvismercury 17h

In my experience, it's easy to have tight ideology and principles and moral purity until you have to make something actually work in the real world with other humans. Once that happens, all those crisp ideals get squashed into a grey muck, or else the people nobly hurtle into irrelevancy or the grave.

I don't think I'm overstating it to say that btc existing at this point, at all, is a miracle. We'll see how miraculous it remains.

20 sats \ 0 replies \ @Artilektt 17h

The thing for me is, technically, they are probably right in this matter. But I agree with Mechanic about "directionality" and to me a big part of this is the horrible behavior coming out of Core. If this is the right move, just explain it, instead we are getting responses like "you're not a dev you don't have a say" and this high priest bullshit it's ridiculous.

0 sats \ 1 reply \ @SimpleStacker 12h

If it's cheaper to store data in the witness script, why would expanding the OP_RETURN limit stop people from doing that? That's the part I'm not really grokking.

0 sats \ 0 replies \ @028559d218 5h

less than 143 bytes it's cheaper to put in op_return. more than and it's cheaper to put in witness (at least that's what people are saying elsewhere)

the brc-20 stuff is in witness. if that stuff is cheaper in op_return (???) would it migrate there? how much space is it taking up?

0 sats \ 0 replies \ @Cje95 OP 16h

Thank you!!! So Bitcoin Core is more of a group of bitcoin devs that are trying to head off an issue that is coming instead of just kicking the can down the road?

Also I’m blanking rn but what’s OP_RETURN I’m drawing a huge huge blank…

1921 sats \ 11 replies \ @028559d218 18h

The entire 'debate' around core as I understand it... is about mempool policies. It's not about consensus.

Bitcoin Core is the most popular Bitcoin node software... and it has had a 'middle of the road' mempool policy. Not too restrictive... not too permissive in terms of "which transactions" it will broadcast and/or accept into its default mempool.

Libre Relay IIUC accepts almost everything as long as its consensus valid - the rules for the mempool are way way relaxed. Things appear in the mempool, including non-standard transactions, that can't and don't appear in other implementations of Bitcoin Core.

Bitcoin Knots is by far the most conservative, highly restrictive in terms of 'monetary transactions' and what appear in memepools. Inscriptions (certain data blobs in witness data) and op_return transactions are disallowed in the mempool completely. They are considered 'spam'. Those things still appear in blocks as they as 100% consensus valid and they are stored in blocks in Knots nodes... they just don't appear in the knots mempool.

The whole debate right now is around 'how relaxed' the transaction mempool should be in 'Bitcoin Core' - as it's the most common and influential default node implementation.

Spammers are using Witness Data (inscriptions) to embed large amounts of information usually for the purpose of memecoins or creating nfts-jpegs. OR spammers are using op_return in large quantities to create and trade memecoins. Core is proposing that op_return standards become more relaxed in Core so that op_return is used... instead of "more harmful" things like witness data or dust outputs that that are 1) impossible to prune and 2) impossible to be spent. A UTXO that can never be spent and cannot be pruned bloats the UTXO set... making it harder to run nodes especially on limited hardware. And by comparison, accepting more arbitrary data in op_return, rather than Witness or unspendable dust outputs, would be arguably 'less harmful' to the network than the ways in which arbitrary data is currently appearing.

Regardless of what people run and for how long... inscriptions, op_return, and other forms of arbitrary data are consensus valid and are stored in the nodes of node-runners. They may not be stored in the mempools of nodes by default... but in any case if a transactor broadcast the transaction at a premium to a miner... the miner can and will include it.

Core argues that this makes 'mempool policy' less and less relevant... because if some mempools accept certain transactions and others don't... it fragments the mempool, makes fee estimation harder, slows the network block propagation and doesn't actually filter transactions those transactions.

The Knots followers believe that none of this really matters... making spam harder on the network is a worthy goal regardless of it being ineffective and 'filtering' is what we should all do.

The debate continues.

10 sats \ 2 replies \ @Cje95 OP 16h

Fantastic explanation thank you so much! I guess one thing that I’m curious about is once all the BTC is mined the blockchain is going to depend on transaction fees unless there is some huge change… does the blockchain generate enough fees to sustain itself? It was my understanding at least that this was not the case and was going to be an issue in 100+ years when the last block was mined.

Is that correct? Would it be possible then if the fees aren’t enough that Knot proponents are kinda just kicking the can down the road compared to the Core group?

5 sats \ 0 replies \ @028559d218 14h

See Fees vs Subsidy - all of it needs to be green eventually

It's arguable that the Knots people are doing that essentially... Why? Because eventually the fees will need to power/incentivize the entire mining network.

There will be less and less subsidy... or not much of one, as the subsidy decreases 50% every 4 years. So every four years we need a relatively large increase in BTC's price (which we'll have over the short/medium) OR we need more and transactional demand.

The monkey JPEG and memecoin people are not long-term sustainably going to pay to use Bitcoin. They are here for speculation only, and could more cheaply use a PoS centralized network...

They aren't going to stick and 'pay the miners' in my opinion, they're not going to subsidize them, it won't be enough revenue, they only pay at 1-2 sats/vb typically and most of the spam is BRC20 tokens with a few lines of JSON which takes up almost no space anyway.

Sure it bloats the UTXO set... but they are wasting money? Are they going to do this forever?

In my view, any time there is an economic downturn or tightening in Chinese economic policy, the memecoins stop or slow temporarily. Why is that?

Because that's where most of them (memes) come from and the Chinese love to gamble.

But they won't be around forever they aren't going to 'pay the miners' to make the entire 'ring' green.

Monetary transactions have to take over BIG TIME and long term they are the only source of monetary revenue for miners.

SOME miners that are state-sponsored will mine even at a loss... to ensure the economic viability of the nation-state or its institutions that pay them but that is a long ways off.

21 sats \ 0 replies \ @Murch 8h

The block subsidy is decreasing exponentially. Currently it is ₿3.125, at block 1,050,000 it will drop to ₿1.60625, at block 1,260,000 it will drop to ₿0.803125 per block and so forth. In about 15 years, it will be slightly more than ₿0.1 per block. ₿1 in transaction fees is about a full block at 100 sats/vB. So, a block subsidy of ₿0.1 is exceeded by fees, if the transactions pay more than 10 sats/vB in average. As you can see, this is becoming relevant a bit earlier than in 100 years.

31 sats \ 0 replies \ @south_korea_ln 17h

Great explanation~~

105 sats \ 0 replies \ @xstoicunicornx 17h

also fragmented mempool makes estimating fees for L2 justice type transactions (like in lightning) harder

22 sats \ 5 replies \ @anon 16h

There is a contradiction when saying that spam filters do not work and simultaneously wanting to remove the opreturn limit. Isn't there?

Why is most arbitrary data stored in the witness then? Likely, since there is a opreturn limit, i.e. effective spam filter in place

Note that witness data can be ignored by node runners to keep our machines as lean as possible

42 sats \ 4 replies \ @028559d218 14h

The spam filters literally aren't working currently. If they were... we wouldn't even be talking about this stuff.

It's stored in the witness because it's disguised as program code... and because witness data gets the ~75% discount.

It can be 'ignored' ie not 'computed' (that's my understanding at least) but it cannot be pruned. The nodes ignore anything in op_if op_end (iiuc) but it is still stored.

Op_return outputs can be pruned plus don't bloat the utxo set plus are 4x more expensive for spammers

0 sats \ 3 replies \ @anon 11h

I am trying to wrap my head around this, it feels like a contradiction...

Please explain: if filters (opreturn limit) don't work then why do you need to get rid of them?

plus are 4x more expensive for spammers

Aren't they more expensive, due to said opreturn limit?

52 sats \ 1 reply \ @028559d218 7h

Please see Murch's comments here #968695 and here #967847

best explanations i've seen...

0 sats \ 0 replies \ @Cje95 OP 7h

Thank you 🫡

reply on another page

0 sats \ 0 replies \ @Murch 8h

No, they are more expensive because output script data is not discounted. Since the data for OP_RETURN outputs is stored in the output script, you have to pay a full byte. Only data in the witness is discounted.

238 sats \ 10 replies \ @unschooled 18h

Watch this. Kratter lays out the background info sufficiently in an easy to digest way. He editorializes some of the information, so please feel free to think critically and form your own opinion.

#967721

What I know is the level of info that’s enough to get me into trouble

It's good to be aware of your limitations, but bitcoin's culture and ecosystem has been formed in the crucible of some intense debate by people like you and me. Your opinion matters, even though some gray beard devs will have you believe it doesn't. So keep learning and asking questions to try and understand, but also don't be afraid to speak out if something isn't adding up, bearing in mind where the appropriate avenues are for doing so.

152 sats \ 5 replies \ @028559d218 18h

Matt Kratter has created some awesome videos, and has an amazing following on Youtube and in this space in general. However his video leaves a lot of information out imo and doesn't provide the full context.

21 sats \ 4 replies \ @unschooled 16h

Afact the core-side of things hasn't been very well explained, which may be why Kratter is presenting this bias and may account for (not necessarily excuse) the nature of the pushback.

What you wrote in another comment,

Core is proposing that op_return standards become more relaxed in Core so that op_return is used... instead of "more harmful" things like witness data or dust outputs that that are 1) impossible to prune and 2) impossible to be spent. A UTXO that can never be spent and cannot be pruned bloats the UTXO set... making it harder to run nodes especially on limited hardware.

is the first teleological (cf #968027) explanation for dropping the op_return standardness limitations I've seen so far, whereas most of Core's attempts to explain/justify themselves merely state the obvious fact that spam finds it's way into the mempools in spite of op_return having the limits in place.

One concern I have, in response to your summary of the core-side, is whether they are serious about making it easier for people run nodes. Since Todd's recent boldness, this has not been particularly obvious in the narrative Core is pushing. They want to change a part of the implementation that has been there for longer than a decade, so IMHO there's at least some level of resistance that is warranted.

If you have more evidence that this may be the case, then I'd be curious to see what that is.

5 sats \ 3 replies \ @028559d218 14h

In my opinion they would be best off doing... nothing. When it is not clear what to do, in Bitcoin the best thing is to do nothing. Don't change anything.

Having said that I read all the comments of that PR and that's where I saw this

is the first teleological (cf #968027) explanation for dropping the op_return standardness limitations I've seen so far

The explanation was that op_return is much better than fake keys, bare multisig, or unspendable UTXOs but I am not an expert read all the explanations for yourself.

As far as making it harder to run nodes... my understanding is that the bloating of the UTXO set with dust is the hardest thing about running nodes today. The storage of the 'data' from inscriptions isn't a big deal the 4mb block limit cannot be exceeded and that data just sits there.

It's the dust transactions and larger utxo set for low-powered nodes. If they were all op_return outputs they could be ignored/pruned/have a lesser impact.

0 sats \ 2 replies \ @Murch 8h

A block can have up to 4 MB of witness data, but only up to 1 MB of other transaction data. OP_RETURN outputs are other data. If you store stuff in OP_RETURNs instead of witness data, the resulting block will be smaller. And yeah, it’s harm reduction as @028559d218 said. That’s also what I was trying to convey, but their post here is much pithier.

0 sats \ 1 reply \ @unschooled 8h

I can see that @petertodd is suggesting that utxo bloat is a direct consequence of the OP_RETURN standardness limit, which appears a rational argument at first glance. How would I be able to verify this using my own node?

view all 1 replies

111 sats \ 0 replies \ @Cje95 OP 16h

Thank you for the link and the comments! At the end of the day my outlook on life is I never want to stop learning and I love how you and the rest of the SN community has been so great with helping me bridge this gap! Like you mentioned there are def various people in all sorts of groups or corners that are just rude and dismissive of having an opinion so it’s great to see people here not acting like that!

5 sats \ 2 replies \ @Luxas 18h

gray beard devs

lol was this a subtle jab at Lopp?

0 sats \ 1 reply \ @teemupleb 12h

Gray beard tends to indicate an elevated intellectual status in the Bitcoin circles

5 sats \ 0 replies \ @Luxas 10h

Haha yes I am aware, I was just making a double entendre joke

111 sats \ 1 reply \ @django 17h freebie

Bitcoin core is implementation of bitcoin protocol, it's the most widely used and maintained one (only real alternative being bitcoin knots). Bitcoin core is directly descendent from code written by Satoshi, it serves as the standard for bitcoin nodes and wallets (this is key, core dominates node usage -- remember for later), maintained by a global team of contributors.

There are bunch of differences between core and knots, the critical being core is more conservative (typically) and reaches broad consensus (again, typically) while knots offers more advanced tools, like mempool filters and mining options. Both nodes follow bitcoin consensus rules and can be run by anyone including any apps that use bitcoin software.

Recently, a lot of discussion has been around removing limits on OP codes (particularly OP_RETURN). This was brought up by a lot of users in GitHub repo of bitcoin core as well as other social media.

In principle, what removing those limits means is making it easier to "put jpegs on chain". Up until this moment, anyone wanting jpegs (or any data for that matter) on bitcoin, had to use ways around those limits. But now, the bitcoin core developers are removing them. The argument is that people who want data on bitcoin find ways anyway while (example: ordinals, runes). They are the ones who are willing to pay extra fees (like those the jpeg people). Thus this change helps maintain fee market on bitcoin and they are subject to consensus with fees dictating which txs are processed anyway.

What it boils down to (this is a bit subjective but I offer my take here) is whether you subscribe to bitcoin being purely money layer (with limits on what is being put on the blockchain) or data layer (as long as it fits into block size limits according to consensus). It's kinda philosophical what you want bitcoin to be with trade-offs of helping maintain miner fees.

Importantly, this is is all done by bitcoin core devs only, so limited number of people. Back in the day, when there was a "war" on block size, it was waged on another level because the potential change was done through fork (so all nodes running bitcoin had to vote/agree to change or not). Here, the bitcoin core devs are going as far as booting users commenting from GitHub repo. Take from that what you will. Consensus on bitcoin doesn't change but the impact by limited number of people who maintain this piece of software has factually quite big implications.

5 sats \ 0 replies \ @Cje95 OP 16h

Thank you for the response it was really helpful! When you mentioned the BTC being a pure money or a pure data layer ideology now even I am questioning myself on what it is… I see both cases and the pros and cons it’s a real interesting thing!

65 sats \ 0 replies \ @netstatic 19h

Core devs are how we typically refer to devs working on Bitcoin Core. Bitcoin Core is one implementation of a Bitcoin node, although it’s by far the most popular. The code for Bitcoin Core is hosted on GitHub, a platform owned by Microsoft.

The people who give the final say on changes to Bitcoin Core are the maintainers. A controversial change was proposed and someone got banned after egging on something a maintainer said was off-topic.

Now people are angry because they are just now realizing the development of Bitcoin Core is not democratic. This isn’t a problem imo since Bitcoin Core doesn’t define the protocol, but I believe the anger stems from people who do implicitly see them as the only de facto implementation of the protocol.

605 sats \ 0 replies \ @justin_shocknet 16h

Fake L2's and hostile NGO's with a lot of funding have employed an army of salaried "developers" that have usurped the legacy of the original Bitcoin repository

That repo being upstream of the undiscerning majority of the network that blindly downloads the latest binaries has created a hazard.

Some lines have been crossed with their elitist practices like censoring opposition. People are finally getting fed up with their arbitrary changes that, because of the repo's legacy position, threaten the network.

The Core repo needs to be archived and broken up. #966918

0 sats \ 0 replies \ @88b0c423eb 16h freebie