About quantum computing, address reuse when you have 50+ addresses

[bitmover]

I have been thinking about address reuse and the quantum computer problem.

As far as I know, we are safe if we never expend from an address. Which becomes quite complicated if we handle dozens and dozens of addresses, and we reuse some of them (like giveaways, campaigns, and other recurring payments, etc).

I know there is a privacy risk about address reuse, but that is manageable if you handle UTXO with patience. The security is what bugs me now.

Until when do you guys think it is safe to keep reusing addresses like? I was thinking about creating a new wallet and sending all coins to a newly wallet, because my current wallet has like 50+ used addresses and change addresses with most of them already spent from... And I also use a Hardware wallet, which makes things a little slower to handle.

How do you guys manage so much addresses? I know this is the case for many "heavy" bitcoin users here, like me

[Kruw]

How do you guys manage so much addresses? I know this is the case for many "heavy" bitcoin users here, like me

Hierarchical deterministic wallets (BIP32) already solved this issue over a decade ago. You only have to make one backup that is able to generate an ~infinite amount of addresses.

An unused address doesn't stop your coins from being stolen by a quantum computer, it only temporarily delays it: Your coins will be stolen the moment you try to spend them.

[bitmover]

How do you guys manage so much addresses? I know this is the case for many "heavy" bitcoin users here, like me

Hierarchical deterministic wallets (BIP32) already solved this issue over a decade ago. You only have to make one backup that is able to generate an ~infinite amount of addresses.

Yeah, this a "solution", but that is quite unpratical to generate more and more addresses over the default of wallets.

 recovering a wallet using the seed isn't so simple all the times.

 You need to search different derivation paths (for example, ledger uses a different one than other wallets). Then you also need to look at different accounts, change addrrsses and also search for more addresses than the default (i think it is 50 addresses, which i already used).

But yeah  , this is probably the "solution"... just keep adding addresses..

I always try to reduce complexity in my setup, specially for heritage reasons

[Satofan44]

Until when do you guys think it is safe to keep reusing addresses like? I was thinking about creating a new wallet and sending all coins to a newly wallet, because my current wallet has like 50+ used addresses and change addresses with most of them already spent from... And I also use a Hardware wallet, which makes things a little slower to handle.

The main thing to do is to separate your main stash from everything else. As long as the main stash is tucked away safely on an address that you do not use then you already have secured 80-99% of your coins (depending on the distribution of balances in your own wallet). For the others, as long as the balances are kept to a small amount it is entirely safe. One must always think about these things in context.

Note 1: The quantum cracking of keys will be targeted, gradual and take time. It is not going to be the case that someone turns on a quantum computer tomorrow and all reused addresses are hacked instantly.
Note 2: There are much bigger targets, a very long list. Exchange addresses, satoshi's coin and other P2PK addresses and re-used addresses. Recent estimates put the amount of potentially vulnerable Bitcoin at 3-4 million (IIRC). Therefore your addresses would be near the end of a very long list of addresses.
Note 3: Perfectly safe for at least several more years, possibly longer.

recovering a wallet using the seed isn't so simple all the times.

 You need to search different derivation paths (for example, ledger uses a different one than other wallets). Then you also need to look at different accounts, change addrrsses and also search for more addresses than the default (i think it is 50 addresses, which i already used).

Always write down the derivation paths with the seed, that information does not hurt.

An unused address doesn't stop your coins from being stolen by a quantum computer, it only temporarily delays it: Your coins will be stolen the moment you try to spend them.

No they won't, this is again theoretical FUD nonsense that the quantum computers will be so fast that they will be breaking keys in real time. It is time to stop watching so many action movies, they are frying your brain from over consumption of content. Even if that were to happen, there will be countermeasures in place which will make the attack ineffective.

[Cookdata]

An unused address doesn't stop your coins from being stolen by a quantum computer, it only temporarily delays it: Your coins will be stolen the moment you try to spend them.

This is scary but it's not scary due to node policy spend.

We don't even know how fast the quantum computers can break the public key to a private key. Let's say at the course of sending transaction a quantum computer found a public key on the network and found the private key, he can't double spend a transaction that is already broadcasted to the network, the coin has to be drop from the mempool before the attacker will be able to spend the coin to another wallet address.

