The newest/last active keychain is the default. Almost all of this class only works on the default active keychain.
All other active keychains are meant as fallback for if a sender doesn't understand a certain new script type.
New P2WPKH KeyChainGroups are created with a P2PKH fallback chain. This will likely go away in future as P2WPKH
and Bech32 are becoming the norm.
The was likely the remains of lazy creation of wallets. Lazy creation wasn't of much use,
since wallets are usually accessed the moment after they're created. And also we introduced
a second "laziness" by only deriving a couple of keys per chain, deferring the hard work
for when bloom filtering is used.
It never worked for encrypted wallets anyways, and encrypted wallets should be
the the norm. Use Wallet.isDeterministicUpgradeRequired() to find out if your
wallet should be upgraded and invoke Wallet.upgradeToDeterministic() when the
time is right.
Use Builder.lookaheadSize() and Builder.lookaheadThreshold() if you want to change the defaults, or
manage lookahead on DeterministicKeyChains directly.
- Hierarchical-deterministic derivation of native segwit addresses.
- Receive payments to native segwit addresses.
- Spend and sign payments from native segwit addresses.
- Watch-only wallets with native segwit addresses (zpub/vpub).
- WalletAppKit, Wallet-tool and Wallet-template are taught to deal with segwit-enabled wallets.
Be aware this adds a new field in the wallet protobuf: output_script_type in Key, which keeps track
of the script type of DeterministicKeyChains. Protobufs will be migrated; old DeterministicKeyChains
are assumed to be of type P2PKH.
Includes some code by Fabrice Drouin.
Currently progress() can be called after doneDownload() which should not
happen. Also make sure that we call progress() with 100% progress before we
call doneDownload() - this is in case any existing users have given up on
downDownload() being called at the right time and instead use 100% progress
as their signal that downloading is complete.
Reasons:
- The implementation was bugged, because it overwrites the server filter with an outdated (not
updated according to NODE_UPDATE_* flags) filter, potentially causing missing transactions.
- Refreshing a filter in-flight has privacy issues.
- According to the comment it isn't even needed any more, due to false positive rate tracking.