Feed for category: bips
PSBT (BIP 174) - Partially Signed Bitcoin Transactions

Multisig transactions 1 have been a great use case of Bitcoin for the past few years, they require unsigned or partially signed transactions to be passed between multiple parties to “co-sign” them. However, there is currently no unified format for how multiple parties may share these transactions between multiple signers, it depends on the particular implementation for each wallet making it hard to do among parties using different Bitcoin wallets.

A draft BIP (174), which was proposed last year by Andrew Chow, was recently a subject of interest among Bitcoin developers. It aims to create a standard extensible format that different clients can implement making Partially Signed Bitcoin Transactions (PSBT) easier to pass around users to sign and combine their signatures.

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

Updates to Dandelion Bip Proposal

A programmer and researcher, Brad Denby who’s team formerly proposed a BIP called Dandelion, published an update to the project.

We’re writing with an update on the Dandelion project. As a reminder, Dandelion is a practical, lightweight privacy solution that provides Bitcoin users formal anonymity guarantees. While other privacy solutions aim to protect individual users, Dandelion protects privacy by limiting the capability of adversaries to deanonymize the entire network.

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.
BIP Proposal P2sh and Version 0 Segwit Script Enforcement From Genesis

A BIP draft was submitted by Suhas Daftur on bitcoin-dev suggesting to backdate the P2SH and Segwit version 0 script rules back to the genesis block.

The Pay to Script Hash (P2SH, BIP 16) script rules and the Version 0 Witness Program script rules (BIP 143141) can be enforced from the genesis block with only one historical exception. Doing so simplifies consensus rules and allows protocol implementers to avoid writing and testing code paths that are no longer relevant.

Link to the BIP draft