In this case, it's likely not possible to spend the coin if the coin remain in the mempool. If the transaction fee is reasonable, it wouldn't take time before confirmation.

[Satofan44]

This is scary but it's not scary due to node policy spend.

We don't even know how fast the quantum computers can break the public key to a private key. Let's say at the course of sending transaction a quantum computer found a public key on the network and found the private key, he can't double spend a transaction that is already broadcasted to the network, the coin has to be drop from the mempool before the attacker will be able to spend the coin to another wallet address.

In this case, it's likely not possible to spend the coin if the coin remain in the mempool. If the transaction fee is reasonable, it wouldn't take time before confirmation.

No. They can replace the transaction with RBF. Many transactions today have RBF enabled. Furthermore, there is no such thing as "The Mempool". Each node has its own mempool at they will often be different between nodes depending on many factors that are not necessary to be mentioned in this thread.

If keys can be really broken in real time and competing transaction end being submitted, then they can be broadcasted to the network and some nodes who don't yet have the original transaction transaction will definitely receive it. There is no reason for them to reject it. The other option is submitting it directly to a miner with a high fee-rate. It is definitely possible if breaking keys in real time becomes a thing, which it won't. Node policies are irrelevant to an attacker given the many number of ways in which you can get transactions submitted. In general node policies can't be designed in any way to provide meaningful protection from quantum attackers.

[satscraper]

I always try to reduce complexity in my setup, specially for heritage reasons

To reduce complexity you might want to consider using  BIP85 child SEED to create the wallet with "default" addresses for heritage purpose, while using your parent SEED to generate new addresses relevant to your routine wallet and automatically move the remaining funds there at the time of spending. To avoid cluttering the routine wallet you may also want to configure it to hide used addresses. I use this approach with Sparrow paired with Passport Core, dedicating one of the child SEEDs ^{generated by this HW} specifically to heritage wallet.

[EL MOHA]

This is scary but it's not scary due to node policy spend.

We don't even know how fast the quantum computers can break the public key to a private key. Let's say at the course of sending transaction a quantum computer found a public key on the network and found the private key, he can't double spend a transaction that is already broadcasted to the network, the coin has to be drop from the mempool before the attacker will be able to spend the coin to another wallet address.

In this case, it's likely not possible to spend the coin if the coin remain in the mempool. If the transaction fee is reasonable, it wouldn't take time before confirmation.

No. They can replace the transaction with RBF. Many transactions today have RBF enabled. Furthermore, there is no such thing as "The Mempool". Each node has its own mempool at they will often be different between nodes depending on many factors that are not necessary to be mentioned in this thread.

This is definitely true, and much easier even if a transaction wasn’t flagged RBF when broadcasted with all most all nodes having their node settings as Full RBF then all unconfirmed transaction can still be replaced by a new one regardless of the tag it has from first broadcast and if maybe the bad actor has the private key then they can simply replace the transaction and it will be replaced immediately by the nodes with Full RBF setting while those without the setting would get it replaced immediately it gets confirmed, that can only be an issue if only the node with full RBF setting actually mines the next block and includes the first transaction, then the replaced one will be invalid and this is usually a very rare case because definitely the replaced one which has higher fee rate would get picked first.

Another thing again could be if the bad actor actually got his hands on the receiving address private key then they would simply just do a CPFP

[BlackHatCoiner]

