0.7.0-rc.1 Custom account depth cause wallet to have higher gap than what bip32 suggests

[chikeichan]

Error case:

• user's actual wallet depth is 50
• user import wallet and set depth to 1000
• user's wallet have 950 unuse address

Note:
Custom account depth was created to circumvent this issue.

In order to fix the issue above in 0.7.0-rc.2:

• remove custom account depth as a feature
• provide a way for user's whose wallet was affected by the problem above to adjust account depth so that they can import again
• find ways to allow import of wallet's with high wallet depth without soft fork, or wait for this issue to be fixed, whichever comes first

[chikeichan]

summarizing discussion with @pinheadmz :

• in order to ensure portability to other wallet, we need to look for ways to fill gaps in account with tx
• non-standard wallet operations should be provided as a script to prevent regular users from accidentally running the script
• wallets with non-standard lookahead (>20) should use one tx to fill every 20th index in the account gap, that way rescan can operate normally in all wallets (e.g. future ledger and trezor)

[pinheadmz]

Just to chime in, filling bip44 gaps by sending small amounts to every 20th address may result in a user's wallet being full of dust outputs, or so many small UTXOs that they need to reconsolidate again anyway to make transactions in the future.

On telegram I suggested sending all recovered assets in a single tx to the last address before the first big bip44 gap. This would ensure standard bip44 recovery even though there would be wallet history missing. If the user ever "naturally" used all 950 addresses (from your example) then the history would be recovered, but the balance impact would be negligible because assets received at the high index have already been transferred to the low index.

Another thought that is perhaps a combination of your and my approach: instead of sending tiny coins to every 20th address - perhaps the recovery script can CHAIN THOSE TOGETHER. So -- grab a big coin like 100 HNS and send it to address 20, then spend that output to address 40, then spend that output to address 60, and so on. These transactions wouldn't even need change outputs just 1-in, 1-out until the gap is filled.

The wallet will not be flooded with small coins and the bip44 recover ability will still be intact. The problem with this may be a bunch of wasted TX fees but I still kinda like the end result a bit better.