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
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.
https://blossom.primal.net/1d159627ea79b723b5bbb61a8133b2dfa02266075aac5226a5dde8ddec275136.mov
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
Done, good idea
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
Someone is consolidating large batches of UTXOs at erroneously high fee rates.
In the last 7 days they have overpaid by over 5 BTC ($580k) 🤯
They could instead just use 1 sat/vB and RBF if needed (or use Mempool Accelerator Pro and avoid any complexity😉)
196 tx match the following pattern between block heights 913374 - 914379 (past 7 days).
- Minimum Input Count: 100
- Output Count: 2
- Fee Rate: Between 101.6 and 101.7 sat/vB
Total fees: 5.43388700 BTC
1 sat/vB is clearing but someone just made a consolidation at 102 sat/vB 🫥
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)
Over the past 1000 blocks, more than 30% of transactions have been below the longstanding1 sat/vB default min tx relay fee limit.
If we plot the actual data, we see spikes around round feerates (1,2,3,4 sat/vB) and a (surprisingly ?) large spike in the sub 1 sat/vB fee rates on the right hand side.
We can animate this graph with a 1000 block sliding window for the month of August.
https://blossom.primal.net/c69fc3f5061f620e604bb0363f8ad03ecb0d2195ab964840f3cfae57b369a17e.mp4
There is a wide range in the proportion of blocks which are < 1 sat/vB, but the 144 block rolling average has been on an uptrend in recent months (shown here is data since June, block 900000)
grid.orange.surf
> it only takes one determined spammer to make a tool to allow the less determined to spam. - nostr:npub1zfytz6ktce3av2svlfpl0e79e44tnskxmvlpkcmc7q0xct3qa49swvm60l
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.
yeah, it's useful as a data source, you are not really using core as a wallet (signing, key management etc). but due to the design of core a watch only wallet file is created to track the addresses
Did you use the bitcoin core wallet in the last year?
nostr:nprofile1qyx8wumn8ghj7cnjvghxjmcpy9mhxue69uhk27rsv4h8x6tkv5khyetvv9ujuenfv96x5ctx9e3k7mgqyza3eaf9qs6l736umzej4jeru0h8h050cw8kj5tsfdres5feganjcvl2xpe and I are arriving early for nostr:nprofile1qqsd0f68dvf98gvs9am9dp0lu0f4r7xzu2k89rm9tt448axf5tu6wlgphpy4c.
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
nostr:nprofile1qy28wumn8ghj7cnvv9ehgu3wvcmh5tnc09aqzrrhwden5te0vfexytnfduqzqwm285amxdvgx6ny68yq9y4edemf3mp45tju53gaa7nt6whna6uynewnpf. 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
Block 900,000, had room to spare despite a celebratory meme inscription.
This works really well
Announcing Proof of Reserves for Twenty One
As Bitcoiners, we hear a lot about how Wall Street has arrived to #Bitcoin. With Twenty One, #Bitcoin has arrived on Wall Street.
Don't trust, verify.
We will be publishing multiple addresses over the next week proving our #Bitcoin reserves.
Our first address can be seen below, which contains 4,812.22 BTC that was acquired via proceeds of a prior transaction: https://mempool.space/address/bc1qzup4k7zn9jur7a8kz0dnaernzyf60h8ez6s9cpmp23wfw5djhvusd4p0v3
We are also announcing today that, as of May 22, the Convertible Note Investors (all but one) and the Sponsor have exercised the option in full to purchase, in the aggregate, $100 million of Option Convertible Notes. See the Form 8-K below.
Over the next week, the four more #Bitcoin addresses we plan to publish are as follows:
- 14,000 BTC that's been contributed by Tether
- 7,000 BTC that's been contributed by Bitfinex
- 10,500 BTC that's an additional contribution from Tether on behalf of SoftBank
- The BTC we intend to acquire via the proceeds from the transaction announced today
The contributions are subject to closing of the previously announced business combination with Cantor; following such closing the BTC reserves will be transferred to wallets owned by Twenty One.
https://blossom.primal.net/b85b8e11a9e8b8d864b1054adc39613c0c2e98ef9546767738658f11a5417ef0.mp4
love to see it, we should talk 🤙
Unbelievable lack of use
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: