Feed for tag: bips
The Great Consensus Cleanup
The great consensus cleanup is a new BIP suggested by developer Matt Corallo to address different issues in the current Bitcoin consensus, the new set of consensus changes aim at reducing complexity of Bitcoin implementations, improving worst-case validation times and fixing vulnerabilities like timewarp.
BIP Proposal: New Serialization Format for Key Material

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.

BIP-158: Flexibility and Filter Size for Light Bitcoin Clients

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).

Core Devs to Optimize Header Synchronization

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.

BIP 157 & 158: Block Filtering
A new BIP was suggested to improve the efficiency of light client protocols in Bitcoin, instead of the current BIP 37’s light client protocol that has flaws such as allowing denial-of-service attack vectors on full nodes, the new protocol allows light clients to obtain compact probabilistic filters of block content from full nodes and only download a block if the filter matches the relevant data.