Any Quantum Secure Address in the Horizon?

[Satofan44]

Even though outdated still an interesting insight. Including shrincs and shrmps, is there any place to see a debate on which options are in the lead and why?

There are many places where you could look for such discussions and follow them, they are not here. Besides a few users here, most are just shitposting nonsense in regards to this topic. Here are some directions:

• https://delvingbitcoin.org/tag/post-quantum
• https://delvingbitcoin.org/t/bitcoin-and-quantum-computing/1730
• https://groups.google.com/g/bitcoindev

Those are all the resources you need.

Some of the oversized options are already out-of-the-question I would assume.
Obviously there are a variety of ways to go quantum-secure, but there must be some clear metrics on how to decide on the most efficient algorithm besides of data-usage, really curious to hear which they are.

They are all literally part of the image, did you even actually read it? Size is just one metric, even if a scheme has a really lean size it is useless for Bitcoin if its signing and verification speeds are terrible. It has to have a reasonable balance of the three. Besides those, scaling related metrics, other secondary things could be considered such as implementation complexity and auditability. If a scheme is efficient but extremely complex, I would not risk going that road. Imagine a scenario where we switch to the wrong PQ with a majority of coins migrated only to discover a fatal flaw in it later, terrible preposition.

With google suggesting cracking Bitcoin keys may come as early as 2029 I really wonder how close we are to consensus here.

Google has not really announced that Bitcoin will be breakable by 2029, if you actually look at the hardware roadmaps or research steps then you will see that nothing is even remotely close to the number of qubits required to run Shor's algorithm. There are various reports estimating all kinds of things, putting the estimate for the expected window for a cryptographically relevant QC between 2030 - 2035 but it is just that an estimate -- there is no consensus and even if it were it is just a speculation, enormous engineering leaps are required to get there.

[ABCbits]

With google suggesting cracking Bitcoin keys may come as early as 2029 I really wonder how close we are to consensus here.

Google never said that. News media either misreport or intentionally hyperbole what they say.

Google’s introducing a 2029 timeline to secure the quantum era with post-quantum cryptography (PQC) migration.

--snip--

Quantum computers will pose a significant threat to current cryptographic standards, and specifically to encryption and digital signatures.

If they actually believe quantum computer would break today's cryptography in 2029, their timeline would already started rather than will be started on 2029.

Some of the oversized options are already out-of-the-question I would assume.
Obviously there are a variety of ways to go quantum-secure, but there must be some clear metrics on how to decide on the most efficient algorithm besides of data-usage, really curious to hear which they are.

They are all literally part of the image, did you even actually read it? Size is just one metric, even if a scheme has a really lean size it is useless for Bitcoin if its signing and verification speeds are terrible. It has to have a reasonable balance of the three. Besides those, scaling related metrics, other secondary things could be considered such as implementation complexity and auditability. If a scheme is efficient but extremely complex, I would not risk going that road. Imagine a scenario where we switch to the wrong PQ with a majority of coins migrated only to discover a fatal flaw in it later, terrible preposition.

IMO time to sign is especially important, when some people use hardware wallet or really cheap/old phone, laptop or computer. For example, with SQlsign, it could take few minutes to sign a TX.

[d5000]

There is actually a scheme that can already be used today without any protocol changes, but it is very expensive. It requires some special data to be "found" before creating the transaction via computation, and the cost is estimated as to be as high as $150 if you have to rent hardware for the computation. In addition, the resulting transactions are non-standard as of today so the fees would be high (and you would need miners and nodes that process non-standard transactions).

The paper [1] was created by Avihu Levy from StarkWare in April 2026.

As far as I have understood the principle, it uses a mathematical puzzle that bypasses ECDSA. You would send the coins to a P2SH script with a hash, unlocked by a STARK proof that you know the secret.


[1] https://github.com/avihu28/Quantum-Safe-Bitcoin-Transactions/

[athanred]

the resulting transactions are non-standard as of today

They could be standard, if wrapped in P2WSH, and not in P2SH.

it uses a mathematical puzzle that bypasses ECDSA

It does not, because it uses OP_CHECKSIG inside. See: https://github.com/avihu28/Quantum-Safe-Bitcoin-Transactions/blob/main/script/script_8p1b_7p2b.txt

Code:

<sig1_pin>              // 9 bytes, hardcoded, SIGHASH_ALL
OP_OVER                 // [1] copy key1
OP_CHECKSIGVERIFY       // [2] verify (sig1, key1) — tx binding
OP_RIPEMD160            // [3] key1 → sig2
OP_SWAP                 // [4] get key2 on top
OP_CHECKSIGVERIFY       // [5] verify (sig2, key2) — proves valid DER

Which simply means, that you start from some small signature, you use public key recovery, to get a matching public key (which is just tweaked z-value in this context), and then, the public key is turned into yet another DER signature, by hashing it.

