These are just my notes on an experiment with ElectrumSV where we stopped monitoring addresses after they were used once, and then the balance present was spent.This experiment is now over, and until the highlighted problems are addressed we will be continuing to monitor all of the wallet addresses.

TLDR; There’s a lot of ground work involved in doing what we want to do, and need to do, and discouraging address reuse is no exception. We’ve learnt a lot, and reinforced some things we already knew, and we’re not ready for it yet.

Comments below! Or on the most excellent Metanet.ICU slack, or the equally excellent in different ways Unwriter’s slack.

Edge cases

Local transactions

What do I mean by resources? This is the selected addresses where the unspent part of the utxos used in the transaction, are sent back to your wallet — the change addresses. This includes what utxos are selected to be spent in the transaction. The former opens a door for address reuse, and the latter opens a door for double-spending.

Electrum, the original BTC wallet that ElectrumSV is derived from, since ElectrumSV branched off has introduced the concept of local transactions, and provides a much more resilient and user-friendly wallet using them. ElectrumSV needs to bring forward our own implementation of local transactions, as a prerequisite of our path forward discouraging address reuse.

Local transactions go beyond just the transactions you’ve sent to the network and that haven’t passed through the P2P network yet, there are many other specialised uses that might have the same requirements.

Marked addresses

One of the approaches we were planning to consider a prerequisite for including the dynamic address monitoring in a release, was support to allow those who did have address reuse to specifically mark addresses to always be monitored as long as they were marked.

Address scanning

The uses for address scanning go beyond just ensuring that users do not miss payments, ElectrumSV can use them to enhance the wallet experience. One situation where this might be useful is scanning ahead and looking at addresses the wallet does not think has been used yet. The way BIP32/BIP44 wallets work is that they do not monitor all your future possible addresses ad infinitum, they just monitor a specific amount of them past the end of the last address in the sequence which is known to be used. For change addresses, we monitor maybe 5 or 6 in ElectrumSV. And for receiving addresses, we monitor 20 in ElectrumSV. These are call gap limits.

One benefit is where we have to deal with keys that were imported from other wallet applications. If we know the key was imported from a wallet that does not have reliable gap limits between used addresses, then we really want to be scanning ahead and ensuring that we have synchronised the full wallet contents. If we don’t then the problems are obvious, we do not know that we won’t be reusing addresses and we do not know that we won’t be double-spending.

On a related note, I used to believe we should support importing these keys from other wallets and let people continue to use them in ElectrumSV. But these days I lean towards thinking this is a bad idea, and only creates future problems. That perhaps it is better to let them be imported, and examined, and perhaps sent to another wallet.


Final thoughts

ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store