dido:public:ra:xapend:xapend.b_stds:defact:bitcoin:bips:bip_0141
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.b_stds:defact:bitcoin:bips:bip_0141 [2020/05/07 18:56] nick ↷ Links adapted because of a move operation |
dido:public:ra:xapend:xapend.b_stds:defact:bitcoin:bips:bip_0141 [2021/08/17 14:03] (current) murphy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ======== BIP 0141 - Segregated Witness (Consensus layer) (soft fork) ======== | + | ==== BIP 0141 - Segregated Witness (Consensus layer) (soft fork) ==== |
| - | [[dido:public:ra:xapend.stds:defact:bitcoin| return to the Bitcoin Standards ]] | + | [[dido:public:ra:xapend:xapend.b_stds:defact:bitcoin:bips| return to the Bitcoin Improvement Proposals ]] |
| <table> | <table> | ||
| Line 9: | Line 9: | ||
| | Comments-Summary | No comments yet. | | | Comments-Summary | No comments yet. | | ||
| | Comments-URI | [[https://github.com/bitcoin/bips/wiki/Comments:BIP-0141]] | | | Comments-URI | [[https://github.com/bitcoin/bips/wiki/Comments:BIP-0141]] | | ||
| - | | Staus | Final | | + | | Status | Final | |
| | Type | Standards Track | | | Type | Standards Track | | ||
| | Created | 2015-12-21 | | | Created | 2015-12-21 | | ||
| Line 17: | Line 17: | ||
| </table> | </table> | ||
| - | : **Note**: The following is an excerpt from the official Bitcoin site. It is provided here as a connivence and is not authoritative. Refer to the original document(s) as the authoritative reference. | + | : **Note**: The following is an excerpt from the official [[dido:public:ra:xapend:xapend.a_glossary:b:bitcoin|Bitcoin]] site. It is provided here as a convenience and is not authoritative. Refer to the original document(s) as the authoritative reference. |
| - | ====== Abstract ====== | + | === 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.// | + | //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.// | + | //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 [[dido:public:ra:xapend:xapend.a_glossary:s:soft_fork|soft fork]] compatible. A future [[dido:public:ra:xapend:xapend.a_glossary:h:hard_fork |
| + | |hard fork]] can place this tree in its own branch.// | ||
| - | ====== Motivation ====== | + | === Motivation === |
| - | ://The entirety of the transaction's effects are determined by output consumption (spends) and new output creation. Other transaction data, and signatures in particular, are only required to validate the blockchain state, not to determine it.// | + | //The entirety of the transaction's effects are determined by output consumption (spends) and new output creation. Other transaction data, and signatures in particular, are only required to validate the [[dido:public:ra:xapend:xapend.a_glossary:b:blockchain|blockchain]] state, not to determine it.// |
| - | : //By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:// | + | //By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:// |
| - | - //Nonintentional malleability becomes impossible. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach ([[ https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki | BIP62]]):// | + | //1. Nonintentional malleability becomes impossible. Since signature data is no longer part of the transaction hash, changes to how the transaction was signed are no longer relevant to transaction [[dido:public:ra:xapend:xapend.a_glossary:i:identification|identification]]. As a solution of transaction malleability, this is superior to the canonical signature approach ([[ https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki | BIP62]]):// |
| - | * //It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation)// | + | * //It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation)// |
| - | * //In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with [[ https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki | BIP62]])// | + | * //In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of [[dido:public:ra:xapend:xapend.a_glossary:p:private_key|private key]] holders (as opposed to only 1 private key holder with [[ https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki | BIP62]])// |
| - | * //It prevents involuntary transaction malleability due to unknown ECDSA signature malleability// | + | * //It prevents involuntary transaction malleability due to unknown ECDSA signature malleability// |
| - | * //It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network// | + | * //It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the [[dido:public:ra:xapend:xapend.a_glossary:l:lightning_network|Lightning Network]]// |
| - | - //Transmission of signature data becomes optional. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth.// | + | //2. Transmission of signature data becomes optional. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of [[dido:public:ra:xapend:xapend.a_glossary:s:spv]] proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same [[dido:public:ra:xapend:xapend.a_glossary:b:bandwidth|bandwidth]].// \\ |
| - | - //Some constraints could be bypassed with a soft fork by moving part of the transaction data to a structure unknown to current protocol, for example:// | + | //3. Some constraints could be bypassed with a soft fork by moving part of the transaction data to a structure unknown to current [[dido:public:ra:xapend:xapend.a_glossary:p:protocol|protocol]], for example:// |
| - | * //Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent// | + | * //Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent// |
| - | * //Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed// | + | * //Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed// |
| - | * //New script system could be introduced without any limitation from the existing script semantic. For example, a new transaction digest algorithm for transaction signature verification is described in [[dido:public:ra:xapend.stds:defact:bitcoin:bips:bip_0143]]// | + | * //New script system could be introduced without any limitation from the existing script semantic. For example, a new transaction digest algorithm for transaction signature verification is described in [[dido:public:ra:xapend:xapend.b_stds:defact:bitcoin:bips:bip_0143| BIP143]].// |
dido/public/ra/xapend/xapend.b_stds/defact/bitcoin/bips/bip_0141.1588892218.txt.gz · Last modified: 2020/05/07 18:56 by nick
