Does key derivation make (or help to make) Bitcoin "quantum safe"?

Question

We have these two other questions that touch on the same subject of how safe is Bitcoin from quantum computing attacks, but I believe mine is specific enough to be a separate question:

• What effects would a scalable Quantum Computer have on Bitcoin?
• How vulnerable is bitcoin to quantum algorithms?

The accepted answer in the older question above states that "ECDSA is compromised, but hashing isn't", so therefore, by simply knowing the address an attacker could not "calculate" back the private key necessary to spend the BTC, but after creating a transaction and spending the BTC, the public key becomes known by the network and therefore and attacker could "calculate" the private key and all the UTXOs of that address would become compromised.

I was wondering if using one address per transaction would mitigate this problem, since apparently key-derivation functions (bcrypt, Scrypt, Argon2) are basically quantum-safe. My reasoning is that from your "master" private key, you'd derive a new one and from this one you'd generate the public key which finally generates the address, and then when this address spends any UTXO and consequently tells its public key to the network, an attacker would only be able to get the derived private key, but never the "master" one, meaning in the end the user is relatively safe as long as they don't reuse the same address and keep on generating one address each time they want to receive a UTXO.

Is the reasoning above correct? Or maybe at least partially correct?

Answer 1

I was wondering if using one address per transaction would mitigate this problem

No, because the public key is revealed at spending time still, even if you never reuse addresses. The time between broadcasting the spending transaction and it being sufficiently buried on-chain still exposes the user to risk if hypothetical machines that can compute the discrete logarithm exist. Since we're talking about hypothetical hardware, you can't make any assumptions about how fast it would work.

Furthermore, lots of use cases of Bitcoin involve sharing public keys with other not-fully-trusted parties. For example, multisig wallets require public keys to be shared between the participants. Lightweight clients reveal public keys to the servers that help them track their balance. Lightning channels involve shared node public keys and channel public keys on the network. In the presence of hypothetical hardware that can compute private keys, Bitcoin as it is used today would pretty much stop existing, as all these use cases disappear.

Lastly, even if you yourself manage to carefully avoid all these scenarios that involve sharing of public keys, and we somehow assume that transactions in flight don't pose a risk, you have to consider that an enormous amount of BTC is currently held in addresses for which the public keys are known, even if not your funds. In the presence of a hypothetical EC breaking machine, so many funds would become exposed that I cannot imagine BTC maintaining much value.

I was wondering if using one address per transaction would mitigate this problem, since apparently key-derivation functions (bcrypt, Scrypt, Argon2) are basically quantum-safe. My reasoning is that from your "master" private key, you'd derive a new one and from this one you'd generate the public key which finally generates the address, and then when this address spends any UTXO and consequently tells its public key to the network, an attacker would only be able to get the derived private key, but never the "master" one, meaning in the end the user is relatively safe as long as they don't reuse the same address and keep on generating one address each time they want to receive a UTXO.

Yes and no.

• Master private keys that deterministically generate the actual address keys are used ubiquitously in Bitcoin, precisely because it permits using a new address for every transaction without needing a backup of each individual key. The reason is not security, but privacy however; reuse of addresses gratuitously reveals information about shared ownership of UTXOs on chain.
• In theory, key derivation mechanisms do exist that are quantum-secure (or could be), in the sense that an attacker who learns (through whatever means) the private key to an address cannot learn the master key it was generated from. The common key derivation mechanism used in Bitcoin (BIP32) does not use such techniques however, because it's incompatible with xpubs. The (unhardened) BIP32 method supports sharing a master public key with another party (corresponding to your master private key which is never revealed), in such a way that those other parties can derive the public keys corresponding to the private keys you will derive. This enables watch-only wallets that can track funds on an online machine, while the private keys remain safe on an offline one.
• All the arguments above still apply: even if attackers are prevented from computing the master private key from an address private key, it doesn't stop them from computing address private keys from public keys.

ECDSA, and other forms of EC-based cryptography are inherently not quantum-secure. It's enticing to think about ways to cover up this property or somehow reduce its impact, but it doesn't change the fact that the cryptography inherently just isn't designed for that. If we want post-quantum secure Bitcoin, we need to switch to actual cryptography designed for that, which is very actively being researched. I personally believe it is too early to push for that practically, as existing schemes today are very novel, are frequently broken still, and come with huge downsides (mostly size of keys or signatures), but given how rapidly the field is progressing I'm confident those concerns will reduce over time.