Post-Quantum Cryptography

On September 19, 2026, Stephen Weis published the factors of the RSA-896 challenge number after using Claude to adapt classical factoring software for GPUs and coordinate a fleet of up to 2048 GPUs. The computation ran over ten days and performed about 30 GPU-years of work, as documented in Weis’s primary technical account. The experiment simplified the engineering effort required for large classical computations, but it did not compromise Bitcoin’s elliptic curve cryptography.

Key Takeaways:

The record factorization used the general number field sieve on GPUs, with an AI agent assisting with software porting and computation management.

Integer factorization and the elliptic curve discrete logarithm problem are distinct mathematical problems. The factoring experiment does not provide a classical break of secp256k1.

Bitcoin reveals public keys through pay-to-public-key outputs, Taproot outputs, and spends from hashed-key outputs. Key reuse can leave new funds linked to a key already visible on-chain.

Shor’s algorithm can solve the relevant elliptic curve problem on a sufficiently capable fault-tolerant quantum computer. Published resource estimates are planning inputs, not demonstrations of successful key recovery.

Wallet operators can reduce long-exposure risk by issuing fresh addresses, detecting key reuse, inventorying script types, and tracking draft Bitcoin Improvement Proposals without assuming proposals are deployed defenses.

The RSA Factoring Record

The factored RSA challenge number has 270 decimal digits and is 896 bits long. Weis published the original number and both prime factors, enabling independent mathematical verification. His technical note also details the use of CADO-NFS, the GPU porting work, and the allocation of idle Anthropic computing capacity.

The result was an implementation and operational achievement rather than a new factoring algorithm. Weis states that the work did not significantly improve the runtime of the general number field sieve. The project instead showed how agent-assisted engineering can move an established computation onto different hardware and maintain a large collection of low-priority jobs running.

Bitcoin exposure path	When the public key becomes visible	Operational consequence	Source
Pay-to-public-key output	The output contains the public key directly	Any unspent value remains associated with a visible key	Bitcoin developer glossary
Pay-to-public-key-hash output	The spending input supplies the public key and signature	Reusing the key can associate later unspent funds with a previously disclosed key	Bitcoin transaction guide
Taproot output	The output commits to a public output key	The key is visible while the output remains unspent	Taproot specification

Agent Work in Number-Field Sieving

The general number field sieve is a classical method for factoring large RSA moduli. In the record project, Claude was used to adapt CADO-NFS for GPUs and coordinate low-priority computation on otherwise idle hardware. The published account does not describe a new mathematical method, autonomous discovery of a factoring algorithm, or an improvement that reduces the established scaling cost.

This distinction separates the agent’s engineering contribution from the mathematical attack. Porting software requires adapting workloads to hardware, resolving failures, managing dependencies, and verifying result validity. Orchestration adds job placement, retries, progress tracking, and use of fragmented capacity. Automating parts of that work can reduce the amount of specialist attention required per experiment without changing the problem being solved.

Large computations can become accessible to more organizations even when the underlying algorithm remains unchanged. An agent can test implementation choices and keep spare hardware occupied, but the organization still needs computing capacity, validation procedures, and human oversight. For related defensive implications, see our analysis of artificial intelligence-assisted cryptographic threats.

GPU servers used for large-scale cryptanalysis — Porting and scheduling made idle data-center GPUs usable for a large classical factoring workload.

The RSA Security Boundary

The record changes the practical assessment of short RSA keys. Weis concludes that RSA-1024 is vulnerable to actors with data-center-scale GPU fleets, based on the resources and engineering observed in his project. The conclusion applies to organizations capable of obtaining substantial hardware capacity, not attackers using ordinary workstations.

RSA-2048 remains outside the showed result. Weis explicitly states that his work does not affect deployed RSA-2048 keys. The experiment supports reassessing obsolete key sizes and operational assumptions, but it does not set a deadline for factoring larger production keys.

Security teams should examine whether specialist labor or access to suitable software has been treated as a lasting barrier. Agent-assisted porting and job management weaken that assumption. Spare computing capacity also requires governance because low-priority workloads can consume resources that appear unused during ordinary monitoring.

Inventory RSA key sizes: identify certificates, signing keys, embedded devices, and archived data that still depend on RSA-1024.
Separate attack categories: modulus factoring, weak randomness, exposed private keys, and side channels require different controls and monitoring.
Record replacement constraints: document which systems can rotate keys through configuration and which require firmware, hardware, or protocol changes.
Monitor idle compute: alert on unexpected GPU jobs, long-running low-priority workloads, and unapproved cryptographic software.
Reassess old cost estimates: update threat models when porting tools, scheduling systems, or hardware access change.

Bitcoin’s Public-Key Exposure

Bitcoin does not use RSA for transaction authorization. Traditional transactions use the Elliptic Curve Digital Signature Algorithm over secp256k1, while Taproot uses Schnorr signatures over the same curve. The Bitcoin developer guide explains that a pay-to-public-key-hash output records a hash and that spending it supplies the full public key along with a signature.

