41.65% of the UTXO set is dust amounts precisely at the implied default core policy dust limits for various script types.
note: p2tr is the most popular 546 sat script type (68% of all 546 sat outputs). I guess degen wallets don't compute the actual dust limit?
Surprising facts from my new report on Bitcoin's UTXO set:
- 49% of UTXOs are sub 1000 sats
- 30% of UTXOs are inscriptions related
- 100k+ 10-year-old counterparty UTXOs store arbitrary data with fake multisig pub keys
Read it in full here:
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
Get yourself to a @btcplusplus
event, what @niftynei() 🇺🇸💸🧡 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.
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.
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.
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.