Extended private keys are defined in
BIP321 and are
used to recover funds in case of a loss, but recovering a wallet using just the
extended private keys is a tricky process and can sometimes fail to recover all
the funds as some metadata can be missing. The current implemenation also has a
weakness in which there is a limit to the incoming payment requests, handing
out more than
20 incoming payment requests could lead to destruction of funds.
To remedy this issue, an early draft of a new serialization/encoding format for extended public and private keys was proposed on the Bitcoin-dev channel.
Decentralizing mining doesn’t always take the form of an algorithm change.
We propose two new mining protocols to rethink the way in which work is generated in the Bitcoin network, potentially drastically increasing effective mining decentralization.
Matt Corallo via Bitcoin-dev:
BIP 158 currently includes the following in the “basic” filter: 1) txids, 2) output scripts, 3) input prevouts.
I believe (1) could be skipped entirely - there is almost no reason why you’d not be able to filter for, eg, the set of output scripts in a transaction you know about and (2) and (3) may want to be split out - many wallets may wish to just find transactions paying to them, as transactions spending from their outputs should generally be things they’ve created.
BIP 158 is a protocol that extends BIP 157. It is a structure of “compact filters on block data” that replaces bloom filters. The purpose of such a system is to enable users who run light Bitcoin clients to verify transactions dealing specifically with their wallets. The issues at hand are juggling efficiency with security (ie. verifying honest nodes and detecting dishonest nodes).
Jim Posen proposed the following BIP (Bitcoin Improvement Protocol) via Bitcoin developer mail:
I have been working on a P2P extension that will allow faster header sync mechanisms. The one-sentence summary is that by encoding headers more efficiently (eg. omitting prev_hash) and downloading evenly spaced checkpoints throughout history (say every 1,000th) from all peers first, we could speed up header sync, which would be a huge improvement for light clients.
According to Posen, the “proposed header download protocol reduces bandwidth usage by [approximately] 40%-50% and supports downloading… from multiple peers in parallel”. Currently parallel header synchronization is not supported. Such an improvement could be advantageous during periods of high technical adoption, which could occur as increasingly stable versions of Lighting Network daemons are released.
An adjustment to BIP 125 was suggested by Rhavar on bitcoin-dev.
Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.