What is BIP-361?

BIP-361 is the proposal most often mentioned alongside BIP-360, and most often confused with it. It is not a new address type and it is not a signature scheme. It is a timeline: two soft forks that would first stop coins from being sent to any of today's address types, and then, years later, lock ECDSA and Schnorr spends behind a protocol a quantum attacker could not satisfy. This article explains what the draft says, what it leaves open, and what it would mean for coins that have never been exposed at all.

What BIP-361 is, and what it is not

Start with the preamble, because it answers most of the confusion. The draft is listed as Informational in type and Consensus (soft fork) in layer, with a status of Draft. Its only dependency reads, verbatim, “TBD Post Quantum Signature BIP”. It does not name BIP-360 anywhere.

That tells you what it is. BIP-361 is not the thing that gives Bitcoin quantum-safe outputs; it takes for granted that something else will. BIP-360, Pay-to-Merkle-Root, is the leading candidate for that something else, but as we explained in that article it removes the exposed key path rather than adding a post-quantum signature, and the dependency BIP-361 names is a signature BIP. So there is a missing piece between the two that no published draft fills today.

What BIP-361 adds is a deadline. Its abstract says the proposal “turns quantum security into a private incentive”: fail to upgrade and you meet friction using your coins, with that friction announced years in advance. It is a migration plan, with the sunset as the forcing function.

The two phases

The specification is a single short table. Here is what it says, with the timing as written.

• Phase A. “Permitted sends are from legacy scripts to PQ scripts.” In other words, once Phase A is in force, a transaction may only create outputs of the new post-quantum type. You could still spend from a 1…, 3…, bc1q… or bc1p… output, but you could no longer send coins to one. The time horizon is 160,000 blocks, which the draft glosses as about three years, after BIP-361 activation.
• Phase B. “At a predetermined block height, nodes tighten requirements on verification of ECDSA/Schnorr.” The time horizon is two years after Phase A. The abstract describes the same moment as a flag day five years after activation; three years of Phase A plus two more add up, so the two descriptions agree.

“Tighten requirements” is doing a lot of work, and the draft is honest that it is not yet specified. The idea is that an ECDSA or Schnorr signature alone would no longer be enough; the spender would also have to satisfy a rescue protocol, covered below. Coins whose owners never do so would stay where they are, permanently. The draft calls this “supply discipline” and quotes Satoshi on lost coins: “Think of it as a donation to everyone.”

Which addresses count as vulnerable here

Here readers of this site need to slow down, because the vocabulary differs from ours. In our first article, and in the scanner, an address is exposed when its public key is already on the chain, and protected when only a hash is. A fresh bc1q address that has never spent is protected at rest, and we say so.

BIP-361 draws the line somewhere else. Its sunset applies to every output spent with ECDSA or Schnorr, which is every output type Bitcoin has today, including the never-spent, hashed, protected ones. The rationale explains why: the authors list three things no existing proposal protects against, and the first is the short-range attack, against a key revealed in a transaction while it waits to be confirmed. A hashed address is safe sitting still, but the moment it spends it reveals a key like any other. Removing ECDSA and Schnorr from the spend path altogether is the only way to close that window, and that means retiring the hashed types too.

So the two views are complementary. ShorWatch tells you which of your coins are exposed now, at rest, with no soft fork needed. BIP-361 is about what would have to happen to every coin, exposed or not, if the network retired the old signatures. A protected verdict in the scanner is good news today; it is not a pass that would exempt you from a migration.

Why the authors want a deadline

The motivation section is the part most people will have opinions about, so it is worth reporting what it actually argues.

On exposure, it gives one figure: as of 1 March 2026, over 34% of all bitcoin had revealed a public key on-chain. That is the number we have cited in our article on address reuse, and it matches what we see at the top of the distribution, where 67 of the 100 largest addresses are already exposed, almost all of them by reuse.

On the threat, it cites industry roadmaps with early estimates for a cryptographically relevant machine, and a Google post on algorithmic improvements lowering the hardware needed. We do not repeat those estimates. Our position has not changed: no machine today can run Shor's algorithm at the scale a 256-bit curve key requires, and anyone who gives you a year is guessing. The authors would reply that the uncertainty is exactly the problem, and that is a fair argument to have.

