On the recent topic of removing/deprecating OP_RETURN relay-limits in Bitcoin Core.
I am grateful to BitcoinMechanic for playing a part in building my Bitcoin conviction through his participation in podcasts.
Sponsored by: OpenSats (currently between grants). Favorite pool: Ocean. Happy to see some healthy StratumV2 competition in DATUM.
Having started running a node more consistently for a few years, then worked on Core for just around one year, I feel like I have one foot in both worlds across the OP_RETURN divide.
Pure affinity scams can go fuck themselves. On the other hand, experimentation in how we make self-custody scale to more users is great. I haven't stumbled upon any solid arguments for/against in the case of Citrea, but haven't really cared to look.
From what little I've seen of the debate, I wish Core devs, including myself, would have spent more of their debate time steel-manning the pro filtering arguments. I worry that this alone has led to an impression of Ivory Tower / "Expert Class" / Paternalism. Hopefully this post can help alleviate some of that (and at least I can get it off my chest and get back to work).
In a world where there is only one homogeneous Bitcoin P2P network, filtering could work to discourage spam. While the main proposal to filter inscriptions was naive (bitcoin/bitcoin#28408 (comment)), I do like the concept of having something like dynamically loaded filtering rules (bitcoin/bitcoin#28408 (comment)).
(Suggestions on how to strengthen it are welcome!)
It looks like the next Bitcoin Core release (v30) is getting IPC - one could feed transactions to a filtering-executable that is updated much more frequently than the node software itself. Being able to deploy filters as soon as new forms of spam are developed could be very demoralizing to spammers in a homogeneous network.
Having new blocks with spam in them propagate slower due to nodes having filtered away the spam, giving an advantage to competing blocks from filtering miners to propagate faster, is an interesting dynamic. Push-back: I think the filtering would need to be extremely pervasive for it to have any material effect.
Making spam transactions have less chance of confirming in the next block works as a deterrent against spammers. Push-back: I don't think spammers care that much about quick confirmation. Accidentally filtering & delaying some acceptable L2 protocol would be bad though.
There could be a sweet spot, a major untapped market for spam between 80 bytes and ~140 bytes (after which storing data in the witness becomes more affordable). Removing the limit could lead to such a market appearing. If nodes then somehow successfully start filtering the OP_RETURNs, maybe this new market would have developed enough momentum to adapt to the new x bytes OP_RETURN limit + fake public keys landscape. Push-back: If there is such a market, wouldn't they just pay a teeny bit more and use witness data or OP_RETURN + fake pubkeys or bare multisigs today?
Some miners want to filter away spam either for ideological reasons or because they think it will increase the value of the asset as a whole. Push-back: They can sometimes delay spam that way, but "amoral" miners will probably always exist.
Fake pubkeys can be stopped through requiring valid signatures up front. Push-back: We could start doing that on a relay-level, but wallet software and hardware wallets would need to be updated to the new transaction format. Do we then store these extra signatures in some add-on section for each block similar to witness data? Some opponents say one can still grind data into subsections of pubkeys, but that at least forces a cost. And of course current consensus rules don't require these up-front signatures, so amoral miners can still mine them even if most of the network blocks them. We could hard-fork to require these up-front signatures. But we can't filter witness data on a consensus level, since spammers can move faster there than we can hard-fork in filters.
It's an attack on the self-determination of node runners to remove settings. Push-back: Yes, one great thing with Bitcoin is that node operators can run any node software they want. Another great thing is that Bitcoin Core is open source, and developers can shave off features that create perverse incentives (embedding data in public keys). Node operators are free to run whichever version of whichever node software they like. If Bitcoin Core would be subverted over a long enough time, other node software would become dominant.
Why stoke division by increasing/removing the limit? Isn't our energy best spent on changing/improving other aspects? This seems to be about some kind of ideological purity from the Bitcoin Core dev side. Commentary: Todd seems to enjoy controversy more than most. Other devs are focused on how quickly the block-subsidy shrinks and limiting mining centralization (see below for more detail). Removing the limit at a cost of trust and energy in the short term should free up energy in the long term, with trust being earned back. I think filterers could have put less energy on implying malice in Core devs and Core devs could steel-man more.
If filters don't work, why remove them? - Let's find out.
Why have I been inserting the homogeneous network caveat above? Peter Todd's Libre Relay is what convinced me to concede to increasing the OP_RETURN limit. Nodes that opportunistically peer with each other to ensure relay of spam transactions and are also run by large pools can simply route around even a very vast majority of filtering nodes.
UTXO set bloat is a weak argument in my book. A large UTXO set is annoying, but thanks to how old unspent outputs are flushed out from RAM to disk, and how look-ups on disk should be O(log N), consumer hardware should keep up. While a weak argument, I still see how it may tip many devs in favor of increasing the limit or even getting rid of it. Which in turn reignited the pro-filtering crowd.
Regarding concerns over compact block reconstruction failures due to frequent out-of-band transactions. Yes, to some extent... but there is also other work that could be done to improve compact blocks. See for example: https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/#how-can-this-be-adapted-for-even-faster-p2p-relay I also have the impression that the logic to include transactions that are probably unknown to the peer in the compact block messages is not fully explored, but could be wrong.
Even if Libre Relay was not effective, I think Luke Dashjr's Citrea filter is a bit crude: https://www.youtube.com/watch?v=J9bRVIXOhm0&t=12555s. Then again, the low diversity of bitcoin transactions probably makes this mostly acceptable.
There's this mempool <-> block template maximalism that seems to have grown among Core devs. The block subsidy is decreasing at a rate where transaction fees will probably start to become the majority of miner revenue in not that many epochs. Minimizing filtering by default ensures quickest possible propagation of transactions, and letting small miners get access to as high fee transactions as possible as soon as possible.
I think herein lies one discrepancy between Core devs and node runners: Node runners are concerned with what their current hardware is doing in the current epoch or two. Core devs are more concerned with miner centralization forces that grow in magnitude over time (custom tx acceleration tools etc). Maybe node runners are right in that trying to filter out spam in the short term makes Bitcoin's monetary use-case clearer to new adopters. This could lead to a virtuous cycle ending us up in a better place once the subsidy becomes painfully low (assuming Libre Relay is ineffective).
Maybe the backstory for this is largely different for filterers vs Core devs?
Chris Guida in a comment below linked to an article (https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/) which claims:
The key point of this article is to emphasise that the main driver for this was not necessarily fees or Ethereum’s virtual machine and Ethereum’s stronger technical capabilities, it is simply that many Bitcoiners and Bitcoin developers did not want Dapps on Bitcoin and they were not interested in these features.
What I get from the article is that 2014 bitcoin culture pushed away some level of spam usage, while Ethereum & others attracted these devs & users. It may be that we would have had a less successful 💩coin scene if Bitcoiners hadn't been so hostile (that would mean we would have had more spam on Bitcoin though, so I'm happy they were hostile).
My guess is that Counterparty switched from bare multisig to OP_RETURN for 2 reasons:
- Economic: Save on fees.
- Image: Behave better in a nascent market with many opinionated early adopters.
Regarding #1, providing a cheaper & less harmful way to do things is arguably in the same vein as the current push to increase the OP_RETURN limit.
Regarding #2, the market is much bigger and more diverse, meaning spam-protocol authors don't give a damn. Also the users sending JPEGs to each other probably have less urgency of transaction confirmation than token traders/dapp users.
The article also quotes Luke claiming "The miners are supposed to filter out abuses." This corresponds to the argument under the section "Moral/low time preference miners". Maybe if enough mining pools ran something like the frequently updated IPC-filtering executable (see "IPC to the rescue?" above), it could actually make an impact. It seems very unlikely that a meaningful fraction of miners would do so though. If it were impactful it would also risk false positives (valid but weird non-spam transactions being delayed).
AFAIK Libre Relay wasn't a thing in those times, and as spam-protocols were fewer and less lucrative (= slower rate of mutation), node-level filtering was slightly more effective.
Bitcoin Core devs like other humans have their flaws, but I believe the project is in good hands (although the number of devs would be nice to increase). At the same time, node runners switching to Knots is a welcome fire drill.
I like Greg Maxwell's rough idea of slight alternative implementations being made up of the Bitcoin Core source code signed by its developers + a fairly reviewable patch file signed by Knots maintainers. It pretty much requires node runners to build from source though.
At the end of the day, Bitcoin is a complex system. Nobody can predict exactly how different actors will behave in the short term. @chrisguida is working on Garbageman (https://github.com/chrisguida/bitcoin/tree/garbageman) to impersonate & eclipse attack Libre Relay nodes to render them less effective. However, having Libre Relay nodes returned by initial seed nodes would make that very hard.
Even though Bitcoin does not equal Bitcoin Core, we need checks on both. Not some 1984 Goldstein controlled opposition, but real scrutiny with sound arguments. Reflecting on my perception of this issue, I was tempted by group think initially, leaning on more experienced Core devs. Now that I've chewed on the arguments, I did end up mostly on the same side, but in a more grounded way than I was earlier. Then again, as the saying goes: It's hard to convince a man who's salary depends on the opposite, so take it for what it's worth.
I understand the urge to storm into a PR and repeat a variation of already posted arguments, having a vague recollection of doing such a thing in the past. There is a point in trying to stop a PR from getting merged, since getting it reverted will probably be harder.
It's saddening that GitHub doesn't provide better moderation tools than hiding/deleting comments and banning.
It would be better to hash out controversial changes in an arena that allows for bubbling up unique and high-quality arguments to the top, maybe falling back on web-of-trust to some extent.
Controversial PRs should probably be at least temporarily closed and let wider debate to occur elsewhere. After the dust has settled, if there is still rough consensus among frequent & experienced devs for the technical / incentive merits behind a change, it should be merged. If artificially frequent controversy happens, banning of tangential comments is more acceptable.
Most Core devs would probably welcome improvements to their tools, but don't see it as their job to build them. People arguing that Bitcoin is a mature asset and needs to be developed in a more grown-up way could invest in improving these tools. Jack Dorsey has a 10 BTC bounty in this vein: https://techstory.in/jack-dorsey-offered-10-btc-to-the-creator-of-decentralized-github/
No, as of writing this, no PR has even been merged containing the removal of the limit. The PR in this area that is closest to being merged increases the limit to the maximum that would fit in a transaction and deprecates the setting: bitcoin/bitcoin#32406. Bitcoin Core v29 released in April still has the limit at 80-ish bytes, same as v28. (On a consensus level one has been able to store ~1MB of OP_RETURN data per block since the op-code was introduced).
I think it is unfortunate to see this tear between what appears to be the majority of frequent Bitcoin Core devs and the currently most vocal group of node runners. Hopefully Core devs can earn back most of the trust with time. This podcast between Antoine Poinsot & Guy Swann, can hopefully be a step towards that: https://bitcoin-audible.castos.com/episodes/chat-133-bitcoin-development-controversy-with-antoine-poinsot (Antoine is the Core dev who brought up the issue for discussion on the mailing list and prompted Todd to post the recent PR, Guy is a friend of BitcoinMechanic and probably the most prolific bitcoin podcaster during the last decade).
As this can of worms of a debate has already been opened, and as the arguments above currently stand, I will ACK bitcoin/bitcoin#32406
Sorry, but generating fake controversy and brigading is trivial and it opens the door for people to exploit 'chaos' for unearned gains. Controversy has little real value.
With that said I find most of the contents in this gist controversial, what are you going to do about it? :)