Replying to 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

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?

Reply to this note

Please Login to reply.

Discussion

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?

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

thanks for clarifying this misunderstanding

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

> 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](https://github.com/bitcoin/bitcoin/blob/8309a9747a8df96517970841b3648937d05939a3/src/policy/fees.cpp#L77)) 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](https://github.com/bitcoin/bitcoin/blob/8309a9747a8df96517970841b3648937d05939a3/src/policy/fees.cpp#L244)), 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](https://github.com/GaloyMoney/bria/blob/018f25b52f991886f1c6ee9713cee4ee641e8187/src/fees/client.rs#L23)) 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](https://github.com/mempool/mempool/blob/cba4308447341725587c232f77c102efc834d488/backend/src/api/fee-api.ts#L22])) 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

Ok I'm done, you're clearly trolling 😂😵

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.

Well said! More and more coming to this view too.