What do I do? Research: I publish chart filled data-driven reports on technical Bitcoin topics. Read at

The Mempool Open Source Project®

Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.

Business inquiries: I lead strategy and business development at @mempool. Reach out directly for questions about Mempool Enterprise & Accelerator

So many based bitcoiners at bcc8333 unconference. If you are in Barcelona check out their meetup

Meetup

Bitcoin Barcelona (BBO) | Meetup

**CAT:** Som el punt de trobada a la ciutat dedicat exclusivament a Bitcoin. Ens reunim per aprofundir en el protocol, la innovació, la cultura ci...

Block 900,000, had room to spare despite a celebratory meme inscription.

Unbelievable lack of use

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:

mempool research

UTXO Set Report

A data driven analysis of Bitcoin's unspent transaction output (UTXO) set revealing that almost half of all UTXOs are < 1000 sats, 30% of UTXOs are...

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

GitHub

Remove arbitrary restrictions on OP_RETURN by default by petertodd · Pull Request #28130 · bitcoin/bitcoin

Any number or size of data-carrying OP_RETURN outputs are allowed, and the -datacarrier option is removed. For those who want to limit data carryin...

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

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size - Luke Dashjr

The latest OP_RETURN war kicked off days prior to @btcplusplus mempool edition. very sus. In Austin to get to the bottom of this 👀

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.

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 😂

The recent pull request to bitcoin core made by peter todd (pull 32359) removes the code to enforce a policy limit on the size and number of OP_RETURN outputs. Additionally, he proposes the removal of the configuration options to allow node runners to modify the maximum size of data carrying transactions.