The strongest part of the motivation is about what an attack would look like. An attacker who could derive private keys would have no reason to announce it. They could compute keys and move funds “weeks or months later, in a covert bleed”, and the network might learn a quantum computer existed long after it did. Nor can anyone know whether an attacker wants money or wants to destroy trust. A defence, the draft says, has to be in place before either becomes visible.

Finally, the rationale sorts every possible response into three kinds: let anyone steal vulnerable coins, let people steal them in a throttled way, or let no one steal them. BIP-361 picks the third, and its answer to the obvious objection, that this freezes coins, is the rescue protocol.

The rescue protocol

Phase B only works if a legitimate owner can move old coins in a way a quantum attacker could not copy. The draft's term for this is a knowledge asymmetry: anything the real owner knows that cannot be derived from the public key.

The example it leans on is BIP-32. Almost every wallet built since 2012 derives its keys from a seed, and most derivation paths include a hardened step. A hardened child cannot be linked to its parent from the public side, so proving knowledge of the parent extended private key is something the owner can do and an attacker, holding only the child's public key, cannot. The draft cites research into ZK-STARK proofs and into commit-and-reveal schemes as two ways of turning that into a spend condition, the second cheaper but with a more delicate multi-step security model.

Two honest caveats come straight from the text. First, the authors write that it “remains to be seen” how much of the legacy supply such protocols could cover, and that if they cover a majority the restriction would be “at most mildly confiscatory”. That careful phrase concedes that some coins with living owners might not qualify. Second, there is no rescue for pay-to-public-key outputs, the format Satoshi-era mining rewards used. The draft says no knowledge asymmetry is known for them, and instead declares itself compatible with a separate “Hourglass” style proposal for those coins, provided it activates before Phase B. Without that, the oldest coins on the chain would simply stop being spendable.

What it would mean for wallets and nodes

The backward compatibility section is the best guide to how the migration would feel from the outside.

• Before Phase A, nothing changes. Old and new wallets send and receive freely.
• After Phase A, a wallet that has not been upgraded can no longer receive from anyone, because nobody may create outputs of its type. It can still send, but only to upgraded wallets.
• After Phase B, both sides need upgraded wallets, and moving any remaining old coins means going through the rescue protocol.

Nodes behave as in any soft fork: an old node keeps validating but treats the new post-quantum witness programs as anyone-can-spend, so it is strongly encouraged to upgrade. The draft also tabulates why miners, institutions, custodians and individuals would go along with this. Whether those incentives are enough is the political question, and the BIP does not pretend to settle it.

What it means for your coins today

Nothing, in the sense that there is nothing to do and no reason to hurry. The draft has no activation mechanism, depends on a signature BIP that does not exist, and would need the kind of agreement that Taproot, a far smaller change, took years to gather. We said in the BIP-360 article that BIP-361 is neither small nor broadly supported, and nothing in the current text changes that.

It does change how you might think about the coins you already hold, in two ways.

1. Know your split now. Every version of this migration, BIP-361 or any gentler alternative, starts with the owner knowing which outputs are exposed and which are not. The coins on revealed keys are the ones any plan treats as urgent; the hashed ones have time. Checking that split costs nothing, and it is the information you would need the day a real activation was announced.
2. Keep the seed, not just the keys. If something like the rescue protocol ever ships, it will favour ordinary seed-based wallets with standard derivation. Imported single keys, or coins whose seed you no longer control, would be the hard cases. This is not a reason to move coins today, since moving them creates its own exposure; it is a reason to keep good custody of the seed you already have.

The standing advice does not move: do not reuse addresses, keep long-term coins on fresh hashed outputs rather than Taproot, and treat any announcement with a date in it with scepticism.

Where it stands

BIP-361 was assigned its number in February 2026 and remains a draft. It is the clearest statement so far of the view that Bitcoin should retire its current signatures on a fixed schedule, and it is useful because it states that view without softening it. It is also the proposal most likely to be rewritten, because every hard part, the signature scheme, the rescue protocol, the fate of P2PK, is delegated to work still being done. We will update this article when the text changes, as we had to do for BIP-360.