Would you expect to know if a government was making advancements towards a CRQC?

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

Done, good idea

https://stacker.news/items/1249538

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.