The first

Dev Day brought a small group of Bitcoiners together at

, a London startup studio for Bitcoin founders, for a day of talks and open discussion.

Thanks to

we have a writeup of the day (videos coming soon™)

https://research.mempool.space/mempool-developer-day-1/

Can BIP110 lead to a chain split? What is Mandatory Signaling? What are the fork dynamics in play?

Find the answers - and simulate the outcome for any hashrate split - at http://bip110.orange.surf 👇

What are the best ways to reliably store a small encrypted blob of data for later retrieval not on your own hardware and not on chain?

Why does BIP110 permit runes, which are BY FAR the most used form of data embedding on bitcoin today?

I keep hearing BIP110 proponents describe their fork as being the safe option even with a minority of hashrate due to the "asymmetry" that the BIP110 chain can wipe out the legacy chain, but the legacy chain cannot wipe out the BIP110 chain.

This asymmetry is real for ANY soft fork, but it doesn't make a minority hashrate soft fork safe.

Softfork nodes reject legacy blocks, so they'll never reorg onto the legacy chain

Legacy nodes accept softfork blocks so they will reorg onto the softfork chain if it has more cumulative work.

Once again, If it has more cumulative work.

Nodes (including miner nodes) follow the most-work (valid) chain. A minority hashrate softfork chain accumulates work slower than the legacy chain.

With a minority of hashrate the BIP110 chain will not persist as the most-work chain, it will fall further and further behind over time.

The BIP110 chain could get lucky and get ahead temporarily, but over time the luck will run out and once it falls sufficiently far behind it won't ever catch up to the chain tip.

There's only two charts in bitcoin that matter, and price isn't one. The first is the hashrate and the second is the number of

merchants -

at

Glad I held off using the integrated primal wallet until now, I’m sure it was great UI but this is the way 🫡

It’s seamless, Phoenix > Primal in under 5 seconds, super clean design, and crucially zapping Just Works

There's been lots of debate about Core v30 removing the OP_RETURN size/count policy defaults, so I ran the numbers for the latest mempool research report: https://research.mempool.space/opreturn-report/

There were three big waves of OP_RETURN usage: 2019, 2024, 2025. Nearly all standard transactions. The nonstandard ones are so rare you can hardly see them on the chart.

The 2019 Veriblock wave actually put more data on-chain than anything since. People talk about recent OP_RETURN usage like it's unprecedented, but surprisingly it isn't.

The important thing is that the spikes in nonstandard OP_RETURNs were in Mar 2024, May 2025, Aug 2025. All before v30 shipped in November 2025. The rate hasn't gone up since. At all. In fact it's come down

Runes transactions were standard under the old rules and would even still be standard for #BIP110 (the proposal that's supposedly aims to curb data embedding). If these guys are serious about stopping data they should block runes.

TL;DR: v30 recognised what was already occasionally happening on-chain. Nonstandard OP_RETURNs are vanishingly rare, haven't increased post-v30, and the current wave is already cooling off. The data doesn't support the panic.

Read the full report linked below 👇

https://research.mempool.space/opreturn-report/

As signing device developers begin to add support for BIP322 it would be great to have on-device message viewing. I've sketched out an idea of how this could be done with QR & vis SD.

https://gist.github.com/orangesurf/0c1d0a31d3ebe7e48335a34d56788d4c

Sparrow just added address chunking which is really nice, I've made an extension to experiment with this on mempool, try it out and let me know if you have any feedback

📂 Get Extension Here:

https://github.com/orangesurf/mempool-chunker

It’s great to see so many people learning the difference between

• Bitcoin consensus vs policy
• UTXOs in RAM vs disk
• Hard vs Soft fork (& chain split)

Instead of copying long invoice strings, let’s use payment method cards

https://primal.net/orangesurf/bitcoin-payment-method-cards

The much discussed bitcoin stale block rate, visualised

Just noticed someone taking advantage of low fees by consolidating 59000 tiny utxos at 0.2 sat/vB across 40 transactions.

That's 4 blocks worth of transactions (3.999 vB) in total!

bc1q3k0swnar7s4w3lcp4u3vys826z8vc2f2t87hu5

wallet devs, are you ready to embrace sub-sat winter?

It's times like this that I'm glad I spent 2 minutes vibe coding a button to expand all hidden messages on the bitcoin github repo.

Code: https://github.com/orangesurf/github-unmoderated

opreturn stats for last month, you might be able to spot the previous default limit. What do you think October will look like?

Sub 1 sat/vB summer will be studied by generations to come

Seeing a few comments asking what can be done about data embedding with unspendable UTXOs (an issue which has been around for a long time).

This is a bit long, but hopefully it will be useful as a reference to the more general question of whether you can address protocol level “problems” at the miner / policy level.

Realistically, short of a soft fork there is very little that can be done technically, and even that would have serious limitations & fallout (that’s the whole point of this gross protocol design).

The obvious first reaction is ask miners to stop mining things like this. There are a few ways, but one would be to increase their -dustrelayfee

By default it’s 0.00003 BTC/kB (3 sat/vB) resulting in a dust output limit of 330 sats for P2WSH.

For this transaction with 1859 such outputs the total locked in unspendable outputs is 1859*330‎ = 613,470 sats ($736 @$120k/BTC)

Lets say you successfully lobby the vast majority (95%) of miners to 10x this config value, the sender would have to choose between paying 6.1M sats ($7k) or sending as is and waiting until the small proportion of miners (5%) using the old default. They would probably do the latter because that’s enough hashrate to find 7 blocks/day on average, and what’s the rush?

Having failed to stop this at the miner level you may now be tempted to lobby node runners to change their default and/or change the default in core v31.

Say you were successful, and core v31 contains a higher default. The sender can just preferentially peer to try and reach miners in protocol.

So you double down and you spoof preferential peering such that it’s not sufficiently reliable.

The sender now has no choice but to pay a miner OOB - if they are to do this they might as well make each output be 0 sats. This could actually be mutually financially beneficial for the sender and miner, because instead of sats being burned as fees they would flow to the miner / be saved by the sender.

Now to be fair it would take effort to establish these direct rails to miners who are exclusively financially motivated, but this is a fixed cost, and I have no doubt it would be done, and then integrated via API to centralized minting services.

Thus, the problem would likely end up being worse than the situation we have today.

Inscriptions & OP_RETURN transactions still make up 40% of bitcoin transactions by count, 10% by fee and 28% by weight.

Everyone can agree that we need more decentralized block template construction.

Core sees private tx broadcast as a threat to that (which is fair imo), which is part of why they are widening default policy rules.

Most filter proponents are vocal ocean supporters. Ocean have already materially increased the number of entities (who are actually finding blocks) doing template construction with DATUM, currently I imagine most of these individuals are using knots, and interestingly many don’t filter out all “spam”.

Knots has (iiuc) a single individual who decides what gets merged, and no doubt eventually there will be something he does / doesn’t do that will be perceived as an artificial restriction on user choice.

Ultimately, the only way miners will have sufficient choice without restriction will be if they can construct their own policy (with ease) and we have already seen an example of this (Knots Lua Pull) and a more recent BIP draft to do the same in Core (see mailing list, not received well)

The (perceived) threat with anything like this, is that “actual censorship” is as easy as mandating the inclusion of a filter file, and template construction is sufficiently centralized currently that IMO this is a reasonable concern.

Which brings us back to the point on which we have unanimous agreement: there is a pressing need to decentralize block template production.

Any action to decentralize block template production should be celebrated.

Knots Lua Implementation

https://github.com/bitcoinknots/bitcoin/pull/119/files

JS BIP Draft

https://github.com/dr-bonez/bips/blob/mempool-policy-scripts/bip-mempool-policy-scripts.md

We must stop people putting data on Bitcoin, it’s a payment network

Meanwhile: every lightning commitment transaction encodes a 48-bit commitment number across nLockTime & nSequence

Sense check

Despite a dip in activity there are still 267k “legit” transactions per day.

(Average non OP_RETURN related/Inscription over the past 90 days)

grid.orange.surf

it only takes one determined spammer to make a tool to allow the less determined to spam. -

npub1zfytz6k…wvm60l

This is the asymmetry that many filter proponents seem to miss.

Most of the kind of transactions they wish to filter out are created using dedicated software (services / tools / platforms).

Developers of such software can rapidly bypass any restriction using open source software like libre relay, which will get their transactions to miners.

We already see this, with some platforms offering the ability to select broadcast method from a drop down, including direct broadcast to some miners.

Did you use the bitcoin core wallet in the last year?

and I are arriving early for

.