Anyway, it looks like yet another Proof of Work inside Script. Which means, that you can just replace it with what Saint Wenhao created, and you will get roughly the same thing, but with just a single signature: https://bitcointalk.org/index.php?topic=5551080.0

Because the whole "quantum resistance" here, seems to be based on "letting the computing power decide", and if so, then it is nothing new, and it can be done easier and cheaper, without making complex non-standard scripts. By just changing the public key, used by Saint Wenhao, from one, to anything else, it should be good enough to be resistant to long exposure attacks, and be vulnerable only to the short exposure, when everyone can see the public key, and has to solve the challenge in less than 10 minutes, to steal your coins.

You would send the coins to a P2SH script with a hash

By using P2WSH, instead of P2SH, it would be standard. I guess people could even use P2TR, but public key recovery doesn't work there, and DER signatures allow developers to use hashes in the context of signatures, which is why P2WSH is required instead.

[Satofan44]

If they actually believe quantum computer would break today's cryptography in 2029, their timeline would already started rather than will be started on 2029.

Exactly. People do not understand how to make proper comparisons and distinctions between estimates on various things depending on what they need. AMD or Intel can forecast what their CPUs may be able to do in a year or two, even if it includes some innovations -- they are mostly incremental progress with a very long history. A working quantum computer on scale has never existed, it needs engineering innovations that are almost on the level of "miracles". Apples are not the same as potatoes.

IMO time to sign is especially important, when some people use hardware wallet or really cheap/old phone, laptop or computer. For example, with SQlsign, it could take few minutes to sign a TX.

It is good that you bring it up, but your framing is not correct. Think about it, that is why I said a balance -- because any combination with an extreme does not work:

• 1. Small size, fast verification, extremely slow signing.
• 2. Extreme size, fast verification, fast signing.
• 3. Small size, extremely slow verification, fast signing.

So a reasonable balance between the factor must be had or it simply will not work at all. This helps with dismissing or narrowing down schemes as developments keep rolling in, as obviously any scheme that has any extreme is not appropriate for Bitcoin's future.
Anyway, here is another development and I expect to see more in the coming future @Kryptowerk: https://finance.yahoo.com/markets/crypto/articles/galaxy-digital-moves-protect-bitcoin-215100443.html. People that should be working on this are working on it at a good pace -- users (I'm more referring to other QC threads) need to shut up with their anxieties and learn to be patient.

[athanred]

Small size, fast verification, extremely slow signing.

It works, if you use batching: if a single signature can confirm 1000 things, then it doesn't matter, if it is 1000 times slower to make. Also, it could actually be beneficial to have "slow signing", because when you look at concepts like "sidechains", then they can settle things on-chain for example once per three months. Or if you look at Lightning Network, then you have one channel opening transaction, a lot of traffic in the middle, and one channel closing transaction. If slow signing is the only drawback, then I would go for it, when it comes to the first layer.

Extreme size, fast verification, fast signing.

This is what can be used only on second layers, like sidechains or LN. Because then, after being settled on-chain with a small, fast-to-verify signature, large data pushes from second layers can be entirely discarded, and stored only by interested parties.

Small size, extremely slow verification, fast signing.

This is probably useless, because if verification is slow, then it is just a "garbage producer", where you can quickly make a lot of data, that nobody will ever check properly.

So a reasonable balance between the factor must be had or it simply will not work at all.

Having #1 scheme on layer one, and #2 scheme on layer two seems to be good enough in case of emergency. And probably the first attacks, which will get closer to breaking things, will result in better solutions as well. Because if you know, what is attacked and how, then it is easier to be protected from that, just like it was with hardened SHA-1, which is entirely based on practical attacks, and doesn't block anything else than that.

[Mario0]

Certain Crypto Currencies are claiming to have them already. When Bitcoin?

Since Bitcoin does not yet have a quantum-secure address, it is clear that it does not require it at this time, and the quantum's that are available now are not yet powerful enough to break Bitcoin's encryption, and if it becomes so, I am confident that the developers will make an upgrade, because, and since awareness is everywhere, I do not believe things like this will be ignored. And other new cryptocurrencies are built with different cryptography when it becomes a concern, then it will not be ignored, that I know for sure.

[Satofan44]

Thank you for expanding the individual elements of my post.

Small size, fast verification, extremely slow signing.

It works, if you use batching: if a single signature can confirm 1000 things, then it doesn't matter, if it is 1000 times slower to make. Also, it could actually be beneficial to have "slow signing", because when you look at concepts like "sidechains", then they can settle things on-chain for example once per three months. Or if you look at Lightning Network, then you have one channel opening transaction, a lot of traffic in the middle, and one channel closing transaction. If slow signing is the only drawback, then I would go for it, when it comes to the first layer.

