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

ElectrumSV currently has no way of tracking resource allocation. This means that you can create transaction, but until it arrives back from the node you are connected to (albeit indirectly), ElectrumSV might just reuse those resources.

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

We can’t just stop monitoring used addresses, we know that. We need to support historical use of wallets, including both past and possible future address reuse. We’ll be making this difficult to do in ElectrumSV, but we still have to deal with keys imported from other wallet applications, which still might facilitate it. Future reuse support can just piggyback on the support we add for past reuse.

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

Marking addresses is nice for people to know that they will continue to receive incoming transactions related to those addresses, but it’s not enough. We need to allow users to re-scan their addresses and detect any unexpected usage of them.

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.

Reorgs

If we get a reorg, we need to resubscribe addresses based on how the wallet changes. And this also relates to local transaction support, which is where it gets even more complicated. This was another incomplete part of our address reuse experiment, that needed to be addressed before we could release it.

Final thoughts

This has been a useful experiment, and has helped me prioritise what we need to do for the 1.3 release of ElectrumSV. Address reuse and local transactions will not be making it in, but we’re now in a better place to consider our roadmap and what needs to be placed in what order in the milestones required to get there.

Written by

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