BIPs bitcoin improvement proposals

147 - Dealing with dummy stack element malleability

<pre> BIP: 147 Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0147 Status: Final Type: Standards Track Created: 2016-09-02 License: PD </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code>. ==Motivation== Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the <code>txid</code> and invalidate any unconfirmed child transactions. Although the <code>txid</code> of segregated witness ([https://github.com/bitcoin/bips/b...

142 - Address Format for Segregated Witness

<pre> BIP: 142 Layer: Applications Title: Address Format for Segregated Witness Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0142 Status: Withdrawn Type: Standards Track Created: 2015-12-24 License: PD </pre> == Abstract == This BIP describes new types of Bitcoin address to support native segregated witness transactions with 20-byte and 32-byte program. == Motivation == To define standard payment address for native segregated witness (segwit) transactions to promote early adoption of the more efficient transaction method. == Specification == The new Bitcoin address format defined is for the Pay-to-Witness-Public-Key-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) transaction described in segregated witness soft fork (BIP141). The scriptPubKey is an OP_0 followed by a push of 20-byte-hash (P2WPKH) or 32-byte hash (P2WSH). The new address is encoded in a way similar t...

114 - Merkelized Abstract Syntax Tree

<pre> BIP: 114 Layer: Consensus (soft fork) Title: Merkelized Abstract Syntax Tree Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0114 Status: Rejected Type: Standards Track Created: 2016-04-02 License: PD </pre> ==Abstract== This BIP defines a new witness program type that uses a Merkle tree to encode mutually exclusive branches in a script. This enables complicated redemption conditions that are currently not possible, improves privacy by hiding unexecuted scripts, and allows inclusion of non-consensus enforced data with very low or no additional cost. ==Motivation== ===Evolution of Bitcoin script system=== Bitcoin uses a script system to specify the conditions for redemption of transaction outputs. In its original design, the conditions for redemption are directly recorded in the scriptPubKey by the sender of the funds. This model has several drawbacks, particularly for comp...

146 - Dealing with signature encoding malleability

<pre> BIP: 146 Layer: Consensus (soft fork) Title: Dealing with signature encoding malleability Author: Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0146 Status: Withdrawn Type: Standards Track Created: 2016-08-16 License: PD </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability related to ECDSA signature encoding. ==Motivation== Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the <code>txid</code> and invalidate any unconfirmed child transactions. Although the <code>txid</code> of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141...

143 - Transaction Signature Verification for Version 0 Witness Program

<pre> BIP: 143 Layer: Consensus (soft fork) Title: Transaction Signature Verification for Version 0 Witness Program Author: Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0143 Status: Final Type: Standards Track Created: 2016-01-03 License: PD </pre> == Abstract == This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature. == Motivation == There are 4 ECDSA signature verification codes in the original Bitcoin script system: <code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, <code>CHECKMULTISIG</code>, <code>CHECKMULTISIGVERIFY</code> (“sigops”). According to the sighash type (<code>ALL</code>, <code>NONE</code>, <code>SINGLE</code>, <code>ANYONECANPAY</code>), a transaction d...

141 - Segregated Witness (Consensus layer)

<pre> BIP: 141 Layer: Consensus (soft fork) Title: Segregated Witness (Consensus layer) Author: Eric Lombrozo <elombrozo@gmail.com> Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0141 Status: Final Type: Standards Track Created: 2015-12-21 License: PD </pre> ==Abstract== This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure. The witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible. A future hard fork can place this tree in its own branch. ==Motivation== ...