While you are technically right, I don't think that we are going to see both deployed simultaneously because doing so would significantly increase implementation risk. Right now we don't have batching or signature aggregation on Bitcoin, and because of that I am hesitant to talk about the practical benefits of a scheme optimized around such assumptions. If we do have batching or aggregation as a standard first, then I could see a much stronger path towards quantum-resistant addresses where those optimizations reinforce each other.

Extreme size, fast verification, fast signing.

This is what can be used only on second layers, like sidechains or LN. Because then, after being settled on-chain with a small, fast-to-verify signature, large data pushes from second layers can be entirely discarded, and stored only by interested parties.

I haven't considered the implications for LN or sidechains as we are generally focused on layer 1 issues first, but you make a good point. The tradeoffs change significantly when you move off-chain. A second layer protocol has much more freedom to optimize for different properties compared to the first layer.

So a reasonable balance between the factor must be had or it simply will not work at all.

Having #1 scheme on layer one, and #2 scheme on layer two seems to be good enough in case of emergency. And probably the first attacks, which will get closer to breaking things, will result in better solutions as well. Because if you know, what is attacked and how, then it is easier to be protected from that, just like it was with hardened SHA-1, which is entirely based on practical attacks, and doesn't block anything else than that.

I do wonder about the tradeoff of implementing different cryptographic schemes across different layers. On one hand, it definitely increases engineering complexity as multiple signature systems mean more code to maintain, more implementations to audit, more opportunities for interoperability issues and an overall larger burden on everyone who is working on wallets and infrastructure. We saw how long it took many systems to get bech32, even if the reasons for the upgrade in this case would be more urgent. On the other hand this would also reduce systemic risk -- if the entire ecosystem was standardized on a single PQ primitive and it later turns out to have a real weakness, the consequences would cascade across everything like dominoes.

I guess there is no perfect answer in this case either, we face yet another classic engineering tradeoff between simplicity and resilience.

Since Bitcoin does not yet have a quantum-secure address, it is clear that it does not require it at this time, and the quantum's that are available now are not yet powerful enough to break Bitcoin's encryption, and if it becomes so, I am confident that the developers will make an upgrade, because, and since awareness is everywhere, I do not believe things like this will be ignored. And other new cryptocurrencies are built with different cryptography when it becomes a concern, then it will not be ignored, that I know for sure.

Don't shitpost generic nonsense here, you won't earn merit this way.

[athanred]

we don't have batching or signature aggregation on Bitcoin

1. Schnorr signatures can be combined. And even if it cannot be expanded into quantum world, then things like 2P-ECDSA can be used, to expand existing output types. If it is possible to execute multisig on P2PK, then in a similar way, quantum signatures could be batched as well, where one signature would confirm multiple on-chain actions. Homomorphic encryption is a quite powerful tool, which lets you to compute things, without knowing the plaintext data you work on.
2. There are discussions about it, the name in use is CISA, Cross Input Signature Aggregation. See also this draft: https://github.com/fjahr/bips/blob/cf0d4f2142cd0504b16e86739167b1f7ab9a3a06/bip-XXXX.mediawiki

I do wonder about the tradeoff of implementing different cryptographic schemes across different layers.

Note that technically, it cannot be prevented. If you have some LN channel, then it is locked on some hash, or public key. A lot of contracts are possible, for example "if you send me some ALT, I will send you some satoshis". It is not a widely deployed use case of LN, but in practice, unlocking some LN transfer can trigger any action on any network, even if it uses different algorithms. More about fake channels: https://petertodd.org/2025/fake-channels-and-rgb-lightning

multiple signature systems mean more code to maintain

The first layer doesn't have to handle all LN complexity. It just checks consensus rules. All that it sees, is just related to opening and closing channels. But on the second layer, you can even use unsafe MD5, if you really want to, and the first layer doesn't have to know about it.

if the entire ecosystem was standardized on a single PQ primitive

It is very likely, that PQ signatures won't be used alone: you will have ECDSA+PQ, and both ways could be mixed. Because some quantum schemes were broken classically, so ECDSA will be probably required anyway, just to avoid that risk. And even if secp256k1 will be fully broken, then OP_CHECKSIG could still be useful, because s-values are based on SHA-256. Which means, that we won't see 9-byte DER signatures, even if all public keys could be broken instantly. To fully break OP_CHECKSIG, breaking both secp256k1 and SHA-256 is needed.

Also note, that even if nothing will be deployed, then some users will use custom scripts, to emulate "quantum resistance". And because of backward compatibility, disabling OP_CHECKSIG is not an option, because it is used way beyond just checking signatures, and even if the private key is known, then you cannot just take every coin, which uses OP_CHECKSIG, for example if it also uses OP_SIZE.