Greg Maxwell's take: There isn't anything unusual or bad going on *with* Bitcoin Core. In my opinion there does appear to be a dishonest and inauthentic social media campaign *against* Bitcon Core. There have been a dozen threads on reddit on the matter, which is pretty sad because it's mostly a nothing burger... I've wasted tens of hours writing responses only to find that generally the opponents just vanish. Back in 2014 the average block size was only around 160 kilobytes, as a result there was no real pressure to drive up transaction fees and it was extremely cheap to stuff whatever garbage data you wanted in Bitcoin's chain. Some people were storing data by paying to fake addresses which were really just data instead of an address. This is maximally bad because it bloats up the UTXO database with unprunable data, directly increasing the minimum cost to run a node. To address this core devs introduced a 'data carrier' output type also called an OP_RETURN. This is a kind of output which provably can't be spent so it doesn't have to go into the utxo database and can be pruned. Additionally, they limited the size of the data to 40 bytes in order to encourage applications which can just store a hash instead of the data to do that. Later this limit was increased to 80 bytes. The world has changed a lot since 2014: Fees are now not just meaningful but significant, no one is dumping data in Bitcoin because it's *cheap*. People dumping data in have almost entirely moved to dumping data in the witness portion of transactions. Major miners no longer enforce this limit, because it turns out they like money (and have denied requests to limit themselves), and if you are willing to directly connect to one its easy to get them mined. There are some users who are still creating 'fake outputs' but have said they would change to opreturn if not for the limit (particularly some payment channel thing). Finally, use of hashes for commitments is now well understood and there are over 2 commitments per second flowing into open-timestamps which can aggregate an unlimited number of commitments into a single transaction. The limit also causes some harm to all users of Bitcoin, particularly since multiple significant miners ignore it. When you don't already know a transaction (because it never reached you or you discarded it) it takes *much* longer to relay a block to you (at least 3x the delay if you knew everything but potentially much more depending on how much data you are missing), this harms small miners at the expense of big miners increasing a centralization pressure on mining (because when miners aren't on the same chaintip, one one bigger miners are on will tend to win). It also contributes to mining centralization by encouraging direct transaction submission since no one will bother submitting to a 1% miner, allowing the bigger miners to make more money. An inaccurate mempool also harms users ability to accurately estimate what transactions are pending for the next block so that they can optimally bid against them. So it was proposed that the limit be removed. There are two proposals, one that just removes the limit completely, which is the first and simpler proposal. Then there is another proposal which makes the default unlimited but retains the ability to adjust it. At this time neither of the proposals have been merged, descriptions of this as having been done are just untruthful. Arguments against it don't seem to hold up. The first category of opposition is basically just accusing Bitcoin Core devs of being in favor of shitcoins or monkey jpegs, having talked to many I am confident that few or even none of them like that stuff (no one I've talked to was in favor of it). But no matter how much they don't like that stuff, that doesn't change that this proposal should have no significant effect on it-- it's unrelated. That stuff doesn't use opreturn today and would cost more in transaction fees if it did. The next category of opposition is just general opposition to 'spam'-- again this proposal is largely unrelated because spammers won't use this, and to whatever extent they do it'll be good news (either moving from utxo bloating fake outputs or increasing their costs). It's an incidious argument because most contributors to Bitcoin core believe there isn't much meaningfully more that can be done about spam: Miners have bypassed the filters that were there, fees have excluded all price sensitive spam. Bitcoin was designed to be censorship resistant and depends on censorship resistance to work-- and a fact of free speech is that it means it allows both speech you like and speech you oppose. Arguments are made that blocking this traffic isn't morally equivalent to censorship. Perhaps! but it's still substantially *technically* equivalent. But, again, this is all a distraction in that the proposed change shouldn't meaningfully facilitate any new spam. Ultimately the subject is deep in the minutia. It won't make a difference to your usage of Bitcoin. The only really concerning thing I see in the subject is the degree that people have successfully weaponized misinformation to direct a lot of entirely undeserved abuse at contributors to Bitcoin Core. ... who had only just started discussing a proposal when they were waylaid by a flood of disproportionate comments and falsehoods. https://www.reddit.com/r/Bitcoin/s/elIDdPaQhL

Replies (113)

