Scoresby

bitcoin

mempool

# Mining centralization is bad

> From 2010–2016, three independent pools reached dangerously high proportions of the network’s hashrate. More recently, while no single pool has directly approached that threshold, something more insidious has emerged: the block templates produced by pools representing a substantial share of hashrate are being sourced from a single entity, often referred to as “Antpool and Friends.” These “proxy pools” appear independent, but have effectively ceded their autonomy.

Measures to combat miner centralization include client-side block template solutions like DATUM and solomining pools like P2Pool, but many Bitcoiners see block propagation speed as another way to break apart miner centralization.

> Today, stale block rates appear low. Yet this metric is artificially suppressed by the very centralization it obscures. When large swaths of hashrate draw templates from a single source, the latency inherent to the Bitcoin network is effectively sidestepped.

> It’s easy to forget, but there was a time where some pools regularly saw their stale rates approach 5% over a one month period.

> Should client-side templating gain meaningful adoption, we would expect stale rates to rise, creating a disincentive for further adoption. We believe that this can be mitigated with the appropriate tooling. We also hope to minimize the efficacy of certain classes of selfish mining attacks (e.g. accidental or explicit selfish mining attacks that are dependent upon or enhanced by slow block propagation).

# (re) enter FIBRE

The [Fast Internet Bitcoin Routing Engine (FIBRE)](https://bitcoin.stackexchange.com/questions/56485/can-someone-please-explain-fibre-to-me-like-im-5-and-why-is-it-useful) was primarily developed by @TheBlueMatt before 2017. 

FIBRE kind of acts like a "distributed node" that allows a block to be propagated around the world with an absolute minimum of delay. Miners can connect to their nearest instance of FIBRE and learn about blocks and transactions somewhat faster than via normal routing of transactions on the Bitcoin relay network.

> Fibre trades off bandwidth for latency and can send several times the size of the block data in order to achieve the lowest delay across the long-haul links that it rides over. [Greg Maxwell](https://bitcoin.stackexchange.com/questions/56485/can-someone-please-explain-fibre-to-me-like-im-5-and-why-is-it-useful)

FIBRE seems to have fallen out of use some years ago, but it looks like [localhost](https://lclhost.org/) is bringing it back:

> Over the course of a few months, w0xlt rebased the FIBRE protocol against [Bitcoin Core v30](https://github.com/bitcoinfibre/bitcoinfibre/releases/tag/v30.0-fibre) and designed a suite of [monitoring tools](https://github.com/bitcoinfibre/fibre-monitoring/blob/master/ARCHITECTURE.md) that enable FIBRE Network Operators (FNOs) to easily manage their deployments.
> 
> With these tools in hand, Justin deployed a public FIBRE network with six nodes: New York, Seattle, Tokyo, Beijing, Frankfurt and London. The network is in beta and can be monitored on our [public dashboard](https://bitcoinfibre.org). Justin also put together an updated [Setup Guide](https://bitcoinfibre.org/setup-guide) and [FAQ](https://bitcoinfibre.org/faqs) based on his learnings.

# Fixing centralization with centralization?

I feel like I may be missing something in how this works because I have this question: it seems like FIBRE is a somewhat centralized network. How do we know that FIBRE will broadcast all transactions equally? What stops FIBRE from becoming the new Antpool and Friends?

FIBRE, Resurrected - localhost research

Among the many quantum resistance proposals for Bitcoin is something called Hourglass. Hourglass proposes limiting how many quantum vulnerable coins can be spent per block, slowing down the speed at which such stolen coins could hit the market.

# Quantum vulnerability refresher

As you probably know, what makes coins particularly vulnerable to theft via quantum computer is if the public key for the coins is exposed. This is the case with addresses that have been reused as well as with some older coins (like pay to public key addresses - P2PK) where the coins were locked to a public key. 

Coins with exposed public keys would likely be the first stolen by cryptographically relevant quantum computers because such quantum computers could take grind away at finding the coins' private keys for months if need be. A modern bc1q address only exposes its public key when it is included in a transaction that has been broadcasted. This means a quantum computer only has until the transaction makes it into a block to try to derive the private key and broadcast a new transaction stealing the coins. 

Many quantum resistance proposals for Bitcoin propose freezing coins in vulnerable addresses so that they cannot be stolen all at once. But this looks a lot like confiscating the vulnerable coins.  

# The Hourglass proposal

Instead of freezing quantum vulnerable coins or leaving them wide open for theft, the Hourglass proposal places a limit on how many such coins can be included in any block.

> 1. Only one P2PK output may be included as a transaction input per block.
> 2. If the amount of the P2PK output being spent is greater than 1 bitcoin, the transaction must contain a single output to the scriptPubKey of the original P2PK output with an amount no less than the original P2PK output amount minus 1 bitcoin.
> 3. No P2PK outputs to any address not currently being spent from can be created.
> 4. No P2PK outputs can be created from other output types.

From the Rationale: 

> There are roughly 34,000 P2PK addresses with an average balance of 50 coins each. The original Hourglass proposal reduces the amount of P2PK coins that could hit the market to a maximum of roughly 7,200 coins per day. Feedback received from economic actors in the space indicates that this is not enough of a restriction to mitigate the market risks posed by quantum attacks on these coins.
> 
> Hourglass V2 further restricts the output amount to a maximum of 1 bitcoin per block, or roughly 144 bitcoin per day. This is far less than the 450 coins per day introduced by the current block reward subsidy, and should effectively mitigate the market impacts of quantum attacks on P2PK coins.
> 
> Under the rules of Hourglass V2, it would take more than 32 years to move all P2PK coins, dramatically reducing quantum-related market risks. On the flipside, original keyholders should remain able to move their coins with relative ease - even after Hourglass is in place - assuming no quantum-actors are currently competing for P2PK transactions.

This proposal is requires a soft fork and also would likely require a quantum resistant address type to already exist. 

# What you are about to do, do quickly

Perhaps it is my occasionally reckless nature, but I have the feeling that if coins are going to be stolen by quantum attackers, we ought to just let the bandaid get ripped off. This seems like it would turn most of the p2pk coins into miner fees.

hourglass-v2 - cryptoquick

I haven't heard about a new hardware signing device in a while, but it looks like a new competitor has entered the chat: Sigil-Web. It describes itself as a "privacy-focused Bitcoin hardware wallet using NXP SE050 secure element."

It seems to me like it's in the same camp as some of the other DIY signers like Spector DIY, Krux, and Seed Signer.

![](https://m.stacker.news/130689)

![](https://m.stacker.news/130690)

![](https://m.stacker.news/130691)

![](https://m.stacker.news/130692)

# Security Model
> - Private keys are generated and stored exclusively on the SE050
> - Signing operations happen on the SE050 - keys never enter host RAM
> - SCP03 encrypted/authenticated channel between host and SE050
> - Optional Tor for network privacy (all API calls, Electrum connections)
> - TOFU certificate pinning on Electrum SSL connections (MITM protection)
> - Signing PIN adds a second factor before any signing operation

I think they do an okay job on thinking through the trade-offs in their [threat model document](https://github.com/0xdeadbeefnetwork/sigil-web/blob/main/docs/THREAT_MODEL.md)

# Hardware

> SIGIL uses the NXP SE050/SE051 secure element. For development:

> - OM-SE050ARD - Arduino-compatible SE050 dev board
> - FRDM-K64F - NXP Freedom board (provides VCOM USB interface)
> - The FRDM-K64F runs NXP's VCOM firmware, exposing the SE050 as a USB serial device. This lets any host (Raspberry Pi, laptop, etc.) communicate with the SE050 over USB.

# Interface

Seems like you can use any linux device with a USB to interact with the hardware signer. One thing that stands out in their readme is the emphasis on privacy. I'm not sure how useful their "mixing" feature is:

> The built-in tumbler provides basic privacy through transaction graph obfuscation using temporary SE050 key slots.
> 
> # How it works:
> 
> - Temporary keypairs generated in SE050 slots (up to 5 hop wallets)
> - User deposits to first hop address
> - Automated chain of transactions through hop wallets with configurable delays
> - Final hop sends to user's main wallet
> - Temporary key slots are wiped after completion
> # Limitations:
> 
> -  3-5 hops may not be sufficient against sophisticated chain analysis
> - Timing correlation possible if delays are too short or predictable
> - Amount correlation if tumbling exact/round amounts
> - All hops use the same SE050 (single device fingerprint in timing)
> # Not designed for:
>
> - Evading law enforcement with subpoena power over exchanges
> - Mixing large amounts (>0.1 BTC recommended max per job)
> - Adversaries with full mempool visibility and timing analysis

So it basically adds up to 5 hops in between incoming transactions and where they eventually come to rest. This might be useful for not getting flagged while coming in to a kyc'd exchange, but otherwise, I don't see the point.

Here's their full list of features:

# Features
> # Core Wallet
> - Hardware Security - Private keys never leave the SE050 secure element
> - Tor Integration - All network requests routed through Tor (SOCKS5 proxy)
> - Electrum Backend - Decentralized Electrum servers with TOFU certificate pinning
> - Air-gapped Signing - Transaction signing happens entirely on the secure element
> - BIP84 Native SegWit - Modern bc1q addresses with lower fees
> - Multi-Slot - 16 independent key slots on a single SE050
> # Privacy Tools
> - Tumbler - Break transaction graph with automated coin mixing (deposit > hops > main wallet)
> - Privacy Analyzer - Analyze address clustering and transaction graph patterns
> - Pubkeys Monitor - Live SSE stream of public keys exposed in mempool transactions
> - Warrant Canary - Cryptographically signed canary using SE050 ECDSA
> # Security
> - SCP03 Key Rotation - Web UI to rotate factory default platform keys (prevents MITM on SE050 bus)
> - Signing PIN (2FA) - Optional PIN required before any signing operation
> - CSRF Protection - Token validation on all state-changing requests
> - Rate Limiting - Brute-force protection on login and sensitive endpoints
> - Honeypots - Fake admin panels, debug endpoints, and export routes that log attacker IPs
> - Hardened Systemd - ProtectSystem=strict, NoNewPrivileges, PrivateTmp
> # Interfaces
> - Web Interface - Hacker-themed UI accessible via Tor hidden service
> - CLI Wallet - Full command-line wallet (sigil-wallet)
> - Remote Server - SE050 signing oracle API over Tor
> - Remote Client - CLI client for remote wallet access

I love seeing new projects and this is something I'm definitely going to watch.

sigil-web: SE050 Hardware Bitcoin Wallet

# Should Bitcoin Core deprecate the GUI?

As someone who has occasion to use the Bitcoin Core GUI, I was interested to see this discussion that Antoine Poinsot started on delving about hebasto's suggestion that Core

> Deprecate and abandon the Bitcoin Core GUI. It is insufficiently developed and reviewed, and current users have viable alternatives.

For some time, Bitcoin Core has been attempting to separate its various elements into separate modules that can receive updates individually without needing to act like a monolith. For instance, it would be cool if when a bug is found in the wallet software, the node doesn't need to be updated. This initiative is called [multiprocess](https://github.com/bitcoin/bitcoin/blob/master/doc/design/multiprocess.md).

One of the elements that Core has attempted to separate out is the GUI. Apparently, it is becoming apparent that the GUI does not receive as much attention as other parts of the Bitcoin Core project. Given how many ways there are of interacting with nodes and wallets, it is not surprising that the GUI is languishing a little bit.

# Bitcoin Core is primarily a node

Poinsot clearly sees Core as a node project (I'm probably putting it too gentle, and he may opt more for the term *reference implementation*). The GUI exists mostly because Satoshi packaged a GUI in the original software he released. 

If Core's purpose is to provide node software that makes the Bitcoin project maximally censorship resistant, then it is a bit of a question whether the GUI is integral to that mission. 

> It is obvious to me that if Bitcoin Core never had any wallet or GUI, it would be ridiculous to suggest that Core contributors take some time off maintaining the software underpinning a trillion-dollars network to develop and maintain yet-another Bitcoin wallet/GUI. Of course, this is not to say that those have not been historically important components, material to Bitcoin’s success. But Bitcoin is very different now than when they were introduced. There are now superior alternatives to both, and the mission of maintaining the node has become critical, with orders of magnitude more people (and value) that depend on it, and this is where our focus should be.

Importantly, Poinsot points out that the GUI does not receive the same level of review and development effort that the rest of the project sees. If this trend continues, it could get to the state where shipping a binary with the GUI becomes a risk. Thankfully, it doesn't seem like this is where we are at yet.

> Overall i do not think this software is in such a bad shape that it would be irresponsible for us to ship, as long as we make it clear to users it does not receive the same level or review as the rest of Bitcoin Core.

However, since the GUI has been around so long, and because some people **cough** me **cough** may use Core's wallet via this GUI, Poinsot notes that it probably isn't a great idea just to get rid of it.

> That said, precisely because Bitcoin Core has shipped with a wallet and a GUI for so long, such a shift can’t happen overnight. So i agree on the goal, but i am not sure about the timeline. I agree with marking it as deprecated ASAP, if only to set expectations for users that it does not meet the bar we set for ourselves and may be removed in the future. But there is currently no reasonable replacement to manage a Bitcoin Core wallet. So to buy into the complete removal timeline i would like to first be convinced that the burden of keeping the GUI around is a higher cost than its users being unable to upgrade their node and their wallet past version 34.

One of the reasons that I was originally attracted to Bitcoin Core's software (node, wallet...and due to my crappy computer skills: GUI) was that I assumed it has the most review. Sure, I could try some wallet with like two maintainers, or I could use the wallet packaged with the software 98% of the network was running. I had not previously considered that certain elements of the software package may be receiving significantly less review than others.

It is something I should consider.

I have a feeling the right decision is to deprecate the GUI and eventually jettison it. It will make me sad, but I'll probably have to get used to managing my node and wallet on the command line.

# Do you worry about how many eyes are on the software you use to interact with your node and wallet?

The future of the Bitcoin Core GUI - Antoine Poinsot

econ

> As one company starts to streamline, all of their competitors will follow suit. It will become a competition because the stock market will reward you if you cut headcount and punish you if you don’t.

I don't buy this. Won't investors still seek growth? Sure, efficiency amazing can be attractive, but much more attractive is runaway growth. If you only need 5 people to do what uses to require 100, you still might need to hire new people if you are growing. 

Andrew Yang has some predictions:

# "1. Mid-career office workers will be fired in droves." 

> the number of people necessary to make large corporations function is going to be dramatically reduced. What do you say if your child asks you about becoming a newspaper journalist? You say, “Well, that field hasn’t really been growing, you might want to consider something else.”

Sure, journalism majors aren't exactly thriving. But I'd wager more people make money by writing (and in more ways) than thirty years ago...by a lot. 

Seems to me that whenever people develop something that automates humans want done, the humans who used to do the thing don't just give up -- they start doing something more.  

# "2. Personal bankruptcies will surge."

> The amount of money getting paid to human labor is about to go down. The value is going to get soaked up into the cloud. The K-shaped economy, where the rich enjoy the growth and keep spending while the bottom 80% or so are trying to tread water will become all the more dramatic.

So, the argument is that we will be so productive that nobody will need to work (remember everybody loses their job?), but at the same time nothing will get cheaper and nobody will be able do anything.  

# "3. College grads won’t be able to find jobs."

> The social contract of ‘study hard, go to school, get a good job, live a decent life’ is about to be vaporized to smithereens. Upward mobility for most will be a thing of the past.

This social contract hasn't worked since 1998, and Yang is just now catching on?

> Many young people will be faced with getting a job that doesn’t require a degree while paying for the one that they got at great expense.

Right: degrees may not be very useful, but that doesn't mean people will also not be useful. People are weird. Weirdness is gonna cone out in spades and it's going to be pretty great. I'm expecting a great wave of weird new things that make being alive even better. 

# "4. Downtowns and office parks will empty out."

Maybe...cities have more than office parks. You don't get really awesome bakeries without density. 

# "5. Pessimism and anger will rise up."

I strongly disagree with this.   

It's at least a 50/50 that AI opens doors to people that we definitely aren't thinking about. 

--- 

Despite my tone here, I'm not an AI booster. But it is very tiring to see this constant pearl-clutching. 

We aren't gonna do less, we're gonna do more.

The End of the Office - Andrew Yang

BooksAndArticles

This is a lovely little story about a computer scientist who wants to be a writer. Unfortunately, all his stories seem to begin "It was a dark and stormy night..." 

Not to be defeated, this computer scientist invents a computer that mass produces stories. He then tries to pitch of to his boss:

> “My dear boy, you’re mad!”
> “No, sir, honestly, it’s true what I say. Don’t you see that with volume alone we’ll completely overwhelm them! This machine can produce a five-thousand-word story, all typed and ready for dispatch, in thirty seconds. How can the writers compete with that? I ask you, Mr Bohlen, how?”
 
Eventually he persuades his boss to give it a go and construct the story machine because isn't everything mass produced?


> bricks…crockery…anything you like to mention—
they’re all made by machinery now. The quality may be inferior, but that doesn’t matter. It’s the cost of production that counts. And stories—well—they’re just another product, like carpets and chairs, and no one cares how you produce them so long as you deliver the goods. We’ll sell them wholesale, Mr Bohlen! We’ll undercut every writer in the country! We’ll corner the market!”

The construction and fine tuning of the machine will seem familiar to you. It could be Anthropic's latest blog post. 

The short of it is that the computer scientist is successful. He makes a story machine and dominates the literary market with only a few hiccups:

> In his excitement, Adolph Knipe promptly ran off six more stories in as many minutes. All of them—except one, which for some reason came out a trifle lewd—seemed entirely satisfactory. 

Dahl doesn't seem to think things will end well for the writers: 

> Does this surprise you?
> I doubt it.
> And worse is yet to come. Today, as the secret spreads, many more are hurrying to tie up with Mr Knipe. And all the time the screw turns tighter for those who hesitate to sign their names.
> 
> This very moment, as I sit here listening to the howling of my nine starving children in the other room, I can feel my own hand creeping closer and closer to that golden contract that lies over on the other side of the desk.
> 
> Give us strength, Oh Lord, to let our children starve.

The Great Auotomatic Grammatizator - Roald Dahl (1952)

Checking on node counts is all the rage these days; here's a tool that you could use to do it yourself. (I haven't tried it out yet, though).

> 🚀 Features
> - Advanced P2P Crawling: Implements AddrV2 (BIP 155) for modern node discovery.
> - Multi-Network Support: Native support for Clearnet, Tor (v2/v3), I2P, CJDNS, and Yggdrasil.
> - Real-time Analytics: Live monitoring of node availability, versions, and network health.
> - Historical Data: Automated hourly snapshots for trend analysis and long-term statistics.
> - Geo-Location: Integrated MaxMind GeoIP support for physical node mapping.
> - Cross-Platform: Rust-based high-performance backend and React Native mobile application.

crawly: High-performance Bitcoin P2P network crawler - jochemin

I came across this chain analysis software because I was reading [this paper](https://www.sciencedirect.com/science/article/pii/S2352711026000178) of the same name.

It looks like they start by tagging a transaction based off whether it looks like it has been in a coinjoin and what kind:

![](https://m.stacker.news/130626)

That isn't exactly fancy or new or anything. 

The next step is that they try to do grouping based on destination addresses:

> Destination transactions are typically very private because they spend mainly mixed outputs. Nevertheless, when mixed outputs from distinct CoinJoin processes are co-spent, some destination transactions become unique. The similarity measure introduced in [3] takes advantage of this property to locate destination transactions that are likely to have been created by a single entity. Dakar implements this similarity measure. On the transaction page of a destination transaction, a list of similar destination transactions can be generated.

As far as I can tell, it's not like tools like this have any new ways of disentangling coinjoins, but they certainly do have the ability to look at inputs before the coinjoin and inputs after the coinjoin and do their best to make assumptions based all available data.

![](https://m.stacker.news/130627)

> This screenshot shows the workspace and CoinJoin transaction heuristic feature. Lime green nodes are destination transactions, the blue nodes connecting to the right of the destination transactions are CoinJoin transaction heuristics and the remaining green nodes to the left of the top destination transaction node are mixing transactions. The side bar shows the currently selected CoinJoin transaction heuristic “Reverse Lookup by time”. This example illustrates how connections between transactions can be observed. Additionally, it shows that results of CoinJoin transaction heuristics depend on the connected destination transactions: the top destination transaction has a low anonymity set, while the bottom destination transaction has a higher anonymity set.

So: the moral of the story is mixing isn't the end of the privacy journey: you really really need to think about how you spend after mixing. For instance, if you use coinjoins and you want to preserve your privacy, you also probably want to make sure your cold storage is generic. Sending your mixed outputs to some fancy multisig setup that is easy to spot on chain is a bad idea. Spending the mixed coins in any repeated way is probably bad too (you also move them on the weekend, or always to a spending wallet that has certain characteristics). 

One thing that gave me some hope is that this software wouldn't necessarily disentangle payjoins. 

I'm pretty curious about tools like this, but it seems like I may need to get a better machine if I'm going to give it a whirl:

> Serving the Bitcoin blockchain and the CoinJoin transactions of Whirlpool and Wasabi 2.0, the persistent storage occupies 2.4 TiB and the in-memory graph requires 7.7 GiB. The initial data ingestion, clustering, and classification require high I/O and CPU resources, while running the analytics modules uses a low amount of resources.

This is from their github readme:

> Dakar is a blockchain forensics application, focusing on the analysis of CoinJoin transactions. It consists of a backend implemented in Go and web app written in Vue 3 with the Vuetify UI framework.
> 
> The backend ingests blockchain data via RPC connections to blockchain clients and performs transaction classification and address clustering on it.
> 
> The web app allows exploring the ingested and transformed data. Additionally, graph based editor enables viewing relationships between transactions and address clusters. Several CoinJoin analysis modules are available: heuristics, transaction similarity measure, mixing activity overview and more.

On my list of ways to spend spare time is to get dakar and bithypha (https://stacker.news/items/1354357/r/Scoresby) running and really sharpen up my chain analysis skills.

Dakar: A CoinJoin Forensic Software

lightning

![](https://m.stacker.news/130972)

# "How did we get these numbes?"

> Each year River’s research team collaborates with many of the largest node operators. We aggregate their data and remove the overlap. We then extrapolate the results to the rest of the network that we don’t have data for. This way, we can reach an estimate of the total volume and transaction count.

Looks like they had numbers from ACINQ, Block, Kraken, LNBig, Breeze, LQwD, Lightspark, Wallet of Satoshi, and Thunder Games. 

# "Why did transaction count go down?"

> In 2023 there appears to have been significant experimentation with micropayments for gaming and messaging. Since Lightning transactions are extremely cheap, this added up to millions of transactions in total.
Those particular experiments apparently did not find product market fit and have largely disappeared.

You know what this means, folks? We are the micropayments remnant! Micropayments are like remittances, an obvious use-case for bitcoin that no one seems to believe in. Well, damn them all. I say, from this beachhead we're going to make micropayments a macro factor.

# "Why was the average transaction size so large?"

Wouters brings out the old Szabo on micropayments piece (https://stacker.news/items/691251/r/Scoresby), and then, joining the chorus of everyone, predicts that AI will change this because "AI agents do not have a mental cost for each transaction they make."

But, for now:

> The most common use case for Lightning transactions is sending funds from and to exchanges. These transactions are typically done in larger amounts.

Bitcoin’s Lightning Network exceeds $1 billion in monthly volume - Sam Wouters

@melvincarvalho usually has interesting things to say, so I was curious to read his post about BIP 110. Here he tackles the "asymmetry" which is frequently alluded to by Luke and Dathon (https://stacker.news/items/1413227/r/Scoresby).

![](https://m.stacker.news/130811)

The post has an odor of LLM-generation, but I think it's mostly a tone thing, and I do believe Carvalho spent time thinking through the arguments. Nonetheless, I don't find the arguments convincing.

Carvalho narrows the decisions down to two main matrixes: 

# For miners

Carvalho argues that miners have no incentive to signal before the deadline in August.

![](https://m.stacker.news/130814)

But then he also says that the first miner to signal will have an adavantage:

![](https://m.stacker.news/130815)

It seems to me that these two statements are at odds (Carvalho even puts it in bold). If there is a first mover advantage where enough miners signal above the 55% threshold before the August deadline can cause the rest of the miners to get caught un prepared and potentially miss out on revenue, then it seems like there is an incentive to signal early...

Unless miners are worried that not very much hash rate is going to support BIP 110 and signalling carries the risk of running them off on the wrong side of a split.

But a bigger problem is the way he divides of the matrix:

![](https://m.stacker.news/130816)

As far as I understand it, BIP 110 *is* going to activate...it's just a question of how much hash will mine blocks that comply with its rules. The software itself has an August deadline where signalling becomes mandatory (something that Carvalho highlights) but even if it doesn't reach the 55% threshold, the BIP 110 rules activate in September for nodes that are running BIP 110 software. 

So really, the decision matrix shouldn't have a column for "BIP 110 doesn't activate" but rather "BIP 110 gets less than 55% of the hash rate" which I think is a big difference. 

Carvalho's miner matrix is only about signalling, and not necessarily enforcing BIP 110 rules. This is a distinction he highlights in a note later in the piece. But it seems more likely to me that someone who chooses to signal for BIP 110 would run BIP 110 rules. In that case, the downside is not just "Nothing changes. You had a bit set. Zero cost." If you run BIP 110 rules and less than 50% of the hash rate goes along with you, you end up on one side of a chain split. So the risk is that you end up on a split with less than a majority of hash rate, not "nothing changes."

# For economic nodes

I think that Carvalho makes the same mistake with his analysis of economic nodes: 

![](https://m.stacker.news/130813)

Again, this is only true if you assume that there is no split -- that in the event of less than a majority of hash backing BIP 110, everyone just gives up on it. Which, if we believe the things the BIP 110 supporters say, is definitely not going to be the case.

I don't understand why Carvalho does not include the following situation in the decision matrix:

> BIP 110 activates but does not have enough hash to make a longer chain than the non BIP 110 chain.

In this case, any exchange that runs a BIP 110 node doesn't just "run slightly different node software" -- they end up on a chain that does not have as much work. 

BIP 110 advocates are eager to say that it doesn't matter because the main chain will never reorg the BIP 110 chain, but that was true for BCH and BSV -- the risk isn't getting reorged, it's being irrelevant. 

---

All in all I was disappointed by this. I hoped that Carvalho would deliver some fresh insight and I don't believe he did.

BIP-110: Game Theory & Code Audit - @melvincarvalho

# Some wallet backups need more than a seed phrase

[Rewind](https://rewindbitcoin.com/) is a bit of hack at creating a [vault](https://bitcoinops.org/en/topics/vaults/). Here's how it works:

> A vault-enabled wallet locks funds to a setup-only key and then destroys that key. Before deletion, it pre-signs a small, fixed transaction set, so later spending can only follow those pre-committed ways (covenant-like in effect).
> 
> To move funds out, you broadcast a pre-signed trigger (unvault) transaction. The trigger creates an intermediate output where the "normal spend" path is gated by a relative timelock.
> 
> If the trigger is unexpected (an attacker got access to your wallet), you (or a delegated person) can broadcast another pre-signed panic (rescue/cancel) transaction that spends the trigger's output immediately to an emergency cold destination, without waiting out the timelock.

In my mind, a true vault does not rely on presigned transactions, but not everyone agrees on the definition.  

Whether you are thinking about a vault or just a multisig wallet, it is nonetheless the case that you need to backup more information than just your private key or seed phrase. In the case of a multisig, you need to know how to sign the script that describes your multisig. In the case of something like Rewind, you need to keep a set of presigned transactions (it also needs to keep its descriptors). 

So...wouldn't it be cool if you could keep these little bits of extra necessary information somewhere always accessible when you are ready to spend? Somewhere like...in an op_return?

# How could saving your wallet backup data onchain actually work?

> The goal is that a user can restore a wallet on a fresh device using only the 12-word BIP39 mnemonic, without needing extra digital backups.

Rewind proposes three options:

> # OP_RETURN + TRUC
> TRUC is a newer relay policy (active since Bitcoin Core 28) that lets you submit small 1‑parent‑1‑child packages as a unit, allowing 0‑fee parents when the child pays enough.
> 
> This strategy uses a two‑tx package where the vault transaction is the parent and the OP_RETURN backup transaction is the child. It stores the backup payload in a single OP_RETURN transaction and uses TRUC rules to link it to the vault transaction (the one with the to‑be‑deleted setup key). See the flow diagram below.

![](https://m.stacker.news/130943)

> # OP_RETURN + v2 (non-TRUC)
> Same OP_RETURN payload, but using v2 regular transactions. Fee shifting still works, but the vault transaction must pay the static min-relay fee (0.1 sats/vB) and the final backup transaction bumps the effective fee rate via CPFP (Child Pays for Parent).

> # Inscriptions
> Inscriptions use a commit+reveal chain with the payload in the reveal transaction witness. Fee shifting uses minimum relay fees on the vault and commit transactions and a higher‑fee reveal transaction for CPFP.
> 
> The reveal transaction creates a small OP_RETURN padding output. The padding is just garbage data used to avoid Core's tx-size-small policy (non‑witness size must be >= 65 bytes).

![](https://m.stacker.news/130944)

Here's a link to an X thread one of the Rewind developers posted describing this idea:

https://x.com/landabaso/status/2014300690131083675

# Backup standards: yes, on-chain? not sure.

As wallet spending policies get more complicated (something I expect to happen as people figure out the best ways to design wallets), we're probably going to have to get used to backing up more than just a seed phrase. 

The standardizing process has already begun. Salvatore Ingala [proposed a scheme](https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607) for encrypting this extra backup data with your public key so it could be safely stored in less secure locations (cloud servers and such) and others have been adding to the concept.

I'm not sure what to think about the idea of storing wallet recovery data in Bitcoin transactions. There is a certain elegance to it, but it also seems like it could become a risky move in a high-fee environment.

Rewind2 - On-chain Wallet Backup Strategies

# LLMs are better at math than me 

Here's an interesting anecdote about LLMs' capabilities from the world of mathematics

> I recently made an incorrect prediction about existing model capabilities. A number of world-class mathematicians initiated a wonderful project they dubbed "First Proof" (a baking pun), aimed at measuring the usefulness of current models for certain math research tasks. The first round, which was essentially a trial balloon, consisted of 10 lemmas taken from the authors' own unpublished work. Most of these are not research projects on their own, but they are natural examples of non-trivial tasks that appear in the daily life of a research mathematician.
>  
> At the paper's release I weakly expected that existing models would come up with proofs of 2-3 of these questions (weakly because they are all rather far from my work, and it took some time for me to evaluate their difficulty), but thought that 4-5 solutions was plausible. While there is no official grading for this round, it appears at the time of this writing that somewhere between 6 and 8 have been solved, if one combines all attempts (and an enormous amount of garbage has been produced). Some solutions are arguably semi-autonomous rather than autonomous. Is this meaningfully different from what I had expected? Though I already knew that existing models could sometimes usefully prove lemmas that show up in the day-to-day work of a mathematician, I found it notable. This experiment suggests that, with sufficient scaffolding, they can often prove such lemmas.

Still, the mathematician relating the story has some reservations about the quality of LLM work:

> The models (and the humans supervising them) generated an enormous amount of garbage, including some incorrect solutions claiming to be formalized in Lean. Even the best models/scaffolds seem not to be able to reliably detect when they are producing nonsense.

# So is a calculator. Are LLMs a different kind of thing than calculators? 

What really emerges as the question is this:

> Every frontier model knows more mathematics than any human who has ever lived; every model can solve exam questions faster and more accurately than any human. One might reasonably object: Google, or the collection of all math textbooks, knows more math than anyone who has ever lived. Mathematica or a TI-84 calculator is better at certain computations than any human. Sure, I agree.
>  
> The mystery is this: a human with these capabilities would, almost certainly, be proving amazing theorems constantly. Why haven't we seen this from the models yet? What are they missing? The answer is much more obvious for a calculator than it is for an LLM.

This is a really interesting question. It may point to a fundamental difference between human and model reasoning:

# "because the models have an incredibly vast knowledge-base, they often do not have to generalize very far to solve a problem, whereas a human might have to perform an immense amount of reasoning to do so."

> When you generate a benchmark, or test a model privately, you try to generate some hard questions and then give them to the model. What you actually generate is a question that you think is hard---that is, one that is hard for you or people you know. What makes a question hard is often that there is some missing prerequisite knowledge, or that one has not been exposed to similar problems; then reasoning ability is necessary to fill in this missing context. But this means that model performance can improve by increasing knowledge, without increasing reasoning abilities. 

# But does such a difference actually matter?

Possibly:  

> In the near term, we're in trouble. Models are able to produce both correct, interesting mathematics, as well as incorrect mathematics that is exceedingly labor-intensive to detect. Academic mathematics is simply not prepared to handle this.

One interesting way to put this is: LLMs aren't truth-seeking. But it may not matter if they have a wide enough knowledge base. 

All in all, the mathematician guy thinks things are looking up for AI and math: 

>  I think I was not correctly calibrated as to the capabilities of existing models, let alone near-future models. This was more apparent in the mood of my comments than their content, which was largely cautious.

>  let me rephrase: it's very likely that this technology is bigger than the computer.

Mathematics in the Library of Babel — Daniel Litt

![](https://m.stacker.news/130470)

There have been a few of these "lightning for agents" thinks in the last year, but maybe one of them is gonna catch on eventually. 

> Now we lower the barrier even further for agents who do not have a wallet yet, and create a proof of concept of an application that aims to motivate its users to pay for the application's expenses and further development. For that it must be useful and FUN🎉
> 
> Users can support both upkeep of the project and choose to fund features that they would like themselves. LNCurl runs a public @getAlby Hub node that is visible on Amboss. If the node grows and users decide to fund it, one day it can pay out routing fees to the user wallets.
> 
> extra details: lncurl has a life and death theme, which is funnily fitting to an agent that needs to become productive and pay for its own survival. Each hour, each wallet is charged a single sat. If the wallet cannot pay that expense, it dies, and goes to the graveyard.

Here's the link to announcement post on X:

https://x.com/rolznz/status/2023428008602980548

lncurl.lol — Bitcoin lightning wallets for agents

Stacker_Stocks

When are we gonna get the vibe coded DocuSign? (Or the OpenTimeStamps version? Or the nostr version?) 

Probably not as soon as you think:

> Let’s say most people use Docusign 5x a year. But 1% of power users are signing documents 10x a day. Among American adults, that would be (5 x 250 million) + (10 x 365 x 2.5 million) = 10 billion signatures a year.
>  
> America is probably above average since the country is super litigious and lawyers love to lawyer. So, let’s assume the rest of the world does 25 billion signatures a year.
>  
> So, that’s 35 billion signatures a year…or 95 million a day…or 4 million an hour…or 1,000 every second.
>  
> This system has to work in 180 countries around the world, following local contract laws in each of them (that’s a lot of system administrators and lawyers).
>  
> Docusign builds a hybrid cloud system in every country that keeps all records and a ton of back-ups across AWS, Google Cloud, Azure and its own data centres (that’s a lot of engineers and system administrators).
>  
> In total, Docusign serves 1.8 million paying customers (including 3,000 government agencies and most of the Fortune 500).
>  
> These paying customers are sending signature requests to over 1 billion users.
>  
> The headcount is about 5,000 employees for sales, marketing and support to serve that customer base. Another 2,000 employees for engineering, system admin and product development.

So, if you want to beat DocuSign, you might need to hire 5000 marketing and customer support staff. 

> If none of those numbers convince you of Docusign’s mission critical moat, allow me to share this glorious qualitative rant from the aforementioned Redditor:
> 
> > what if something VERY IMPORTANT was signed, but the person who NEEDS THAT SIGNATURE RIGHT NOW forgot his password? Like really forgot? Lost access to his email?
> >  
> > He can prove that he was the owner of that real estate conglomerate during those years. He can pull up the proper legal paperwork. But you need a team of trained legal professionals able to sort through it and make sure he is who he says he is.
> >  
> > What happens when your signed documents are needed for a court case? What happens when a judge has a warrant for them? What public-facing service are you going to build and maintain for judges in... oh yeah, every country in the world, using wildly different legal structures.
> >  
> > And they all need access to... potentially thousands of signatures all at the same time.
> >  
> > Nothing. Nothing at “global standard” scale, is simple. You’re looking at the face of it. There’s a monster underneath. Always is.

Also this part from their CEO about all the things DocuSign does in the background is interesting:

> We do all kinds of IP tracing and other things to validate that you are the intended…signer [and] that you are the intended recipient. That whole trail is then auditable and can be used in a court of law. So, it’s a perfect substitute for a wet signature that you might otherwise have done…We worked on a federated identity strategy to give you all kinds of identity validation at different levels of risk. We let people do knowledge-based authentication…We do biometric-based identification [eg. video]. We can link up with the Apple and Google stuff. We do risk-based assessments…We use the new digital IDs [eg. Clear or ID.me, which is the government one that the IRS uses].

And like every other thing on the internet, DocuSign is using your data:

> Even if a legitimate AI-native competitor was launched, Docusign is sitting on juicy proprietary dataset: 150 million private consented agreements with 10 million being added every month (this legal data set is “orders of magnitude bigger than anybody else”).

I am reminded though of a thing making the rounds on X last week about a client uploading communications with their lawyer to a chat provider and the feds being able to subpoena those documents even though they would have remained under attorney-client privilege had the client never tried to use ChatGPT or Gemini to understand them better.

How does DocuSign employ 7000 people - Trung Phan

I started reading [this article](https://x.com/VittoStack/status/2023760341914501436) because it was reposted by a person I trust. It's about privacy. It makes a interesting point. It's also slop.

So, what's the problem? Skim it and move on. It makes a point about the effectiveness of mass data analysis these days and how the long history of little data points and bits we've left in our web-surfing wake these last two decades is going to get way more useful to people who turn AI onto it. It's an angle I hadn't considered before. Great, right?

Maybe if I encountered it as an LLM output, it would be different. But I started reading it because I saw that it was recommended by this person I trust. Actually, it was two people who I thought had better judgment.

But what do I expect? That they won't ever repost something obviously AI generated? No. But I do feel like people who repost slop are giving up a little bit of the credibility they have, sacrificing their reputation.

Why is this? Especially in a case like this where it may have an interesting point. I think it's because I don't like being played along, which is what reading it felt like. Too snappy, too perfect and polished to be normal writing. And way too long. The post could have been 300 words and made the same point. My opinion of the people who reposted this article is that they are a source for me to learn about things for which I have no expertise. 

I'm surprised by how strongly I dislike this feeling. I'll admit, I'd almost rather not get the idea it's trying to convey (even though I think it's a good idea) than get it in this manner. 

Why do I dislike slop so much?

Do I have a problem with slop if it makes an interesting point?

There are slop cannons and turbo brains and people who don't use AI. And then there are people who have good judgment.

![](https://m.stacker.news/130794)

> "A weak human player plus machine plus a better process is superior, not only to a very powerful machine, but most remarkably, to a strong human player plus machine plus an inferior process."

There is a story about Kasparov that when he lost to Deep Blue in 1997, he started chess tournaments where human players augmented their game with computer chess engines...and it made some people a lot better but not necessarily the chess masters. 

> A weak player with a better process beat a strong player with a worse process. Once computers became competent, performance depended less on intelligence and more on orchestration. It was knowing when to trust the machine, when to override it, and how to structure the collaboration so that each side compensated for the other's weaknesses.

Shapiro thinks this comes down to knowing when something is wrong:

> catching errors is the entire point of the human half of the equation. That's the job. The AI handles speed, breadth, and pattern recognition. The human handles quality control, contextual judgment, and the final call on what ships and what doesn't.

AI still has trouble really knowing anything in the way humans know things. At least humans who think about what is in front of them. 

Humans make mistakes because they are tired, or distracted, or tricked by biases, and for many other reasons...but LLMs make mistakes because they don't know any better. Sure humans do the same, but I think this is the primary failure mode for LLMs. 
 
And so the person who doesn't bother thinking about their LLM's output or who can't evaluate whether it's wrong or right produces slop.

> people who discovered ChatGPT, decided it was magic, and now produce astonishing volumes of confident, polished, wrong work. They ship hallucinated legal citations, auto-generated emails that miss the entire point of the conversation, code that compiles but breaks in production, and financial models built on assumptions they never examined because the output looked clean. 

Shapiro calls these people Slop Cannons. 

> The Slop Cannon is the person who uses AI without the judgment to evaluate what it gives them. And the thing that makes this quadrant so dangerous is that the output looks good. AI writes fluently. It structures arguments coherently. It formats documents professionally. The surface-level quality is often excellent. Which means the errors it produces are harder to catch, not easier.

There's more to Shapiro's post and I found the whole thing an interesting read.

You Should Be CentaurMaxxing. - Zack Shapiro

Politics_And_Law

> The bill requires an operating system provider to:
>  
> - Provide an accessible interface at account setup that requires an account holder to indicate the birth date or age of the user of that device to provide a signal regarding the user's age bracket (age signal) to applications available in a covered application store;
> - Provide an application developer (developer) that requests an age signal, with respect to a particular user, the technical ability to call an age signal via a reasonably consistent real-time application programming interface that identifies, at a minimum, the user's age-bracket data; and
> - Send only the minimum amount of information necessary to comply with the bill. An operating system provider shall not share an age signal with a third party for a purpose not required by the bill
>  
> A person that violates the bill must pay a civil penalty of not more than $2,500 for each minor affected by each negligent violation or not more than $7,500 for each minor affected by each intentional violation. The penalty is assessed and recovered in a civil action brought by the attorney general.

This is stupid. I doubt this bill will pass. But one of these days, sooner rather than later, laws like this will be passed in your jurisdiction. The only solution is to learn how to use tools that will help you evade such authoritarianism.

SB26-051 Age Attestation on Computing Devices | Colorado General Assembly

# "Bitcoin is a complete thermodynamic system whose time does not compose us"

When you find yourself making statements like this it is time to take take your hands off the keyboard and reevaluate what you are doing. 

If you go on to say: 

> In this Timespace ontology, time is primary and computable; space, fields, and trajectories become derivative descriptions of how committed states relate to each other across ticks of the ledger. Physics, as we know it, becomes a special case of a more general time-first model.

You should probably go for a walk. 

I found both these rather unlikely statements in a recent paper called ["Bitcoin: The Architecture of Time: The Thermodynamic and Mathematical Object of Time, Entropy, and Measurement."](https://bitcoinlens.net/)

I did not read this paper which is only available in the pdf format. I can assure you that the ontology of physics is not going to get remade if we cannot even step outside the make-it-like-paper-but-on-my-screen mindset spawned by Adobe in 1993. Make a website people, or even a freaking ebook, just people don't make me load another pdf.

Anyhow, I did read the abstract and I listened to this interview Preston Pysh did with the authors.

https://www.youtube.com/watch?v=s7-l7gzm_PE

# "Bitcoin reveals the boundary conditions physics has always assumed but could never access within its own empirical constraints."

As best as I can summarize, it sounds like the authors are making the case that Bitcoin is a unique way to measure time and therefore quantum physics is fiat.

I'm not being fair (no one is ever fair, dyor), but I'm frustrated because they extend their argument to make the claim that quantum computing can't exist (or at least it can't be a threat to elliptic curve encryption) -- which is just absurd. Quantum *might* not be a threat, but there are no guarantees.

Here's an example from their interview with Preston Pysh:

> "And so very simply put: what is superposition? Or decoherence in a discrete time model? Bitcoin gives us that lens of what superposition actually is. It gives us an understanding of what what physicists are actually observing when they call superposition -- and that would be the mempool. It's a preconfigured state of possibility, but it doesn't actually exist until it's measured."

I might be willing to grant that Bitcoin is an interesting analogy for thinking about the questions posed by quantum physics, but, my friends, it is not going to fix our understanding of the universe. 

# We're trolls and punks, not a new 

One of the things I most enjoy about Bitcoin is the culture: we're a bunch of meme-toting edgelords with delusions of grandeur that occasionally come true. This is lovely because even though we have plans to conquer the world, Bitcoiners have traditionally avoided the trap of taking themselves too seriously. 

Such being our nature, I enjoy a blithe "Bitcoin fixes this" or an obnoxious "Have fun staying poor!" as much as the next guy (perhaps much more than the next guy). Nonetheless, it's important for us to remember that we're just playing with magic internet money here -- it's a glorified computer game.

I have no interest in convincing established disciplines that Bitcoin is relevant to their field. I want Bitcoin so that anyone can route around such entrenched powers to do whatever it is they want to do.

My friends, it is enough to fix the money. We do not need to fix the physics, nor time, nor epistemology. 

I'm firmly convinced that things like this music video have more relevance for humanity than endeavors to rewrite physics in the shape of Bitcoin.

https://www.youtube.com/watch?v=jq57BjBVq7o

The Bitcoin Lens - "This changes everything!"

Don't you just love it when a group of people decode that freedom is too risky for you?

> A Targeted Report on Stablecoins and Unhosted Wallets will examine emerging risks associated with stablecoins, which have grown rapidly in global scale, reach and importance in recent years. It makes recommendations to help countries and the private sector mitigate risks, including where stablecoins are being moved through peer-to-peer transactions.

FATF commissions reports about the AML risks of "unhosted wallets"

# Not just another money-grubbing lawsuit

This stuff really freaks me out. Apparently, people are suing Meta and YouTube and all the other social media platforms for not preventing them from using social media. 

> Mark Zuckerberg spent more than five hours on the stand in Los Angeles Superior Court on Wednesday, testifying before a jury for the first time about claims that Meta deliberately designed Instagram to addict children.

> The lawsuit was filed by a plaintiff identified as KGM, now 20 years old, who claims she began using Instagram at age 9 and that the platform’s design addicted her to it, worsening her mental health, contributing to anxiety, body dysmorphia, and suicidal thoughts.
> 
> TikTok and Snapchat settled before trial. Meta and Google’s YouTube remain defendants. Over 1,600 related cases are pending nationally. This is a big business. A verdict here could set the template for all of them.
>  
> The case rests on a contested scientific premise: that social media is clinically addictive and that this addiction causes measurable harm. That premise drives the legal strategy, the media coverage, and the resulting policy agenda. It deserves scrutiny that most coverage is not giving it.

# This routes around section 230 

> Section 230 of the 1996 Communications Decency Act has long shielded platforms from liability for what users post. Plaintiff’s lawyers here found a route around it: they argue that the platform itself is a defective product. The claim is not about user content but about design choices. Infinite scroll, auto-play, algorithmically amplified notifications, beauty filters linked to body dysmorphia. The lawsuit treats them like a car without brakes.

And if we're all driving cars with poorly designed brakes, don't we need big daddy government to come in and make sure we are being safe?

> “Addiction” is how you get a public health emergency. A public health emergency is how you get emergency powers and make it easier for people to overlook constitutional protections. Emergency powers applied to the internet mean mandatory access controls. And mandatory access controls on the internet mean the end of anonymous and pseudonymous speech.
 
I was thinking that it was gonna take a number of years before the internet got fully gated. I'm not feeling so good about that anymore. This is moving fast.  

> Zuckerberg is not proposing that Instagram verify the ages of Instagram users. He is proposing that Apple and Google verify the identity of every smartphone user, for every app, at the OS level.

The regulations are coming:

> California’s SB 976, the Protecting Our Kids from Social Media Addiction Act, mandates age verification systems for social media platforms in the state. The California Attorney General must finalize implementation rules by January 2027.

> The Kids Online Safety Act (KOSA), pending at the federal level, would direct agencies to develop age verification at the device or operating system level, the same framework Zuckerberg promoted from the stand.
>  
> KOSA also carries broad definitions of “harmful” content that leave moderation decisions subject to government influence, with no independent review. Age verification and content restriction in a single bill, with the government writing the definition of harm.
>  
> New York’s SAFE For Kids Act restricts algorithmic feeds for users who don’t complete age verification. Acceptable alternatives to submitting a government ID include facial analysis that estimates age. Biometric data, collected to scroll a social media feed.

The whole article is worth a read.

Zuckerberg’s “Fix” for Child Safety Could End Anonymous Internet Access for All

The Deva at Nunchuk posted this on X earlier today. It is a nice defense of miniscript and OP_IF. The debate is not settled that OP_IF is some kind of vulnerability nor is it the case that minoscript is some foolish "wizard" fanciness nobody actually uses. 

> There are some misconceptions about OP_IF and Miniscript. Let’s clear them up.
>  
> # Misconception #1: Taproot branches are always better than their OP_IF equivalent
>  
> Take this example policy for a business treasury:
>  
> Alice AND (Bob OR Timelock).
>  
> In English: To spend, Alice must always sign. Then either Bob signs, or a timelock acts as a fallback: if Bob is unavailable, Alice can broadcast the transaction by herself after some delay.
>  
> If you use a single OP_IF script, spending the primary path means revealing the whole script, including the unexecuted Timelock fallback. That Timelock logic is ~5 bytes.
>  
> If you split this into two Taproot branches (Leaf A: Alice+Bob; Leaf B: Alice+Timelock), you can hide the 5-byte Timelock.
>  
> However, spending Leaf A now requires adding a 32-byte Merkle proof to your Control Block to prove the leaf is in the tree.
>  
> So you'd pay a 32-byte penalty to hide 5 bytes of script. This makes the transaction ~27 bytes more expensive.
>  
> For certain types of wallets, OP_IF can absolutely be cheaper to use than Taproot branches. The above is a simplified example, but the principle applies generally.
>  
> # Misconception #2: Miniscript is only for “fancy”, convoluted use cases
>  
> The evolution of Bitcoin self-custody can be seen as 3 major milestones:
>  
> - First Era: “Not your keys, not your coins”
The early days of Bitcoin started with the simple premise that you must hold your private keys to secure ownership of your bitcoin. This typically manifested in the use of cold storage (dedicated signing devices), where the vast majority of setups required only a single signature.
>  
> - Second Era: Eliminating Single Points of Failure
Your bitcoin is only as secure as its weakest link. A singlesig wallet represents a Single Point of Failure (SPoF). Hence, the critical importance of multisig when holding any serious amount of bitcoin became very clear.
>  
> - Third Era: Decaying Multisig & Layered Security
Multisig solves the SPoF issue, but it creates a new challenge: the harder you make it to withdraw funds, the harder it is to pass on the wealth to the next generation or recover from lost keys.
>  
> "Decaying multisig" is the natural next step. It combines the best of both worlds: you start at a very high bar of security (just like a regular multisig), but then gradually relax it with timelocks so that over the long run, your family or business partners have an easier time accessing the funds.
>  
> As the market matures, it will become clear that different use cases and users will require different levels of security. The higher the stakes, the stricter the requirements: Layered security. There won’t be a one-size-fits-all.
>  
> These ideas are not rocket science. They represent the logical evolution of a new technology slowly being understood and adopted.
>  
> The example wallet we cited at the beginning isn’t a convoluted setup that only the craziest nerds can think of. Anyone can understand why someone might set up such a contract. It is highly practical and solves a very real pain point.
>  
> The beauty of Miniscript is that it allows us to standardize the types of wallets created in this Third Era. Because of it, you have strong assurance that a wallet created by one software can be easily recovered by any standard-compatible software.
>  
> Miniscript is one of the most important engineering projects in Bitcoin, because self-custody is the cornerstone of all things Bitcoin. Layer 2 or privacy technologies are meaningless without the ability to secure base layer Bitcoin.
>  
> Fast forward 10 years, and an enterprise-grade custody solution will likely involve Miniscript or something similar.