Proposal: Automaticaly advance address pool index

[davecgh]

I have previously discussed this in IRC, but I thought it would be best to get it written into an issue.

Currently, it really isn't feasible to run multiple wallets on the same seed, such as in the case of when you'd want to have redundancy for a voting wallet. The reason for this is basically the following:

Wallet A: Current Address Index 17
Wallet B: Current Address Index 13

In this scenario, Wallet B doesn't know about the addresses for indexes 14, 15, and 16 and so the balance of the two wallets won't match. Even worse, if you request new addresses from Wallet B in order to advance the index, it still won't see transactions involving those addresses before the current block height, because from its point of view, those addresses are just now coming into existence. This pretty much always leads to the two wallets getting out of sync, trying to double spend coins, etc.

So, in order to resolve this situation, I propose that the wallet should detect when one of the addresses it is watching has a transaction involving it and automatically advance the current address index to the index after the one that was detected as well as advance the pool of watched addresses to include all additional deterministic addresses after that address plus the gap limit. This would greatly help the multi-wallet scenario since it means that all wallets could detect when a newer address has been generated via another wallet and received funds and automatically sync itself.

In order to visualize this, consider the following:

* Assumes a gap limit of 20
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
                             ^                                                           ^
                             |                                                           |
                   current address index                                pool address index

In the diagram, we can see that the current address index is 13, but the pool address index, that is to say the pool of upcoming addresses that are monitored, is 33 (13 + a gap limit of 20). This would mean that a call to getnewaddress would return the address associated with index 13 and advance the current address index to 14. It would also automatically advance the pool address index to 34 and start watching for transactions involving the new address. As a diagram this means:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
                                ^                                                           ^
                                |                                                           |
                      current address index                                pool address index

Now, let's assume, as in the original example, a second wallet happened to give out some new addresses and is at address index 17 and a new payment came into address 17. The first wallet should detect this payment to index 17 (because it's watching up to 33) and automatically advance the current address index to 18 and the pool address index to 38. Just as before, all new address should be added to the addresses which are being watched for transactions which involve them. Additionally, because it's an address that is after the current address index, it should rescan for transactions involving address indexes 14-38 starting from the block height associated with the last used address (address index 13). The process should repeat for any newer ones found used during the rescan too. As a diagram:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
                                 *  *  *  * ^*  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  * ^*
                                            |                                                           |
                                  current address index                                pool address index

* Rescan these addresses starting from the block height associated with index 13

The result, of course, is that whenever addresses are used, all wallets would automatically adjust their current address index to match each other and rescan for any transactions that happened involving those addresses. This would effectively help keep things in sync for the vast majority of cases and pretty much solve the issues with running multiple wallet instances on the same seed.

I should note however that obviously this approach can't completely stop address reuse since you could request a new address from two different wallets before receiving funds and they would both give out the same address. However, I think this is minor compared to the current issue where it is guaranteed that multiple wallets will get out of sync and result in attempts to double spend, different balances, etc.