BIPs bitcoin improvement proposals

78 - A Simple Payjoin Proposal

<pre> BIP: 78 Layer: Applications Title: A Simple Payjoin Proposal Author: Nicolas Dorier <nicolas.dorier@gmail.com> Replaces: 79 Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0078 Status: Draft Type: Standards Track Created: 2019-05-01 License: BSD-2-Clause </pre> ==Introduction== ===Abstract=== This document proposes a protocol for two parties to negotiate a coinjoin transaction during a payment between them. ===Copyright=== This BIP is licensed under the 2-clause BSD license. ===Motivation=== When two parties (later referred to as sender and receiver) want to transact, most of the time, the sender creates a transaction spending their own Unspent Transaction Outputs (UTXOs), signs it and broadcasts it on the network. This simple model gave birth to several heuristics impacting the privacy of the parties and of the network as a whole. * Common input ownership heuristic: In most transactions, all the in...

68 - Relative lock-time using consensus-enforced sequence numbers

<pre> BIP: 68 Layer: Consensus (soft fork) Title: Relative lock-time using consensus-enforced sequence numbers Author: Mark Friedenbach <mark@friedenbach.org> BtcDrak <btcdrak@gmail.com> Nicolas Dorier <nicolas.dorier@gmail.com> kinoshitajona <kinoshitajona@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0068 Status: Final Type: Standards Track Created: 2015-05-28 </pre> ==Abstract== This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint. ==Motivation== Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly imple...

90 - Buried Deployments

<pre> BIP: 90 Title: Buried Deployments Author: Suhas Daftuar <sdaftuar@chaincode.com> Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Final Type: Informational Created: 2016-11-08 License: PD </pre> ==Abstract== Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. ==Motivation== BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block version (N) in use on the network, and those rules became enforced under the...

123 - BIP Classification

<pre> BIP: 123 Title: BIP Classification Author: Eric Lombrozo <elombrozo@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 Status: Active Type: Process Created: 2015-08-26 License: CC0-1.0 GNU-All-Permissive </pre> ==Abstract== This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. ==Copyright== This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. ==Motivation== Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them. ...