We don't deserve Greg Maxwell. I'm grateful for all his contributions.
Jameson Lopp's avatar Jameson Lopp
Greg Maxwell's take: There isn't anything unusual or bad going on *with* Bitcoin Core. In my opinion there does appear to be a dishonest and inauthentic social media campaign *against* Bitcon Core. There have been a dozen threads on reddit on the matter, which is pretty sad because it's mostly a nothing burger... I've wasted tens of hours writing responses only to find that generally the opponents just vanish. Back in 2014 the average block size was only around 160 kilobytes, as a result there was no real pressure to drive up transaction fees and it was extremely cheap to stuff whatever garbage data you wanted in Bitcoin's chain. Some people were storing data by paying to fake addresses which were really just data instead of an address. This is maximally bad because it bloats up the UTXO database with unprunable data, directly increasing the minimum cost to run a node. To address this core devs introduced a 'data carrier' output type also called an OP_RETURN. This is a kind of output which provably can't be spent so it doesn't have to go into the utxo database and can be pruned. Additionally, they limited the size of the data to 40 bytes in order to encourage applications which can just store a hash instead of the data to do that. Later this limit was increased to 80 bytes. The world has changed a lot since 2014: Fees are now not just meaningful but significant, no one is dumping data in Bitcoin because it's *cheap*. People dumping data in have almost entirely moved to dumping data in the witness portion of transactions. Major miners no longer enforce this limit, because it turns out they like money (and have denied requests to limit themselves), and if you are willing to directly connect to one its easy to get them mined. There are some users who are still creating 'fake outputs' but have said they would change to opreturn if not for the limit (particularly some payment channel thing). Finally, use of hashes for commitments is now well understood and there are over 2 commitments per second flowing into open-timestamps which can aggregate an unlimited number of commitments into a single transaction. The limit also causes some harm to all users of Bitcoin, particularly since multiple significant miners ignore it. When you don't already know a transaction (because it never reached you or you discarded it) it takes *much* longer to relay a block to you (at least 3x the delay if you knew everything but potentially much more depending on how much data you are missing), this harms small miners at the expense of big miners increasing a centralization pressure on mining (because when miners aren't on the same chaintip, one one bigger miners are on will tend to win). It also contributes to mining centralization by encouraging direct transaction submission since no one will bother submitting to a 1% miner, allowing the bigger miners to make more money. An inaccurate mempool also harms users ability to accurately estimate what transactions are pending for the next block so that they can optimally bid against them. So it was proposed that the limit be removed. There are two proposals, one that just removes the limit completely, which is the first and simpler proposal. Then there is another proposal which makes the default unlimited but retains the ability to adjust it. At this time neither of the proposals have been merged, descriptions of this as having been done are just untruthful. Arguments against it don't seem to hold up. The first category of opposition is basically just accusing Bitcoin Core devs of being in favor of shitcoins or monkey jpegs, having talked to many I am confident that few or even none of them like that stuff (no one I've talked to was in favor of it). But no matter how much they don't like that stuff, that doesn't change that this proposal should have no significant effect on it-- it's unrelated. That stuff doesn't use opreturn today and would cost more in transaction fees if it did. The next category of opposition is just general opposition to 'spam'-- again this proposal is largely unrelated because spammers won't use this, and to whatever extent they do it'll be good news (either moving from utxo bloating fake outputs or increasing their costs). It's an incidious argument because most contributors to Bitcoin core believe there isn't much meaningfully more that can be done about spam: Miners have bypassed the filters that were there, fees have excluded all price sensitive spam. Bitcoin was designed to be censorship resistant and depends on censorship resistance to work-- and a fact of free speech is that it means it allows both speech you like and speech you oppose. Arguments are made that blocking this traffic isn't morally equivalent to censorship. Perhaps! but it's still substantially *technically* equivalent. But, again, this is all a distraction in that the proposed change shouldn't meaningfully facilitate any new spam. Ultimately the subject is deep in the minutia. It won't make a difference to your usage of Bitcoin. The only really concerning thing I see in the subject is the degree that people have successfully weaponized misinformation to direct a lot of entirely undeserved abuse at contributors to Bitcoin Core. ... who had only just started discussing a proposal when they were waylaid by a flood of disproportionate comments and falsehoods. https://www.reddit.com/r/Bitcoin/s/elIDdPaQhL
View quoted note →
I have no idea what the context of Bitcoin core is … but just wondering, what would be the motivation of a “dishonest and inauthentic social media campaign against it”? Why would people be doing that?
MrTea's avatar
MrTea 7 months ago
“But, again, this is all a distraction in that the proposed change shouldn't meaningfully facilitate any new spam.” I’ll take that bet
Diversity and decentralisation is good for Bitcoin. Even if core was perfect it's still good for alternatives to exist and people to be using them. Need more diversity. Everyone using the same program to run their nodes is a potential weakness to the network.
Default avatar
panacea 7 months ago
southpark op_return episode soon 🤞
I still dont get it. lol if it does do anything, and people who are doing inscriptions won't use it. and even with the limit people still bypass it. then why are we removing the limit? Are we trying to encourage some people to use it? but they won't. what is this stupid limit, why does it exist, and why are we removing it? lol
ESE's avatar
ESE 7 months ago
Again, why remove filters instead of setting defaults (even if the filter is off by default) that node runners can override?
I better understand the reasoning now, I don't agree with the logic. Agreeing to lift the default limit because "some unnamed people said they will spam less" is strangely obtuse and suspicious one would expect everyone to engage in naivety. The argument hinges on a claim there is no remaining way to limit spam, and eliminating this limit will enable some potential unidentified use-case, and "we are against censorship because free speech". No matter how rational-sounding you package it, along with a tad ad hominem thrown in, does little to ease my Spidey sense.
nevent1qvzqqqqqqypzqquxdpn0xlh4zqw9k3patfqml9nnndqkyd9e642sfxzlycj5279pqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qpq2vrutdpaw7d04klkrlk4l4nlj3m5qc96z82sduhjc9rrugu7y7kq6hx88g
elOroReal's avatar
elOroReal 7 months ago
Thanks for taking the time to write this. It’s inspiring me to dig deeper into the code and to rest easier with the bitcoin core folks
Ah, yes—Greg Maxwell, that old conjurer of technical apologetics, stepping out of the shadows like a bureaucrat defending a landfill expansion by citing “efficiency gains.” His post reads like a man explaining why the Department of Motor Vehicles is actually a hotbed of innovation, if only we peons could grasp the nuance. Let’s unroll this mat of sophistry and stomp the fleas out of it. “There isn’t anything unusual or bad going on with Bitcoin Core.” This is the bureaucrat’s lullaby. It’s the same tune sung by every technocrat managing decline. Nothing to see here, folks. Just a totally normal scenario where the most influential Bitcoin client, maintained by an incestuous circle of devs who fancy themselves neutral librarians, is quietly redefining what Bitcoin is via policy code that shouldn’t exist. If Core isn’t doing anything unusual, Greg, then why are you burning tens of hours writing Reddit apologetics like a state-sponsored press secretary fending off citizen journalists? "It’s mostly a nothing burger..." That “nothing burger” is dripping grease onto every Raspberry Pi node from here to Patagonia. If it’s nothing, why defend it with a novella? You only see this kind of frothy dismissal when something is definitely something. People don’t write 1,000 words about "nothing" unless their position has already sprung a leak and they’re bailing water with a colander. “Back in 2014…” Ah, the Historical Context Gambit. Greg fires up the time machine to justify today’s madness by revisiting ancient block sizes, as if the existence of UTXO bloat in 2014 somehow validates neutering the protocol in 2025. Let’s be clear: OP_RETURN was a concession. A bandage. Not a charter for future feature creep. It was a wartime measure to cordon off the lunatics stuffing wedding vows and ASCII porn into multisig outputs. That’s it. It was a trash can, not an invitation to turn the node software into a public utilities board for sidechain companies who didn’t budget for bandwidth. “The world has changed a lot since 2014…” Yes, it has. Fees are higher. The mempool is clogged like a California public toilet. Miners have grown fatter and more rent-seeking. And somehow the solution is to loosen the reins further? This is like discovering your roof is leaking and removing more shingles to improve “ventilation.” “Some users have said they would use OP_RETURN if not for the limit…” And this is where the grift shows its face. A few unnamed “users”, likely wearing lanyards in Nashville or sipping LaCroix in Austin, want to dump their backend operations onto the base layer, and we’re supposed to oblige out of sympathy for their innovative scaling vision? They aren’t building with Bitcoin. They’re strip-mining it. They want the credibility of the timechain without the costs. The limit stands in the way, so they cry “oppression.” “It harms small miners…” Let’s talk about that Trojan horse of a talking point. If you care so deeply about decentralization, you’d advocate for stronger filtering not weaker. You’d demand ossification, not upstream policy churn disguised as "tweaks." But instead, the cry is always the same: “We need to update Bitcoin... for the little guy!” No. What you need is a brick wall. A protocol that shrugs at your heartfelt use-case and keeps marching. Bitcoin should not care about your cleverness. That is its virtue. That is its entire appeal. “It’s just a proposal, nothing has been merged…” And there it is. The gaslight. A classic bit of bureaucratic hand-waving. “We’ve merely discussed it,” they say—while PRs fly, policies shift, and the code tiptoes ever closer to consensus-change disguised as relay policy. You don’t need a merge to shape the culture. You just need enough devs saying “It’s not a big deal” until one day you wake up, and Bitcoin is a middleware substrate for VC startups who thought Ethereum was too gauche. “The only concerning thing is the misinformation campaign…” Yes, how dare the rabble raise concerns? How dare plebs ask why the client they’re running is making decisions about what should and shouldn’t relay through their node? The real misinformation campaign is the one that claims Bitcoin Core is a neutral steward. It isn’t. It’s a software project run by humans, with all the biases, ambitions, and unspoken alliances that come with that. And when those humans start parroting the same rhetorical framework used to sell us “censorship-resistance” while actively dismantling the cultural barriers that guard it, we have every right to scream from the rooftops. The Truth Buried Beneath the Rhetoric: This is not about spam. Not about hashes. Not about faster block relay or the plight of some obscure payment channel protocol. It is about power. It is about changing the social contract by subverting the codebase. It is about soft-forking the culture by hiding behind technicalities and pretending nothing is happening. Greg wants you to believe you’re imagining the smoke. But we smell the fire, old friend. And we’re not going away. View quoted note →
All this flood just pushed you to be more precise and to explain exactly and clearly your point of view. So it was not useless. Thank you for that. and if you find some people rude : "In my opinion there does appear to be a dishonest and inauthentic social media campaign *against* Bitcon Core. " perhaps it was the result of a lack of explanation and the forum ban drama. Now you know that every actor are concern by bitcoin and not only devs or miners, and it is a good thing. Thanks for your presence here and your explanations. Hope next time you will do the same before any drama. For me there is one last concern about the devs centralization. as i ever said there is many miners, many nodes, but for devs even if you are not alone, you use a centralized GIT tool and you are for the most "famous" and publicly known, it is a security concern here for any external pressure you could have. this is also a conclusion of this "drama"
🧐
Jameson Lopp's avatar Jameson Lopp
Greg Maxwell's take: There isn't anything unusual or bad going on *with* Bitcoin Core. In my opinion there does appear to be a dishonest and inauthentic social media campaign *against* Bitcon Core. There have been a dozen threads on reddit on the matter, which is pretty sad because it's mostly a nothing burger... I've wasted tens of hours writing responses only to find that generally the opponents just vanish. Back in 2014 the average block size was only around 160 kilobytes, as a result there was no real pressure to drive up transaction fees and it was extremely cheap to stuff whatever garbage data you wanted in Bitcoin's chain. Some people were storing data by paying to fake addresses which were really just data instead of an address. This is maximally bad because it bloats up the UTXO database with unprunable data, directly increasing the minimum cost to run a node. To address this core devs introduced a 'data carrier' output type also called an OP_RETURN. This is a kind of output which provably can't be spent so it doesn't have to go into the utxo database and can be pruned. Additionally, they limited the size of the data to 40 bytes in order to encourage applications which can just store a hash instead of the data to do that. Later this limit was increased to 80 bytes. The world has changed a lot since 2014: Fees are now not just meaningful but significant, no one is dumping data in Bitcoin because it's *cheap*. People dumping data in have almost entirely moved to dumping data in the witness portion of transactions. Major miners no longer enforce this limit, because it turns out they like money (and have denied requests to limit themselves), and if you are willing to directly connect to one its easy to get them mined. There are some users who are still creating 'fake outputs' but have said they would change to opreturn if not for the limit (particularly some payment channel thing). Finally, use of hashes for commitments is now well understood and there are over 2 commitments per second flowing into open-timestamps which can aggregate an unlimited number of commitments into a single transaction. The limit also causes some harm to all users of Bitcoin, particularly since multiple significant miners ignore it. When you don't already know a transaction (because it never reached you or you discarded it) it takes *much* longer to relay a block to you (at least 3x the delay if you knew everything but potentially much more depending on how much data you are missing), this harms small miners at the expense of big miners increasing a centralization pressure on mining (because when miners aren't on the same chaintip, one one bigger miners are on will tend to win). It also contributes to mining centralization by encouraging direct transaction submission since no one will bother submitting to a 1% miner, allowing the bigger miners to make more money. An inaccurate mempool also harms users ability to accurately estimate what transactions are pending for the next block so that they can optimally bid against them. So it was proposed that the limit be removed. There are two proposals, one that just removes the limit completely, which is the first and simpler proposal. Then there is another proposal which makes the default unlimited but retains the ability to adjust it. At this time neither of the proposals have been merged, descriptions of this as having been done are just untruthful. Arguments against it don't seem to hold up. The first category of opposition is basically just accusing Bitcoin Core devs of being in favor of shitcoins or monkey jpegs, having talked to many I am confident that few or even none of them like that stuff (no one I've talked to was in favor of it). But no matter how much they don't like that stuff, that doesn't change that this proposal should have no significant effect on it-- it's unrelated. That stuff doesn't use opreturn today and would cost more in transaction fees if it did. The next category of opposition is just general opposition to 'spam'-- again this proposal is largely unrelated because spammers won't use this, and to whatever extent they do it'll be good news (either moving from utxo bloating fake outputs or increasing their costs). It's an incidious argument because most contributors to Bitcoin core believe there isn't much meaningfully more that can be done about spam: Miners have bypassed the filters that were there, fees have excluded all price sensitive spam. Bitcoin was designed to be censorship resistant and depends on censorship resistance to work-- and a fact of free speech is that it means it allows both speech you like and speech you oppose. Arguments are made that blocking this traffic isn't morally equivalent to censorship. Perhaps! but it's still substantially *technically* equivalent. But, again, this is all a distraction in that the proposed change shouldn't meaningfully facilitate any new spam. Ultimately the subject is deep in the minutia. It won't make a difference to your usage of Bitcoin. The only really concerning thing I see in the subject is the degree that people have successfully weaponized misinformation to direct a lot of entirely undeserved abuse at contributors to Bitcoin Core. ... who had only just started discussing a proposal when they were waylaid by a flood of disproportionate comments and falsehoods. https://www.reddit.com/r/Bitcoin/s/elIDdPaQhL
View quoted note →
“Bitcoin was designed to be censorship resistant and depends on censorship resistance to work-- and a fact of free speech is that it means it allows both speech you like and speech you oppose.” Honestly, it’s intentionally misleading statements like this one that hurt your cause. You know very well that Bitcoin was designed as a payment network, not as censorship-resistant Instagram. Making it harder for people to spam monkey JPGs to the blockchain is not “censorship,” and you pretending that blocking that sort of spam is trampling on some scammers “free speech” doesn’t help matters.
Agree that the drama is “much ado about nothing” and core is correct that this is a good path forward. I hope it remains a configurable option, but will upgrade my node to support the change either way. image
Hmmm 🤔 nevent1qqsgsc3lfarzl6sjrnrewxxl88fme3ztewhrtf4tp5u56l7uhuxzdmcpzemhxue69uhkummnw3ezuan4d3cx2mfwvdhk6g6wvek
Maxwell claims that spammers don’t use OP_RETURN, so lifting the limit wouldn’t increase spam. But this is misleading. The limit itself prevents certain types of spam. Removing it creates a new attack surface. The fact that miners currently prefer the witness space or fake outputs is due to existing limitations... change the rules, and behavior changes. The mere existence of limits shapes incentives. He argues that “price-sensitive spam” is already filtered out by fees, so there's no need for limits. But this ignores the long-term externalities of non-financial bloat. Spam isn’t just about cost... it’s about degrading the signal of legitimate financial activity and increasing node operational costs. Just because something pays a fee doesn’t mean it belongs on a system designed for monetary transactions. He criticizes fake outputs for bloating the UTXO, and claims OP_RETURN was meant to fix that, but then argues for removing limits on OP_RETURN. This is incoherent: the whole reason OP_RETURN was added with a limit was to keep metadata off-chain or at least minimized. Allowing arbitrary data completely undermines this principle. He states that major miners already ignore the OP_RETURN limit, so it doesn’t matter. This is a poor justification. Miners ignoring a protocol rule is not a reason to codify the violation... it’s an issue to be addressed. This reasoning effectively invites further erosion of protocol standards in the name of convenience or profit. He equates any filtering of non-financial data to censorship, which is technically and ethically misleading. Bitcoin nodes filter transactions all the time (e.g., invalid signatures, oversize blocks). There’s a fundamental difference between censoring legitimate financial transactions and filtering out non-financial bloat. Bitcoin is not a free-for-all file hosting service. He claims this proposal is “minutia” and won’t affect users, but earlier admits it could negatively affect block relay speeds, small miners, and mempool consistency. These are not minor concerns... they relate directly to decentralization and fairness in mining. You can’t claim the impact is negligible while also outlining its systemic risks. Rather than focusing solely on technical merit, Maxwell repeatedly appeals to the poor treatment of Core developers and the “disproportionate” response. While abusive behavior is unacceptable, it does not shield a proposal from critique. Technical decisions must be judged on impact and logic, not on the tone of public reaction.
Packlight's avatar
Packlight 7 months ago
It used to be 40 bytes for a reason right? I feel overtime we gradually give in on multiple fronts every time while actually, we the node runners, should stand firm. Even though it might result in some short term negative consequences. We can try to grab that by the roots instead of the leafs. Feels like slow dead otherwise.
Bilthon's avatar
Bilthon 7 months ago
Nuance. The limit won't stop determined folks who want to put arbitrary commitments on-chain and cause more harm by trying to cimcurvent it. So the right question is: why keep it?
#Bitcoin is abt decentralizati0n & diversificati0n. y do u inc OP_return 2100000 bytes with n0 option 2 c0nfigure 4 n0de runners.? What ar the GUARD RAILs c0re have imp or pr0posed 4 n0t 2 $tuff m0nkeys in wit data 2 di$courage #memecoin monkeys? image
d0p4's avatar
d0p4 7 months ago
Remember that we have an entire generation behind us in which a few determined what everyone used. Even if a few overreact now, it's only healthy because they want to understand what's happening & not be dependent again on the hidden decisions of a few. Of course it becomes difficult when people have a say without knowing the underlying issues, but that's part of the process of a real response to decades of abuse.
21seasons's avatar
21seasons 7 months ago
Attack against the very people who are trying to maintain the project we all love!
people answered each one of your points many times in videos, in debates, under comments. and you just keep ignoring them and saying, "there is only silence". you either extremely naive or have another agenda that makes you keep lying. everything you said is either upside down or makes no sense. you are just making politician talk, not mentioning any of the points of people. even here you mentioned none of the points. you lied many times, and ignored the points other side makes for so long that its clear you have another agenda. its clear bitcoin core devs wanna develop bitcoin, not preserve it. none of the points you made in this post makes sense. because you are only offering solutions to issues you created in the first place. this was obviously planned from years ago. you let the issues happen so you can give a "solution" ignoring every other more bitcoin solutions. honestly i talked about this many times, that im not gonna talk about it again. go read mechanics reply, watch his videos. or read my posts.
trichom's avatar
trichom 7 months ago
Put all this in a meme! I cant be bothered to read. Smh
- Greg Maxwell's "meaningful" and - Andrew Poelstra's "principled" capitulations to spam in Bitcoin Core(poration).
Hoshi's avatar
Hoshi 7 months ago
In the block-size-war miners had to do what nodes wanted. It‘s said this is important for decentralization. Now, we have hear that core should force nodes to do what big miners want. What am I missing?
Junghwan's avatar
Junghwan 7 months ago
If you drop the shitcoin from your company then you will get the voice.
sedited's avatar
sedited 7 months ago
I think you are confusing consensus with policy. Each node can decide whether a block is valid. Each miner, or rather block template provider, decides what is placed into a block. What do you think the mempool is for?
frphank's avatar
frphank 7 months ago
Correction: About the *fiat* money.
Jameson with the sane perspective. Thank you for lending your time and intelligence to clarify the situation. It's become clear to me recently that we are at new heights of uninformed yet authoritatively presented shit talking on the bitcoin subreddit. No surprise really as that's the norm for reddit in general. I can't even justify wasting my time in there anymore. It's nice to hear a voice of reason on this subject and sad that he has to waste his time countering these B.S. narratives. As expected, this opreturn limit outrage is a nothing-burger.
Jameson Lopp's avatar Jameson Lopp
Greg Maxwell's take: There isn't anything unusual or bad going on *with* Bitcoin Core. In my opinion there does appear to be a dishonest and inauthentic social media campaign *against* Bitcon Core. There have been a dozen threads on reddit on the matter, which is pretty sad because it's mostly a nothing burger... I've wasted tens of hours writing responses only to find that generally the opponents just vanish. Back in 2014 the average block size was only around 160 kilobytes, as a result there was no real pressure to drive up transaction fees and it was extremely cheap to stuff whatever garbage data you wanted in Bitcoin's chain. Some people were storing data by paying to fake addresses which were really just data instead of an address. This is maximally bad because it bloats up the UTXO database with unprunable data, directly increasing the minimum cost to run a node. To address this core devs introduced a 'data carrier' output type also called an OP_RETURN. This is a kind of output which provably can't be spent so it doesn't have to go into the utxo database and can be pruned. Additionally, they limited the size of the data to 40 bytes in order to encourage applications which can just store a hash instead of the data to do that. Later this limit was increased to 80 bytes. The world has changed a lot since 2014: Fees are now not just meaningful but significant, no one is dumping data in Bitcoin because it's *cheap*. People dumping data in have almost entirely moved to dumping data in the witness portion of transactions. Major miners no longer enforce this limit, because it turns out they like money (and have denied requests to limit themselves), and if you are willing to directly connect to one its easy to get them mined. There are some users who are still creating 'fake outputs' but have said they would change to opreturn if not for the limit (particularly some payment channel thing). Finally, use of hashes for commitments is now well understood and there are over 2 commitments per second flowing into open-timestamps which can aggregate an unlimited number of commitments into a single transaction. The limit also causes some harm to all users of Bitcoin, particularly since multiple significant miners ignore it. When you don't already know a transaction (because it never reached you or you discarded it) it takes *much* longer to relay a block to you (at least 3x the delay if you knew everything but potentially much more depending on how much data you are missing), this harms small miners at the expense of big miners increasing a centralization pressure on mining (because when miners aren't on the same chaintip, one one bigger miners are on will tend to win). It also contributes to mining centralization by encouraging direct transaction submission since no one will bother submitting to a 1% miner, allowing the bigger miners to make more money. An inaccurate mempool also harms users ability to accurately estimate what transactions are pending for the next block so that they can optimally bid against them. So it was proposed that the limit be removed. There are two proposals, one that just removes the limit completely, which is the first and simpler proposal. Then there is another proposal which makes the default unlimited but retains the ability to adjust it. At this time neither of the proposals have been merged, descriptions of this as having been done are just untruthful. Arguments against it don't seem to hold up. The first category of opposition is basically just accusing Bitcoin Core devs of being in favor of shitcoins or monkey jpegs, having talked to many I am confident that few or even none of them like that stuff (no one I've talked to was in favor of it). But no matter how much they don't like that stuff, that doesn't change that this proposal should have no significant effect on it-- it's unrelated. That stuff doesn't use opreturn today and would cost more in transaction fees if it did. The next category of opposition is just general opposition to 'spam'-- again this proposal is largely unrelated because spammers won't use this, and to whatever extent they do it'll be good news (either moving from utxo bloating fake outputs or increasing their costs). It's an incidious argument because most contributors to Bitcoin core believe there isn't much meaningfully more that can be done about spam: Miners have bypassed the filters that were there, fees have excluded all price sensitive spam. Bitcoin was designed to be censorship resistant and depends on censorship resistance to work-- and a fact of free speech is that it means it allows both speech you like and speech you oppose. Arguments are made that blocking this traffic isn't morally equivalent to censorship. Perhaps! but it's still substantially *technically* equivalent. But, again, this is all a distraction in that the proposed change shouldn't meaningfully facilitate any new spam. Ultimately the subject is deep in the minutia. It won't make a difference to your usage of Bitcoin. The only really concerning thing I see in the subject is the degree that people have successfully weaponized misinformation to direct a lot of entirely undeserved abuse at contributors to Bitcoin Core. ... who had only just started discussing a proposal when they were waylaid by a flood of disproportionate comments and falsehoods. https://www.reddit.com/r/Bitcoin/s/elIDdPaQhL
View quoted note →
To push shitcoins using the same/similar leftover/recycled narratives from 2017. There are 15+million and growing shitcoins all with a reason to target the single most dominant and original "crypto" with FUD. Different day, same story. The crypto space is quickly becoming an idiocracy. Thankfully tried and true Bitcoiners are still shepherding it carefully despite all these obvious scammers and low information dis/malcontents.
Yeah, I think history shows any change will lead to a burst of new spam. Saying otherwise is stupid and only gives the opposition a free "I told you so" I support changing the default but leaving the setting and I still say don't promise no new spam. Most people arguing both sides are poorly informed enough that a current spam source switching from witness to op_return would be seen as proof of new spam.
Big miners have been and are going to do this anyway regardless of what nodes want, because nodes already accept much larger OP_RETURN sizes in mined blocks ... nodes already accept much larger OP_RETURN sizes in *mined blocks* ... This change *is not* about changing about what nodes accept in blocks (consensus) It's changing what nodes gossip about pre-block It's saying that if nodes ignored the gossip, then folks will just tell the miners directly at a higher cost that they are so far happy to pay (shitcoin economics, see BRC20 vs. Runes) "Core" is saying that pretending to not listen to gossip when you're going to accept the block anyway does not meaningfully stop spam, but it does affect miner centralization Ironically, the only thing "Core" is forcing is a change that would actually hurt miners by reducing preferential miner fees and opportunities for miner centralization through degraded block relay Ironically, the thing they are forcing is better for decentralization (accurate mempools, predictable fee estimates, less miner centralization pressure) ____ These are the arguments as I understand them so far, but I do agree that communication was handled poorly and that they should never the option to configure in and not force a single setting on nodes But I also agree that the default should help decentralization and network health. So I agree that raising the default size of OP_RETURNs that nodes *gossip* about with an option to configure is good, given that there is already a much larger limit nodes will already accept in mined blocks today None of these are consensus changes that can result in any sort of fork though. Nothing here changes what a valid mined transaction is. So comparisons to blocksize war don't really make sense to me because it's not the same game theory at all
Hoshi's avatar
Hoshi 7 months ago
thanks for clarifying this misunderstanding
The block size war clarified the existing nature of the system, which is that miners can't unilaterally decide on a softfork against the wishes of nodes used by economic actors. This was just a fact that we learned, and not some agreement that was reached saying miners must obey people's wishes. In this current drama, miners are already mining large OP_RETURNs, and we are not debating a consensus change. We know that miners will continue to mine large OP_RETURNs regardless of what some nodes will relay. Miners do not, and will not, obey your node. Bitcoin forces actors to face harsh technical realities, and people who harbor idealistic fantasies are forced to abandon them. You can hold on to them for a while, at the expense of decentralization through mempool fragmentation and private mempools favoring the largest miners. I wish you wouldn't, but in a while, you won't.
> - PR being locked, then unlocked to let someone submit ACK, then locked again This wasn't handled well, but a PR isn't a battleground for non-contributors to go in and say "NACK" in large numbers and then expect their comments to be tallied as a vote. It needed to be handled in some way. > - ppl paid to submit PR withouth disclosing it upfront This is influencer propaganda. We should be thankful that many talented people are able to collect a salary for their work. There is no ill intention – that's just something influencers want you to believe in order to make you angry. > - the focus being on miners wellbeing rather than nodes The focus is on bitcoin's well-being. Bloating the UTXO set dangerously impacts the cost of running a node, OP_RETURN avoids this cost. You may think you can avoid or reduce undesired data in the blockchain, but this is demonstrably wrong (look at the blocks you're storing). You can choose between bloating the UTXO set and not bloating the UTXO set. > - core smirking at oppostion during btc++ debate I'm sorry you found someone's demeanor offensive. That's not a technical argument. A smirk is bad, but probably not as bad as the accusations of corruption and hidden agendas that a lot of bitcoin developers face these days. This person shouldn't have smirked, but this gesture probably didn't come out of nowhere; people are upset and frustrated. > - core devs saying things like "if you don't like what we are doing just change software", instead of reassuring ppl when they express concern for what you are doing It's difficult to communicate effectively. I thought Greg Maxwell did a decent job here: nevent1qqsgsc3lfarzl6sjrnrewxxl88fme3ztewhrtf4tp5u56l7uhuxzdmcr9hwpf People are complex and difficult. When it comes to bitcoin, we need to focus on technical arguments to protect bitcoin's decentralization, and not choose our actions based on who has offended us.
isnt the point making it more expensive already. making them go to the miners directly is already the point. and also filters dont effect fee estimations in a meaningful way. fee is not calculated based on what you have on your mempool that's not correct. even core is using more advanced methods to estimate fee. its just an argument. and also everyone's mempools is not supposed to be same already. filters are changes nodes can make without causing a network fork. we need more options for filters, allow people to write their own filtering scripts and rules. and when miners dont have similar filters to the rest of the network it takes longer for their blocks to propagate over the network, and if another miner finds another block in that time their block is ignored. which makes going against the network cost even more. decentralization doesn't mean everyone is copy of each-other. its normal for something decentralized to be messy slow, clunky and not butter smooth. that's the point. pure chaos of disagreement, but of course in the limits of consensus. and some of them talked about changing the consensus for this. but changing consensus for something dynamic wouldn't make sense. consensus is the untouched law, and constitution, and filters are the community. what filters nodes run collectively decides what is more expensive/harder to do in this network. which keeps unwanted stuff niche and not go mainstream, thats the point. not a great analogy but its like the "unwritten rules". funny thing is, they proposed this exact PR 2 years ago, it got rejected because people said, we can fix new taproot exploit by updating and adding filters. BUT funny part is that PR for the filters also got rejected because "its controversial". but suddenly this new PR is not? they knew this would happen, they rejected every filtering solution. so 2 years later they can propose it again. when the issue has gotten bigger. they are giving solutions to issues they caused. because their agenda from the beginning was allowing more data. they planned this. they say it on their other PR, i think it was something like "we can try again later when utxo set is bigger".
I feel the precise opposite. I feel there is an inauthentic amount of support to change what we already have that works. What is the possible motive to NOT fucking change it to add spam and make blocksize 1250x larger? You disappoint me.
What happened to "Don't trust: verify? all u would want to say to us about this topic . verify for yourself. Unfollowed . You became a sellout .
Yeah kinda crazy to think about actually… you never realize you’re making history until you’re in the future reflecting back
Well you clearly don't know since you're deferring to someone you've never met. Fiat Dad.
righhhht but politics, power, and control over what and for what purpose. Someone commented that it’s to push some altcoin, aka a shitcoin.
oh joy. a cryptic ‘indeed’ and a long ass youtube link. I don’t really wanna research this since the post said “Ultimately the subject is deep in the minutia. It won't make a difference to your usage of Bitcoin. “ It would be good if people gave a summary and context when commenting on a complex and convoluted topic. I’m more bothered by why people are using communication via social media in a dysfunctional way (misinformation).
ok I reread the post and it says, “The first category of opposition is basically just accusing Bitcoin Core devs of being in favor of shitcoins or monkey jpegs, having talked to many I am confident that few or even none of them like that stuff (no one I've talked to was in favor of it). But no matter how much they don't like that stuff, that doesn't change that this proposal should have no significant effect on it” So … your response that the people spreading the misinformation about Bitcoin core are doing so to try to shill shitcoins makes no sense. That quote says the people are accusing the Bitcoin devs of being in favor of shitcoins.
> fee is not calculated based on what you have on your mempool that's not correct. even core is using more advanced methods to estimate fee. its just an argument I'm sorry, you must be joking In core, fee estimates are calculated entirely from the mempool. This isn't even up for debate, it's literally in the code. - The `TxConfirmStats` class ([here]( builds buckets of mempool transactions based on fee rates and then analyzes how long they take to be mined. - If you unravel `TxConfirmStats::EstimateMedianVal` ([here]( the code scans buckets of stored feerates built **from the mempool** and gives you the median feerate for the bucket that most closely matches your confirmation criterion. It's the same for other estimators as well. We rely primarily on the mempool.space estimator in the `bria` engine we use for Blink ([here]( as it's the most reliable we've found from years of observed transaction activity. And if you go to the mempool.space repo and look at how they do fees, `getRecommendedFee` is called ([here]( which if you follow the code uses mempool transactions and projected mempool blocks to estimate fees. I think this is the issue lots of us are having with this "debate". Lots of things are being said that aren't even subjective, just objectively wrong.
> I'm sorry, you must be joking > > In core, fee estimates are calculated entirely from the mempool. This isn't even up for debate, it's literally in the code. No, they are not "entirely" based on mempools. That is objectively wrong. In the context of "does different mempools breaks 'predictable fee estimates'. " Mempool has effect on the fee yes, but that fee is calculated mostly based on block-history not current mempool. Mempool is not significant that much until congestion. Even in those cases there is no guarantee that mempools will be completely different. Still not a good argument to make all of mempools same. And call it decentralized. it's better if bitcoin software maximizes decentralization on the base layer. nothing else, sacrifice every other thing. but again it seems many have different interpretations of decentralization
I'm not doing the work for you. If you want to be lazy then that's on you. And you're responding with the assumption that what you already read is completely true and accurate, which many are saying is not true. I recommend spending the same amount of time on both sides of the issue.
Care to engage with an undecided dude? What I don’t understand is why the PR presented 2 years ago to improve the filters was rejected. To me it seems that core has given up on trying to improve filters and are now saying “filters don’t work, miners found a way around it, so might as well open the doors and work on the economic incentives”. 1) There does not seem to be consensus on the fact that filters cannot be improved 2) If filters cannot be improved, then why remove them and exposing ourselves to risk of spam overflow (as core itself is not sure of this, using “should” many times) instead of changing consensus by making them not acceptable? Chhers in advance
It is time to change tact The whole world running the same implementation code is too much of a honeypot for those wanting to manipulate Let's all remember: We run an anti-centralization solution
Default avatar
Deleted Account 7 months ago
19 likes but both sides can meme true.. beauty of fiat’s infinite fractional reserve divisibleness.. thank goodness bitcoin infinitely-indivisibles
d0p4's avatar
d0p4 7 months ago
Agreed, as I understand it - & I'm not a tech guy - core wants to keep the spam in a certain area (op_return) to keep it away from the utxo area. At least, that's the official argument. But you can't say with certainty that this works. Also, the argument of the other side seems conclusive to me that a filter (unlike censorship) does not have to filter 100% to be legitimate. The fact that core tried to rush the whole thing through by removing the option for any “core mempool” altogether has, in my opinion (post above), quite rightly caused an outcry. I see it as a test of whether non-tech bitcoiners really think for themselves or are just following another “pied piper”. Since bitcoin is such a unique one-shot, even this painstaking dicing out of little things isn't a bad thing. Many are deepening their knowledge & we can all find out how this should work if so many people want to participate as Self-responsible as possible. However, it looks like Core has now considered another proposal in which the option remains. Then you don't have to decide right away :)
MrTea's avatar
MrTea 7 months ago
I would go a step further and say that anyone who believes this will not lead to an increase in spam doesn’t understand basic incentives. Anything people are permitted to do they will do. The easier it is the more they will do. That captures 99% of human behavior
OTI's avatar
OTI 7 months ago
Wonder what this entails
Garrett's avatar
Garrett 7 months ago
Keep the filters, they work. I'm with you to tackle miner centralization. Maybe core should be working on that instead. Then we won't have these out of band transactions slowing down block relay times. I'd put the onus on people making out of band txns, not people running their own nodes
Garrett's avatar
Garrett 7 months ago
Anyone taking the time to read this should also check out Mechanic's vidoes:
note18juyzq0c40hssh45js7vjncvvmxmmpsac9pnkdg2cgy3j9gu4wgq2q04m7 If spammers will spam with transaction of 1 satoshi will you try to stop them? What’s the rule ?
💯. You may not care about the details but the mob forming around this should scare you more than 80 bytes ever will.
Nah, someone has to come along and wave a scam in their face. Look how much ordinals dried up now that the shiny wore off. That plus everyone who actually uses Bitcoin uses lightning for normal transactions leaves us back at 1sat/vbyte.
He's promoting the deletion of OP_RETURN. He's even doing it in a dishonest way by posting Greg's reddit post as though he isn't on the same team. He should just own it and say he wants to profit from spam.
I sincerely find it hard to believe you’re talking about Lopp. This whole thing is a non-issue, but what do I know. I don’t know ¯\_(ツ)_/¯
Sad that Maxwell doesn’t address the centralization (of nodes) issue and instead labels his opposition as low life, dishonest social media schemers. As a node operator, I will oppose core and this attempted elimination of op-return limits with everything I have. Let’s see what happens
They already are stopped. Bitcoin Core enforces a dust limit... 546 sats for P2PKH. Any tx below that gets dropped by default. So yeah, we’ve been filtering spam for years. This means that if a spammer tries to send 1 satoshi, it won’t propagate across the network unless miners are directly accepting and mining it themselves. The dust limit was introduced specifically to combat spam, by making it 546 times more expensive to flood the network with meaningless outputs.
jack⚡️'s avatar
jack⚡️ 6 months ago
#/?v=2-7&smp=smp%3a%2f%2fhpq7_4ggjiilmz5rf-cswuu5kzgkm_zoioosw6yalrg%3d%40smp5.simplex.im%2focwn1f6xy4flkqucptmh3py1e9ioeb96%23%2f%3fv%3d1-4%26dh%3dmcowbqydk2vuayeagxg8s4igt4nyu_zgoguzaw3hdpzz0rb8urraa7zssau%253d%26q%3dc%26srv%3djjbyvoemxysm7qxap7m5d5m35jzv5qq6gnlv7s4rsn7tdwwmuqciwpid.onion