By popular request, here is the last years bitcoin transaction data with rune & BRC20 split out from other OP_RETURN and Inscription transactions.
Runes & BRC20 = 51% of transactions over the past 12 months
Over the past year bitcoin there have been more data storage transactions (inscriptions & OP_RETURN) than other transactions.
The most entertaining outcome is the most likely. Bookmark this.
Get yourself to a nostr:npub1dwah6u025f2yy9dgwlsndntlfy85vf0t2eze5rdg2mxg99k4mucqxz7c52
event, what nostr:nprofile1qqsvh300dvquh50l5t9et2257pxrsk5ndsdgdcdmnnxl9nc0f6l2ejcpp3mhxue69uhkyunz9e5k7qg4waehxw309ajkgetw9ehx7um5wghxcctwvsr0dtke and the team have built is truly special.
The difference between online and IRL discussion is stark.
Online we only see differences.
IRL people celebrate similarities.
What has changed since 2023, when pull 28130 was closed with the justification that “it's unlikely that Bitcoin Core is going to make any changes in regards to OP_RETURN”?
I’m seeing lots of speculation around the financial motivations with regards to modifying OP_RETURN standard core policy.
In 2023 Peter Todd was transparent with his financial incentive ($1000 from Christopher Allen) for making pull request 28130, which was ultimately closed
🎲 In 2014 Luke Dashjr described mining policies such as OP_RETURN size limits as not being a development topic, and suggested randomizing the default value.
https://gnusha.org/pi/bitcoindev/201411161724.19573.luke@dashjr.org/
The conversation is still locked. My guess would be a push behind a new pull which doesn’t remove configuration options and only changes defaults
The latest OP_RETURN war kicked off days prior to nostr:npub1dwah6u025f2yy9dgwlsndntlfy85vf0t2eze5rdg2mxg99k4mucqxz7c52 mempool edition. very sus. In Austin to get to the bottom of this 👀
The legend didn't render correctly
I've put some numbers together to help you determine whether the horse has already bolted regarding the use of bitcoin for non financial transactions.
49% the UTXO set is sub 1000 sat outputs
43% of transactions in the past 2 weeks had an OP_RETURN or were inscriptions.
I think there is a strong argument to be made that even if you hold the opinion that bitcoin is for financial transactions, not arbitrary data storage, the figurative horse has bolted and efforts to close the stable door are currently futile. The argument looks like this.
1) There are people who want to encode arbitrary data, and are willing to pay for this. Systems are being developed which use arbitrary data pushes to enable bitcoin financial transactions to happen on sidechains/layers, blurring the line between financial transactions and the arbitrary data most people think about (jpegs on the blockchain).
2) Blocking arbitrary data at the relay layer is a sisypheancan task which nobody has succeeded to do for a prolonged period of time.
3) Even if successful the relay network can and will be trivially bypassed if block template builders wish to accept these transactions which encode arbitrary data. So you need template builders to be on board (the more the better).
4) The current block template builders are not likely to be on board, as it goes against their short-mid term financial incentives. This is because they are typically
(a) disengaged / ambivalent about bitcoin development (see radio silence regarding new soft fork discussions)
(b) In favour of any and all use of blockspace which will increase revenue (see the direct submission services, use of librerelay, prevalence of side chain mining)
(c) Of the opinion that their fiduciary responsibility is to construct blocks containing valid transactions which generate the highest possible revenue for their customers.
4) Even IF you were able to successfully persuade template builders to filter these transactions (say by decentralising template construction into the hands of more ideological lower time preference miners) there will be disagreement about what level of data encoding is acceptable, with some arguing that it is permissible in certain formats, and with hardliners arguing that all arbitrary data should be eliminated. The fragmentation will result in some arbitrary data being trivially pushed into the chain.
5) Even IF you were able to persuade the overwhelming majority of hashrate to reject arbitrary data inclusion it becomes difficult to reliably get transactions which clearly encode arbitrary data into blocks, the data would end up being encoded in a slightly less efficient manner with a 2x cost burden.
6) If 2x cost burden is sufficient to stop arbitrary data encoding then it can easily be priced out. If not, all that effort would be wasted because it wouldn't achieve the desired outcome.
Knots does much more than a “simple” filter fix, and personally I don’t think it has enough reviewers to recommend it’s use
A message to those on team #fixthefilters - your time would be better spent earning sats, which you can then use to fund development of a bitcoin node implementation which implements your desired configuration options. It's a cat and mouse game and the cat is currently asleep.
adding policy rules as a non mining node makes about as much difference as posting your opinion on the github pull request
both sides agree on this 😂
Call for transparent development
In my opinion it is critical that bitcoin developers have an opportunity to verify that these nonstandard transactions don't pose DOS risks. With that in mind, it would be great to be able to perform benchmarking on these transactions prior to them being widely deployed on chain.
If you are building systems which use nonstandard transactions, I would love to discuss this with you!
I will post more about this in the future, if anything was unclear please comment below!
Note: There is also the set of transactions using upgrade hooks, where pretty much everyone benefits from not including certain transactions. Ideally we can ensure that there is no economic demand for these, because they make upgrades much easier.
If economic demand for these transactions grows, it is reasonable to expect that some miners will relax the policy rules on their blockmaker node to earn this extra revenue.
These transactions won't relay over the standard bitcoin core p2p relay, so they will either be submitted directly to the miner (e.g. slipstream) or over an alternate relay path (e.g. opreturn bot using libre relay). Once mined they will be downloaded by all nodes in the network.
From my perspective, it's inevitable that systems will be built to get valid transactions to miners if they can't be relayed p2p. This has already happened, and will likely continue to happen as people develop systems which require the use of nonstandard transactions.
Ideally the standard transactions & DOS transactions sets don't intersect, that's the intention of most policy rules.
Note: There are some who believe that policy rules should be used to guide the use of the permissionless network. Personally I think this is a folly when there is an economic incentive.
It's relatively simple to ensure that the standard transactions and known DOS transactions don't intersect because they are both well defined. It's harder to know whether the standard transactions and the unknown DOS transactions don't intersect, but we can reason about how we would construct a DOS transaction and then add some policy rules. For example, we can set a limit on the total size of a transaction, which will presumably mean some unknown DOS transactions are now non standard (and our node is protected).
So to be prudent we can add in lots of policy / standardness rules to protect us from unknown DOS transactions, which makes our node less vulnerable. The tradeoff is that in doing this we also make some safe (non DOS) transactions non standard. Arguably this is what happened over the years with bitcoin core, and for good reason.
This is a key point when considering policy rules. Our understanding of what transactions potentially result in a DOS risk is undoubtedly incomplete, and the widespread adoption of current bitcoin core standardness rules might be protecting the network more than we realise. But, having strict policy rules is also making some perfectly safe transactions non standard. For miners, these non standard, known non DOS transactions represent a safe source of extra revenue.
