Six Bitcoin Proposals Would Rewrite Wallets, Security and Even the Word 'Satoshi'

Six active Bitcoin Improvement Proposals — including one that would eventually block transfers to quantum-vulnerable addresses and another that would stop calling the smallest unit a "satoshi" — are working through Bitcoin's drafting process, and several carry timelines that start the moment they activate.

None of this is live on the network today. But the drafts sketch what everyday Bitcoin storage and spending could look like within years, not decades.

What does BIP 361 do about quantum computers?

The most aggressive idea is BIP 361, co-authored by Jameson Lopp. It lays out a phased transition in case quantum computers become powerful enough to break Bitcoin's current signature schemes.

The first phase blocks new BTC transfers to quantum-vulnerable address types roughly three years after activation. Two years after that, spending with existing ECDSA and Schnorr signatures would face additional conditions.

The intent is simple. Attackers should not be able to seize coins sitting in old addresses. Quantum-resistant recovery paths would let rightful owners reclaim funds.

That raises a harder question: what happens to coins that never migrate, or wallets dormant for a decade? The draft doesn't dodge it, but it doesn't resolve it either. BIP 361 remains a draft and depends on a post-quantum signature standard that doesn't exist yet.

A companion draft, BIP 360, proposes a new output type called Pay-to-Merkle-Root. It removes the direct key-based spending path in taproot, shrinking the quantum exposure created by public keys sitting visible on-chain. It does not, however, protect against attacks during the brief window when a transaction waits for confirmation.

Can you recover funds after a hacker gets your key?

Vault designs say yes. BIP 345, now marked closed, proposed a mandatory delay before BTC could move to any address. The document gives a concrete example: a one-day waiting period.

Under that model, an attacker holding the daily key still cannot drain the wallet immediately. The user gets a window to push funds down a predefined recovery path using a separate recovery key.

BIP 443, developed by Salvatore Ingala, replaces it as the suggested alternative. It offers a broader framework for setting conditions on how BTC gets spent in later transactions. Vaults are one use case. Shared fund management and scaling designs are others. It is still in draft.

What are Silent Payments?

BIP 352 defines a method called Silent Payments. Reusing one address on Bitcoin makes it easy for outsiders to cluster every payment that hits it. Silent Payments fixes that.

The user shares a single piece of payment information. For each incoming payment, the protocol derives a different destination address on-chain. A donation address published on a website could receive payments from many senders, and no observer could link them just from the shared code.

The cost lands on the recipient. Their wallet must scan the blockchain to find its own payments — a real burden for lightweight wallets.

BIP 352's technical text is completed. Unlike the other proposals here, it changes no consensus rules. Adoption depends entirely on wallet support.

Should 0.0001 BTC just be called 10,000 bitcoin?

John Carvalho's BIP 177 takes aim at language rather than code. It proposes renaming the smallest unit — the satoshi — as "one bitcoin." Wallets would show whole numbers instead of long decimals.

An amount displayed today as 0.00010000 BTC would read as 10,000 bitcoin under the new convention.

Nothing structural changes. Supply rules, user holdings and issuance stay identical. The BTC code keeps its current meaning: 1 BTC still equals 100 million base units. The draft would, however, split the words — "bitcoin" and BTC would denote different denominations. It remains a naming convention for wallets and applications to adopt voluntarily.

Why bring back OP_CAT?

BIP 347 wants to reactivate OP_CAT, an instruction from Bitcoin's early days that was switched off in 2010.

Its job is basic: concatenate two pieces of data. That primitive would let developers build more complex spending conditions and verification mechanisms on Bitcoin. The proposal lists vaults, advanced contracts, payment channels and simplifications to the BitVM2 design as use cases.

The new version caps combined data at 520 bytes. And one caveat matters: BIP 347 is marked completed, but that only finalizes the technical document. Actually enabling the opcode requires a separate soft fork.

Could BTC move to sidechains?

BIP 300, from Paul Sztorc and CryptAxe, handles transfers between Bitcoin and sidechains running different security models. The so-called Drivechain approach would let users move BTC to sidechains with distinct features, then back to the main network.

The distinctive part is the withdrawal mechanism. Conversions from sidechains to Bitcoin would be managed by a miner-based proof-of-work process, not a fixed company or signatory group.

That structure lets developers test transaction and application designs away from the main chain. The trade-off for users is equally clear: miners hold the keys to getting funds back, and the security assumptions follow from that.

BIP 300 remains a draft, not a shipping feature.

What changes next?

For now, very little on-chain. BIP 352 and BIP 347 have finalized technical texts but need wallet integration and a soft fork respectively; BIP 361, 360, 443 and 300 are still drafts. The watch item is BIP 361's activation clause — the day it activates, a three-year clock on quantum-vulnerable addresses starts ticking.