A quantum computer will probably not ever target an address with a low amount, and likely not an address with a very large amount either (like Binance's cold storage). They'll likely target Satoshi's keys first. Consider that we're not there yet, but more importantly: once we get there, we won't just wake up one day and a quantum computer will have run a function that emptied all public keys' balances. It'll probably take a very long time at first to break just one public key, so the attacker needs to be very careful with which key that is.

By the time a quantum computer can break public keys very quickly, I believe we will have found consensus to a quantum-safe fork. I think the safest option at the moment, is to see a quantum computer actually breaking one key in practice, so that everyone is convinced of the danger.

[d5000]

If keys can be really broken in real time and competing transaction end being submitted, then they can be broadcasted to the network and some nodes who don't yet have the original transaction transaction will definitely receive it. There is no reason for them to reject it. The other option is submitting it directly to a miner with a high fee-rate. It is definitely possible if breaking keys in real time becomes a thing, which it won't.

There would be a much better method to secure your funds in this unlikely event: the recovery method proposed by Tadge Dryja. It needs a soft fork but in this situation it would be very likely approved.

Basically, before you transmit the tx from the vulnerable ECDSA address, you'd have to submit (using a quantum-proof method like FALCON or SPHINCS+) a transaction containing nothing more than an OP_RETURN output with the txid of the transaction (or another proof that you know the private key, like a signature). Then you submit the transaction in a second step, sending the funds to a quantum resistant address. Only transactions from ECDSA addresses where the "TXID transaction" can be detected before would be accepted by the Bitcoin protocol.

This means that even for the worst case scenario there's a way to recover the coins. Not reused addresses are always safe from quantum computing (if there are no completely shocking new developments in this area).

[bitmover]

[The other option is submitting it directly to a miner with a high fee-rate. It is definitely possible if breaking keys in real time becomes a thing, which it won't. Node policies are irrelevant to an attacker given the many number of ways in which you can get transactions submitted. In general node policies can't be designed in any way to provide meaningful protection from quantum attackers.

I think this is point here.

Breaking keys with quantum computers wont be something so easy and fast to do.

Only addresses with lots of funds should be targeted, and certainly i wont be one of them.. if such scenario ever happens.

[Satofan44]

There would be a much better method to secure your funds in this unlikely event: the recovery method proposed by Tadge Dryja. It needs a soft fork but in this situation it would be very likely approved.

Basically, before you transmit the tx from the vulnerable ECDSA address, you'd have to submit (using a quantum-proof method like FALCON or SPHINCS+) a transaction containing nothing more than an OP_RETURN output with the txid of the transaction (or another proof that you know the private key, like a signature). Then you submit the transaction in a second step, sending the funds to a quantum resistant address. Only transactions from ECDSA addresses where the "TXID transaction" can be detected before would be accepted by the Bitcoin protocol.

This means that even for the worst case scenario there's a way to recover the coins. Not reused addresses are always safe from quantum computing (if there are no completely shocking new developments in this area).

Absolutely, and I kinda expected you to talk about this solution in case you responded here.   I was just giving the easy/dumb method in case a big breakthrough catches us by surprise. The one that you have explained here is much better but it needs much more preparatory work than a direct-submission-to-miners solution (some already offer this service). I do think that we should deploy some measures nevertheless, even if they are not optimal as of today. It is better to have some inefficient options ready than to have nothing at all just in case.

I think this is point here.

Breaking keys with quantum computers wont be something so easy and fast to do.

Only addresses with lots of funds should be targeted, and certainly i wont be one of them.. if such scenario ever happens.

A lot of people fail to think in a nuanced way, it seems to me that this is an extremely rare ability these days. This is why they fall for FUD. Even under the worst scenario are quantum computers unable to kill Bitcoin. Sure they can cause plenty of market chaos, but market chaos can be caused by anything. One should be used to these things. As with everything, once Bitcoin survives quantum computers it will only become much stronger than it was.

[The Cryptovator]

Are you really afraid of quantum computers? And do you think using a fresh address would prevent you from being compromised through quantum computers? I don't think so, because once you receive the funds into your address, it means your address will be marked as a used address. Until you use your fresh address, it won't appear in the blockchain as a used address. This means you will never have funds into an unused address, and all the used addresses will be treated the same way like a bulk hack.

Unused or fresh addresses, I will call them new addresses. So that address would only help you to protect your privacy, because a new address is unknown. Only the sender may know it if he knows you. To reduce the quantum risk, you may use a separate address, whether it's new or used. It would delay the hacking process, but still, if the quantum becomes true, we aren't safe anyway. First targets will be whales, then everyone and each. But I have faith that at least it will happen in the next decade; in the meantime, Bitcoin developers will find solutions; they either need a hard fork or something else. There might be a stronger wallet system that would counter the quantum computing system.

[bitmover]

don't think so, because once you receive the funds into your address, it means your address will be marked as a used address.

Only when spending funds from an address that its public key is exposed. Just by receiving funds your public key isn't exposed, so the address is still "fresh" and safe from this possible risk of quantum computers.

[Satofan44]

Only when spending funds from an address that its public key is exposed. Just by receiving funds your public key isn't exposed, so the address is still "fresh" and safe from this possible risk of quantum computers.

This is correct, I have already explained this here or in many other topics. There is no need to go over this basic knowledge each time. Anyway, he just wrote a completely generic shitpost where every single sentence is wrong. Put him on ignore, give him a neutral tag (since DT pajeets will complain if you give him a negative) and move on. Don't respond seriously to such idiots as the fallacies in their posts are very often already explained in the very thread that they are responding to. It shows that they don't read anything at all. Quoting or responding to a small and targeted part of a post is a tactic of pretending that you've read something.

don't think so, because once you receive the funds into your address, it means your address will be marked as a used address.

Real science has no room for opinions only for the truth, so fuck off back to where you came from. You don't know anything about this subject.

[Ambatman]

I have been thinking about address reuse and the quantum computer problem.

As far as I know, we are safe if we never expend from an address. Which becomes quite complicated if we handle dozens and dozens of addresses, and we reuse some of them (like giveaways, campaigns, and other recurring payments, etc).

I know there is a privacy risk about address reuse, but that is manageable if you handle UTXO with patience. The security is what bugs me now.

Until when do you guys think it is safe to keep reusing addresses like? I was thinking about creating a new wallet and sending all coins to a newly wallet, because my current wallet has like 50+ used addresses and change addresses with most of them already spent from..

I'm assuming you are going to move this coins with privacy in mind
And won't consolidate all UTXOs together cause that would beat the essence of owning such numbers of address.

First targets will be whales, then everyone and each. But I have faith that at least it will happen in the next decade

It amazes me how many people just believe that when a quantum computer that can pose a threat is made
Bitcoin would be their first target. Who even started the narrative.

[The Cryptovator]

don't think so, because once you receive the funds into your address, it means your address will be marked as a used address.

Only when spending funds from an address that its public key is exposed. Just by receiving funds your public key isn't exposed, so the address is still "fresh" and safe from this possible risk of quantum computers.

I got you; thanks for letting me know. But actually I had been talking about the address, not about the public keys. You were concerned regarding using or reusing the address, not the public keys. So my reply was about the address as well. And yes, if you consider it this way, then the receiving address remains fresh when it comes to public keys matter.

We still don't know the power of quantum computers; if they could calculate public keys from the address and from the public keys to private keys, then the threat still exists. Hope something will not happen and Bitcoin will exist, but developers need to start working on how to secure the Bitcoin Blockchain.

[LoyceV]

How do you guys manage so much addresses?

Why would handling many addresses be a problem? My wallet takes get of that. I must have used hundreds of addresses over the years, and most of them are empty now.

For recurring (signature) campaigns, Silent Payments could be a solution to avoid address reuse, but I think it's too complicated to use. That's probably why I haven't seen any campaign that uses it.

Yeah, this a "solution", but that is quite unpratical to generate more and more addresses over the default of wallets.

Again: why? I think Bitcoin Core's default "address gap" is 1000 addresses, and I don't think you'll be handing out that many addresses before any of them receives a payment.
For Electrum, it's easy to raise the gap limit, but again: how likely is it to hand out 25 addresses that aren't used?

recovering a wallet using the seed isn't so simple all the times.

If you used thousands of addresses, Electrum will become slow to sync and may even get stuck. But for any "normal" use, I've never ran into this problem.

You need to search different derivation paths (for example, ledger uses a different one than other wallets). Then you also need to look at different accounts, change addrrsses and also search for more addresses than the default (i think it is 50 addresses, which i already used).

Is this problem a hardware wallet thing? I know both Ledger and Trezor have terrible software that doesn't just let you create more addresses without using the first one, but I don't use their software. If you use Electrum with your hardware wallet, this problem doesn't exist.

I actually prefer using different addresses for everything: It's so much easier to know what a payment is for, if each address has a unique Label.

[ABCbits]

--snip--
We still don't know the power of quantum computers; if they could calculate public keys from the address and from the public keys to private keys, then the threat still exists. Hope something will not happen and Bitcoin will exist, but developers need to start working on how to secure the Bitcoin Blockchain.

Even with Quantum Computer and Grover's algorithm. SHA-256 (that typically used to generate Bitcoin address) only got weakened from 2^256 to 2^128 towards brute-force attack.