Re: Should wallets warn if you re-use addresses due to quantum computers?
Yes, we are. But P2TR can be spend by key, or by TapScript. Spending by key can be blocked in the future, if needed, and then, quantum-safe paths will be executed inside TapScript.
Sorry for the "intrusion", I have just asked about this in another thread, and this would answer my question 
-- do you know links with info about that possible "blocking" of P2TR key-paths?What I have seen is this passage in Bitcoin Optech, is this what you're referring to?
Quote from: https://bitcoinops.org/en/preparing-for-taproot/
Voided keypaths: some users may want to prevent usage of keypath spending in order to force scriptpath spending. That can be done now by using an unspendable key as the first parameter to tr(), but it’d be nice to allow wallets to store this preference in the descriptor itself and have it compute a privacy-preserving unspendable keypath.
Quote
Multisignature helps but is that all that we have on the table right now?
No, Proof of Work can be used, too. But I guess not everyone wants to be a miner, and using optional Proof of Work to limit double-spending ability of some third parties also comes with a cost of grinding transaction hashes, which is huge, if there are many inputs and outputs.
If you do find it, please share it here.
Ok Imagine this. All your wealth is in a single bank vault, the best bank vault that you could make. Every time you need some extra money in your wallet, you move all your wealth to another bank and take some money for yourself. Doing this each time creates a huge surface for human error and security compromise.
I believe it could be done in a way these movements can be minimized (e.g. once per week or so, using good prediction algorithms about the hot wallet's needs for coins) and in that case the security threat wouldn't be that high. In addition, they could simply use different addresses from a HD wallet with the same seed, to minimize the costs of the storage of the access data. Of course the opinion of an exchange/service operator would be cool here as I'm talking from a layman perspective.Off topic, but what is it that it is missing for you compared to Electrum?
The main feature I'm missing at Electrum (and Sparrow doesn't provide either) is support of an alternative and less privacy-intrusive balance querying mechanism like BIP-157 (Neutrino) without the need of an own full node, or alternatively the possibilty to group addresses into sub-wallets as written in this thread. I've unfortunately realized it isn't as easy as I've depicted it in that thread (it's still relatively easy but not a thing of a few lines in the code like I initially supposed).