Currently, the keychain package (responsible for generating public and private keys used throughout the ln processes) is implemented by generating accounts and addresses directly in the underlying wallet.
This has the following drawbacks:
Forces the creation of several accounts that might become visible for other wallet software
If using alongside a regular wallet, accounts might get a lot of generated addresses built for them without ever seeing a transaction
The vast majority of these addresses (pretty much all of them) are never published on chain
Most of the keys/addresses are further tweaked before being used in the ln processes (meaning the current wallet software cannot even in principle know about them)
Most of the keys/addresses are used in scripts the wallet doesn't understand and therefore is unable to use for anything
The wallet ends up tracking this enormous amount of addresses that are essentially useless (for its regular onchain operation) with associated memory and processing consequences
In the upstream lnd, this was solved by using a separate HD branch with a different purpose value and implementing a mechanism in the underlying btcwallet (KeyScope) to allow usage of branches with a purpose other than the default 44'.
While some feature to allow different purpose branches isn't available in dcrwallet, an alternative approach is to use a single account masterpub to derive all dcrlnd-specific keys. Done correctly, this can ease switching to a different root purpose key in the future.
This means dcrlnd will have to track the indexes of used keys itself instead of relying on the underlying wallet, but this seems reasonable given that pretty much all the functionality associated with addresses and accounts is useless for the off-chain side anyway.
The wallet will be able to handle arbitrary xpubs in the future (and possibly individually unlocked accounts) so there may be other options for this, but for now we can close this.
Currently, the
keychain
package (responsible for generating public and private keys used throughout the ln processes) is implemented by generating accounts and addresses directly in the underlying wallet.This has the following drawbacks:
In the upstream lnd, this was solved by using a separate HD branch with a different
purpose
value and implementing a mechanism in the underlying btcwallet (KeyScope
) to allow usage of branches with a purpose other than the default44'
.While some feature to allow different purpose branches isn't available in dcrwallet, an alternative approach is to use a single account masterpub to derive all dcrlnd-specific keys. Done correctly, this can ease switching to a different root purpose key in the future.
This means dcrlnd will have to track the indexes of used keys itself instead of relying on the underlying wallet, but this seems reasonable given that pretty much all the functionality associated with addresses and accounts is useless for the off-chain side anyway.