Coinbase sets out priorities for Bitcoin’s post-quantum transition
Source report: 2026-10-13 · Editorial analysis published: 2026-10-14
Shashank Agrawal’s October 13 technical post proposes flexible outputs, staged migration and safer signing implementations. It is input to discussion, not an activated Bitcoin upgrade or a deadline for ASIC replacement.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
A technical contribution to an open protocol discussion
Coinbase published Working Together on Bitcoin’s Post-Quantum Readiness on October 13, written by Shashank Agrawal. It argues for preparing before a cryptographically relevant quantum computer is announced, because consensus changes and movement of funds could take years. The author explicitly presents the technical considerations as input to open discussion, not instructions or a final Coinbase position.
This is a proposal about future spending security and ecosystem migration, not a declaration that Bitcoin has already adopted a new signature system. It supplies no verified date when a quantum computer will break existing keys and no deadline to discard mining equipment. Our report distinguishes the new publication from a network activation: identifying desirable engineering properties does not cause every full node to begin enforcing a new rule.
An output structure is different from a signature algorithm
The post separates the structure holding a spending condition from the cryptographic signature scheme used to satisfy it. It points to designs such as P2MR in BIP-360 and the discussed P2TRv2 as ways to retain flexibility for future signature choices. A reusable structure could reduce the need to redesign the entire output type whenever another scheme or parameter set is considered.
The BIP-360 text describes P2MR as a proposed Merkle-root-based output structure. It is not itself a complete deployment of post-quantum signatures. Reading the design as an already activated replacement for ECDSA or Schnorr would erase that scope. The engineering question is how a future spending path can make algorithms identifiable and rules unambiguous while still fitting Bitcoin’s limits on witness size and verification work.
One of two spending paths is not two required approvals
Coinbase discusses a possible transitional 1-of-2 design, with a classical ECDSA/Schnorr path and a post-quantum path as alternatives for spending the same funds. Either authorized path would be sufficient under that construction; it is not a requirement to submit both signatures for every transaction. The post also discusses staged protection rather than requiring the entire policy for old signatures to be settled before active wallets can move.
Our analysis notes a consequence of that alternative-path model: while the classical path is still accepted, adding a post-quantum alternative does not by itself eliminate exposure through the classical path. Protection depends on the construction and the later rules that govern which paths remain available. Therefore the presence of a PQ option, a completed wallet migration and the retirement of a vulnerable path should be tracked as distinct milestones, rather than treated as interchangeable claims of safety.
State management can become part of the signing boundary
The publication highlights the potential size and speed advantages of stateful signatures but warns that reusing signer state can permit forgery. Its concern includes independent servers, uncertain writes and recovery from backups. It calls for a stateless option when stateful schemes are supported. This is about state inside a signing scheme, not simply whether a wallet displays a balance or a miner has synchronized the blockchain.
An illustrative recovery example shows the difference: restoring an older backup may restore a signing state that has already been consumed after the backup was made. A system must establish whether that state is still safe before signing again. Counting only transactions confirmed on-chain is insufficient if signing events happened outside that set. This is a general explanation of the failure mode raised in the post, not a report that Coinbase suffered such a compromise.
Institutional custody needs more than a small signature
The post asks for reproducible, Bitcoin-specific evaluation and robust implementations, including deterministic verification across platforms and resistance to random-number failures. It also identifies compatibility with multiparty computation, hardware wallets and security modules as relevant. These properties affect whether an institution can protect its keys while retaining a workable signing service, and cannot be assessed from a signature’s byte count alone.
A comparison should keep generation, signing, verification, recovery and custody assumptions separate. A scheme that looks attractive in a single-process demonstration might have different constraints in a distributed signing system. Coinbase’s MPC discussion does not ask the Bitcoin community to adopt one particular MPC protocol. It asks that signature choices be assessed against custody requirements alongside the needs of individual users and the consensus system.
Network costs need a consistent workload
Coinbase lists block capacity, fee cost, full-node validation, initial synchronization, propagation and migration throughput as dimensions for evaluating candidate schemes. For an illustrative payload calculation, 100,000 spends with an assumed extra 1,000 bytes each would add 100,000,000 bytes before any further transaction overhead. Those chosen inputs are not the size of an adopted Bitcoin signature, a measured network backlog or a prediction of fees.
The example explains why per-signature size and ecosystem-scale migration are different comparisons. Fee estimation would additionally need the actual transaction construction, witness weighting and a fee rate. A byte-only multiplication cannot be substituted for Bitcoin’s weight rules or used to announce an exact future fee. Likewise, a cryptographic microbenchmark alone does not establish how blocks propagate or how every full node performs under a mixed workload.
Dormant coins remain a separate unresolved problem
The post treats inactive, lost and exposed funds as a separate governance and engineering question that can be discussed alongside technical signature support. It raises late migration and possible rescue mechanisms without claiming that a policy has been accepted. Dormant funds are not automatically abandoned funds: a holder may still have the relevant secret even when an address has not moved coins for years.
A rescue proposal would need to show what evidence the rightful holder can supply and why a future attacker knowing a public key cannot use the same route. Losing a secret, preserving a seed and failing to meet a migration window are also different situations. The new publication does not authorize confiscation or transfer old coins to miners. An actual policy would require its own precise design and a separate consensus discussion.
Mining readers should separate hashing from authorization
For ASIC owners, the immediate distinction is between proof-of-work hashing and signatures authorizing the spending of coins. This technical post addresses the latter and how nodes and wallets might validate future spending paths. It does not announce a SHA-256 mining algorithm change or provide a revised hashrate, power draw or profitability input for any current miner. Hypothetical future validation costs also do not translate directly into an ASIC firmware requirement.
The archival quantum-computing and security-hardware photographs illustrate the subject; neither proves a computer capable of breaking Bitcoin keys or a deployed Coinbase solution. The confirmed event is a dated engineering contribution. Useful next milestones would be updated proposals, reproducible implementations, evaluated custody workflows and explicit consensus decisions. Until those exist, a technical roadmap and an operational network change should remain clearly distinguishable.
Source: Coinbase / Bitcoin BIPs ↗ · BIP-360 P2MR specification ↗
Mining calculator ↗
