summaryrefslogtreecommitdiff
path: root/bip-0141.mediawiki
diff options
context:
space:
mode:
authorLuke-Jr <luke_github1@dashjr.org>2016-07-21 16:13:10 +0000
committerGitHub <noreply@github.com>2016-07-21 16:13:10 +0000
commit850d103abec6be9fd1d6bbb972f4c9ae7a76f2d5 (patch)
tree78d025b6719a719d33d2266fd31df5e641093c41 /bip-0141.mediawiki
parent76e29be5e022aa03561bc02ba328752cbad00fd0 (diff)
parent55c3d8068adbddd1cb9f97e4bc5e78500ce363bd (diff)
Merge pull request #416 from jl2012/patch-26
BIP141 fix
Diffstat (limited to 'bip-0141.mediawiki')
-rw-r--r--bip-0141.mediawiki23
1 files changed, 10 insertions, 13 deletions
diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 497cf7e..4b4a0aa 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -123,14 +123,13 @@ Sigops per block is currently limited to 20,000. We change this restriction as f
Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value.
The sigop limit is likewise quadrupled to ≤ 80,000.
-In addition, opcodes within the witness program are counted identical to as previously within the P2SH check script.
-That is, CHECKSIG in a witness program is counted as only 1 sigop, and CHECKMULTISIG in a witness program is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program.
+Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH <code>witnessScript</code> are counted identically as previously within the P2SH <code>redeemScript</code>. That is, CHECKSIG is counted as only 1 sigop, and CHECKMULTISIG is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program.
== Examples ==
-=== P2WPKH witness program ===
+=== P2WPKH ===
-The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH) witness program:
+The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH):
witness: <signature> <pubkey>
scriptSig: (empty)
@@ -147,7 +146,7 @@ Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less
=== P2WPKH nested in BIP16 P2SH ===
-The following example is the same P2WPKH witness program, but nested in a BIP16 P2SH output.
+The following example is the same P2WPKH, but nested in a BIP16 P2SH output.
witness: <signature> <pubkey>
scriptSig: <0 <20-byte-key-hash>>
@@ -159,13 +158,13 @@ The only item in scriptSig is hashed with HASH160, compared against the 20-byte-
0 <20-byte-key-hash>
-The P2WPKH witness program is then executed as described in the previous example.
+The public key and signature are then verified as described in the previous example.
Comparing with the previous example, the scriptPubKey is 1 byte bigger and the scriptSig is 23 bytes bigger. Although a nested witness program is less efficient, its payment address is fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0.
-=== P2WSH witness program ===
+=== P2WSH ===
-The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH) witness program.
+The following example is an 1-of-2 multi-signature version 0 pay-to-witness-script-hash (P2WSH).
witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig: (empty)
@@ -180,13 +179,13 @@ The script is executed with the remaining data from witness:
0 <signature1> 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG
-A P2WSH witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
+P2WSH allows maximum script size of 10,000 bytes, as the 520-byte push limit is bypassed.
The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 2<sup>80</sup> work is not infeasible anymore (By the end of 2015, 2<sup>84</sup> hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent BIP16 P2SH output but is moved to witness.
=== P2WSH nested in BIP16 P2SH ===
-The following example is the same 1-of-2 multi-signature P2WSH witness program, but nested in a BIP16 P2SH output.
+The following example is the same 1-of-2 multi-signature P2WSH script, but nested in a BIP16 P2SH output.
witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig: <0 <32-byte-hash>>
@@ -198,7 +197,7 @@ The only item in scriptSig is hashed with HASH160, compared against the 20-byte-
0 <32-byte-hash>
-The P2WSH witness program is then executed as described in the previous example.
+The P2WSH witnessScript is then executed as described in the previous example.
Comparing with the previous example, the scriptPubKey is 11 bytes smaller (with reduced security) while witness is the same. However, it also requires 35 bytes in scriptSig.
@@ -249,8 +248,6 @@ Since a version byte is pushed before a witness program, and programs with unkno
Examples of new script system include Schnorr signatures which reduce the size of multisig transactions dramatically, Lamport signature which is quantum computing resistance, and Merklized abstract syntax trees which allow very compact witness for conditional scripts with extreme complexity.
-The 32-byte limitation for witness program could be easily extended through a soft fork in case a stronger hash function is needed in the future. The version byte is also expandable through a softfork.
-
=== Per-input lock-time and relative-lock-time ===
Currently there is only one nLockTime field in a transaction and all inputs must share the same value. [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68] enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.