Exposure depends on the output type and the wallet’s behavior. Early pay-to-public-key outputs publish a key directly. The Taproot specification defines outputs containing an output key. A hashed-key output delays disclosure until spending, but reuse can link a disclosed key to another output that remains unspent.

Measurements published in 2026 associate about 6.9 million bitcoin with public keys already visible on-chain. This amount concerns bitcoin held under exposed-key conditions rather than a count of wallet addresses, as detailed in the measurement of Bitcoin’s quantum-exposed supply. The figure describes a potential future attack surface. It does not mean those funds can be recovered from their public keys by current classical systems.

Classical and Quantum Attack Paths

The RSA record and Bitcoin’s quantum risk share an operational lesson, but their classical attack algorithms do not overlap. The general number field sieve factors an RSA modulus. Recovering a Bitcoin private key from a secp256k1 public key requires solving an elliptic curve discrete logarithm problem. The published factoring work reports no progress on that classical problem.

Shor’s algorithm applies to both problem families when run on a sufficiently capable fault-tolerant quantum computer. Google’s analysis of cryptocurrency vulnerabilities estimates the quantum resources needed to attack elliptic curve cryptography. Such calculations depend on assumptions about architecture, error correction, circuit design, and hardware performance. They should be read as resource models rather than proof that existing hardware has recovered a cryptocurrency private key.

The phrase “harvest now, decrypt later” describes encrypted information collected for future decryption, so it applies to Bitcoin only loosely. The blockchain already stores public keys revealed by certain outputs and spending transactions. A future attacker would search that public ledger for visible keys still connected to unspent funds, then attempt private-key recovery if suitable hardware became available.

Interpreting Faster Engineering Cycles

A rapid factoring result shows that software engineering and computation management can improve quickly. It is not a formula for forecasting the failure of larger RSA keys or secp256k1. Hardware availability, implementation quality, memory requirements, validation, and the scaling behavior of each attack all affect the outcome.

Bitcoin operators should compare the speed of technical experimentation with the time required for protocol migration. A change must pass specification review, gain wallet and hardware support, be tested by exchanges and custodians, and obtain sufficient network agreement. Users must then move funds before an old output type is retired or becomes unsafe.

This creates a governance and deployment problem before a practical quantum attack exists. Waiting for a confirmed key-recovery event would leave little room for testing or gradual migration. Treating speculative hardware dates as certainties would create a different risk by encouraging rushed consensus changes.

The secp256k1 Security Model

Public-key visibility creates a target, but visibility alone does not break the system classically. A public key is designed to be shared, and security depends on the cost of deriving the corresponding private key. Address hashing adds a disclosure delay for relevant output types rather than changing the underlying curve.

Consider a treasury that receives a payment, spends the output, and later accepts another payment tied to the same key. The first spend permanently publishes that key. The later unspent output then remains linked to an already visible target for as long as it stays on-chain. Issuing a fresh address prevents that specific reuse path.

Issue a fresh receiving address for each transaction. Remove static treasury, invoice, deposit, and donation addresses from routine workflows.
Inventory unspent outputs by script type and key history. Flag pay-to-public-key, Taproot, and hashed-key outputs whose keys appeared in earlier inputs.
Detect reuse at the key level. Different address strings do not necessarily prove that the underlying wallet relationships are separate.
Monitor pending transactions. A future short-exposure attack would target the interval after a spending transaction reveals its key and before confirmation.
Test migration procedures: confirm that signing devices, custody policies, withdrawal systems, and recovery workflows can support a new output type.

Bitcoin Migration Work to Track

Draft Bitcoin Improvement Proposal 360 proposes pay-to-Merkle-root, an output type that removes Taproot’s key path and commits to a script-tree root. Its stated scope is resistance to long-exposure attacks. The draft also says the design does not prevent a short-exposure attack against a key revealed while a spending transaction waits for confirmation.

Draft Bitcoin Improvement Proposal 361 describes a migration and sunset process intended for use after a post-quantum output type exists. Both documents are proposals rather than active Bitcoin protections. Wallets and custodians should track specification changes, test vectors, transaction costs, recovery behavior, and activation status.

Post-quantum standards also separate signatures from key establishment. ML-DSA and SLH-DSA are signature standards, while ML-KEM is a key-encapsulation mechanism and cannot substitute for a Bitcoin transaction signature. The National Institute of Standards and Technology announcement identifies the algorithms and their respective purposes.

Bitcoin still needs decisions covering consensus rules, signature encoding, transaction weight, wallet recovery, hardware compatibility, activation, and treatment of funds that do not migrate. For the wider distinction between classical and quantum attacks, see Post-Quantum Security for Blockchain Systems. The next installment examines Ethereum’s post-quantum roadmap, account migration strategies, account abstraction, and Layer 2 custody dependencies.

More in-depth coverage from this blog on closely related topics:

Sources and References

Sources cited while researching and writing this article: