Matthew Kratter is under appreciated.

My response to Greg -

>>There does appear to be a dishonest and inauthentic social media campaign *against* Bitcon Core.

I'll take the blame/credit for this as I've clearly been a major part of it - regardless of if you think I'm acting in good or bad faith. I of course believe that at least I and the others I work with are sincere and authentic.

>>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.

UTXO bloat sucks - obviously agree. Context though? Zero concern about 4GB -> 12GB bloating from 2023 to present. Sudden concern about Citrea and similar adding a couple of kilobytes a year? Mind if I take apparent concern about this with a grain of salt? Will reiterate further down.

>>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.

Yes. Which was sufficient for anyone who wants to use Bitcoin for data and do it in a plausibly respectful manner like Open Time Stamps does which no one is going to war about.

>>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.

Right!

>>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.

Sad. If it was easy the entire motivation for Core's two PRs would not exist. Citrea *want* the advantage of having *all pools* potentially mine their "transactions" - their design means using one pool that solicits out-of-band nonsense is not sufficient, even if they were prepared to pay the extra cost of a service like Slipstream. You are now missing a major chunk of the story. Not to mention the fact that witness-discount enjoying spammers were left to run amok without any consideration of adding Luke's filter which trivially prevented them. Arguments that it wouldn't work are being made by those who now unironically tell us the OP RETURN limit needs to be raised because it will prevent Citrea from using OP RETURN (which is cheaper for them) than fake pubkeys. This is completely self contradictory and somehow none of this is registering for you.

>>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).

Right. So the filters work and the last two years of pretending they're meaningless was complete nonsense. Thanks for admitting it I guess - I wish it was in service of FIXING them instead of REMOVING them.

>>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.

As mentioned, no one is going to war over this. Heck, Knots allows 40 bytes of OP RETURN by default as that was never a controversial compromise.

>>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.

Yes!! When mining is CENTRALIZED, the huge actors can bully the rest of the network a million ways, including blocks full of unknown transactions causing their blocks to take longer to process, making life harder for the tiny miners on the network.

But you are presumably aware that this attack is not prevented by nodes bending over backwards trying to become aware of every single possible thing on the planet a miner might conceivably wish to include in a block. Bitcoin does not require us all to have identical or even remotely similar mempools for any aspect of how it functions. It is also not meant to be relied upon whatsoever should mining become anything like as centralized as it is today.

So this point is somewhat ridiculous. Yes, nodes are on their back trying to keep up with how powerless they are in the current environment. But nuking all their mempool policies to try and level the playing field is not remotely realistic as a solution.

What you are pointing out here is technically true and utterly irrelevant when put in the current context.

Bitcoin running more optimally, has thousands of miners making their own templates rather than relying on a handful of pools. In that circumstance any MINER who starts filling blocks up with consensus-valid, but mempool-rejected junk suffers instead of the miners who don't. Their blocks propagate more slowly but it's *their* problem, not the network's.

Indeed, a long forgotten PR into Core in 2016 introducing Compact Blocks specifically warned *miners* that they should update to recent mempool policies in order to reduce their chances their blocks becoming orphaned.

We optimize for nodes, not a handful of template creators to which the entire world's hashrate is beholden to.

>>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.

I don't know who has made false claims in that regard. I have not. It's a messy situation so plenty of people are making inaccurate claims whether wittingly or otherwise. Sorry but it doesn't invalidate my entire stance.

>>Arguments against it don't seem to hold up.

Of course they do. Core is optimizing for miner centralization and trying to adapt nodes to accommodate Bitcoin in a state it cannot expect to operate in reliably for much longer. Over 51% of the hashrate is two, fully permissioned, KYC pools. The smaller of the two has 8 or 9 smaller pools it clearly operates the back-end for such as Braiins, Binance Pool, SEC Pool, Poolin', BTC(.)com and a few others. See stratum(.)work for unrefutable evidence of this.

Again, they can bully the rest of the network at such a size, and nodes trying to keep up by agreeing to relay junk against their own interest does not actually mitigate that attack.

At this point Bitcoin exists entirely thanks to the benevolence of Bitmain and Foundry. This makes us no better than any random cryptocurrency and it HAS to be fixed. Nodes relaying spam against their own interest are simply trying to remain relevant in a context in which they cannot.

>>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.

Currently you pretty much never see OP RETURNs between 80 and 150 bytes. Anything in that range remains cheaper than those exploiting the witness discount with inscriptions which only starts to become a net positive above 150 bytes or so.

Saying it will have no significant effect is just wrong. >99% of OP RETURNs in the blockchain are 80 bytes or less. After Core get this change through there will be an enormous number greater than 80 bytes. Assuming they will always use the inscription hack once they exceed 150 bytes is also not something we can flippantly do. There are situations where they would prefer to serialize the data instead of break it up into chunks separated by OP_PUSH as is necessary when inscribing. While more expensive, also far more useful as a troll as suddenly illicit data will trigger anti-virus software and make your laptop something you really don't want to carry through an airport if it has a copy of the blockchain on it. Some mitigations have been made in this regard but are only partially in use at the moment. This isn't something I feel like really using to push back on your overall dismissal of our concerns but it's probably worth noting.

The more general point is that I'm not saying Core are secretly shitcoiners. I'm saying they're being utterly gutless in putting up a real fight and instead are using a bunch of excuses to discontinue the approach older developers in the space had - telling these guys to f*ck *ff and not constantly accommodate them invoking all manner of excuses - and if you want to be frustrated, try arguing in favour of spam filtration - something we've been doing since Satoshi's time - while people invent horror stories about what it might do without any historical precedent whatsoever. Again, Bitcoin does not require that we have identical or even similar mempools for any aspect of what it does. Miners can only attack us if we filter if they are in a position to take over the whole network anyway.

Fee estimation, miner centralization, UTXO bloat. These are all little more than scare tactics here. You know how fee estimation works in Bitcoin Core. I'm willing to own the mistakes and inaccuracies made by people on my side of the aisle here. But how about Core stop making these technically-true points about fee estimates, miner centralization and UTXO bloat which become meaningless when put in appropriate context? Random Twitter anons and mysterious self-deleting reddit accounts - yeah I'm going to hold Corallo, Todd, and you to higher standards then them. So please stop invoking these nonsense arguments. Spam filters *do not come with tradeoffs anyone actually needs to worry about*. Yes they exist, but they are being exaggerated beyond all reason and burden of proof is on those who want to remove them - not us.

>>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.

"Spammers won't use this" - already addressed above. There is sweet-spot territory being unlocked here. You're completely ignoring the 81-150 byte range of currently inaccessible OP RETURNS which magically no one uses despite the only thing protecting it being these apparently useless filters.