Get in touch if you are around from the 14th and want to meet up!

Which filter do you think core will drop / change the default for next?

• Max Transaction Size
• Minimum Relay Fee
• Minimum Output Size

What do I do?

Research: I publish chart filled data-driven reports on technical Bitcoin topics. Read at http://mempool.space/research

Business inquiries: I lead strategy and business development at

. 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

https://www.meetup.com/bitcoin-barcelona/

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:

https://research.mempool.space/utxo-set-report/

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

event, what

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.

🎲 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/[email protected]/

The latest OP_RETURN war kicked off days prior to

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.

If bitcoin core doesn’t have the functionality that you want you can build it, and share it with the world.

If other people share your views they can also run that code.

You are making a transaction, you check mempool and set what seems like an appropriate fee, but then a new degen mint drops and your transaction gets buried. New transactions coming in push your transaction further back, and 24 hours later it's 10 blocks deep.

Fortunately you used Mempool Auto Accelerator with a 24h Time Delay trigger, and your transaction confirms in the next block.

I have 10 beta access spots, dm me.

unusual 151 sat/vB tx

https://mempool.space/tx/53a2b07caeef425198cc394df8511087b181cf0ab64ad1c42dee3231b2730804

Thanks to DATUM the

team have increased the number of entities finding blocks who constructed their own templates by 13 entities (11 if you assume Just Fo r X is one entity). You love to see it.

If you are building something on bitcoin and use

every day I want to hear from you, drop me a message.

https://zap.stream/npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx

Very interested to learn more about the Privacy improvements. "Predicate blind signing" was mentioned previously by the team in their Oct 2024 post.

https://bitkey.build/building-in-the-open/

Signing privacy

Predicate blind signing combines blind Schnorr signatures with zero-knowledge proofs that make assertions about transaction attributes. This allows the server to enforce signing policies without learning any identifying information about the transaction itself.

Vault privacy

For transactions involving funds stored in the vault, the server only signs for the funds outside the vault, adding an extra layer of protection. To preserve privacy while proving funds exist, we use a zero-knowledge proof system similar to the proof-of-solvency approach utilized by exchanges. This method allows the app to prove to the server that sufficient funds exist for a transaction without revealing any specific details about wallet balances or transaction history.

confused about the different mining options with @OCEAN ? I've made a table to compare STRATUM (V1) with DATUM.

Will add in STRATUM V2 & DEMAND in the future.

http://poolcompare.orange.surf

confused about the different mining options with

? I've made a table to compare STRATUM (V1) with DATUM.

Will add in STRATUM V2 & DEMAND in the future.

http://poolcomparison.orange.surf

"solo mining" is currently confusing as a term because it's being used to mean different things by different people (often with an agenda).

Sovereign Mining: You select the transactions Lotto Mining: You get the full block reward

Miners use picks, not hammers 🔨 -> ⛏️

https://mempool.space/mining

Babylon unstaking continue to account for a significant proportion of all bitcoin transaction fees, even hitting 50% on 11th April.

Blockspace is currently so cheap that a 4MvB inscription tx costs just 0.02 BTC

https://mempool.space/block/00000000000000000001a6878d5d21d40f53e4a331635658ee832f0194da761b

At OP_NEXT Day 1 (2h15m) Ryan Rasmussen mentioned that BitwiseInvest had to deal with dusting attacks shortly after BITB addresses were published.

I've noticed that many (22) of the wallet addresses which are no longer used have received address poisoning attack transactions.

example: https://mempool.space/address/bc1qky4xywjl59d9ge83pjdhqs7ge8d3wtwgd5edm3

Live view of

announcing the release of v3.2

The Mempool Open Source Project® v3.2.0 is here 🚀

Highlights:

• Support for v3 transactions
• Support for anchor outputs
• New UTXO bubble chart on the address page
• DATUM miner tags
• Tags to identify runestone messages and inscriptions
• Package broadcast
• Stratum job data visualizations
• Taproot multisig labels
• Transaction & PSBT preview feature
• Address poisoning detection

https://github.com/mempool/mempool/releases/tag/v3.2.0

babylon unstaking transactions are accounting for a large proportion of all transaction fees, because they use a hard coded fee rate

who could have predicted this

Even with the mempool this empty, it's possible to get your transaction stuck for 1 hour by using 1 sat/vB instead of 1.1 sat/vB