You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bip-codeshark-jl2012-segwit.mediawiki
+25-21Lines changed: 25 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -89,20 +89,19 @@ The new rule is s<sub>v</sub> <= 1 MB.
89
89
90
90
=== Witness program ===
91
91
92
-
* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a single push of 2 to 41 bytes gets a new special meaning. The byte vector pushed by it is called the "witness program".
93
-
** In case the scriptPubKey pushes a witness program directly, the scriptSig must be exactly empty.
94
-
** In case the redeemScript pushes a witness program, the scriptSig must be exactly the single push of the redeemScript.
92
+
* A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
93
+
** In case the scriptPubKey pushes a version byte and witness program directly, the scriptSig must be exactly empty.
94
+
** In case the redeemScript pushes a version byte and witness program, the scriptSig must be exactly the single push of the redeemScript.
95
95
96
-
* The first byte of a witness program is the "version byte", an unsigned integer.
97
-
** If the version byte is 0, the rest of the witness program is the actual script.
96
+
** If the version byte is 0, the WP is the actual script.
98
97
*** The script is executed after normal script evaluation but with data from the witness rather than the scriptSig.
99
98
*** The program must not fail, and result in exactly a single TRUE on the stack.
100
-
** If the version byte is 1, the rest of the witness program must be 32 bytes, as a SHA256 hash of the actual script.
99
+
** If the version byte is 1, the WP must be 32 bytes, as a SHA256 hash of the actual script.
101
100
*** The witness must consist of an input stack to feed to the program, followed by the serialized program.
102
101
*** The serialized program is popped off the initial witness stack. Hash of the serialized program must match the hash pushed in the witness program.
103
102
*** The serialized program is deserialized, and executed after normal script evaluation with the remaining witness stack.
104
103
*** The script must not fail, and result in exactly a single TRUE on the stack.
105
-
** If the witness version byte is 2 or above, no further interpretation of the witness program or witness happens.
104
+
** If the version byte is 2 to 16, no further interpretation of the witness program or witness happens.
106
105
107
106
=== Other consensus critical constraints ===
108
107
@@ -140,9 +139,9 @@ The following example is a version 0 witness program, equivalent to the existing
The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized:
162
+
The OP_1 in scriptPubKey indicates the following push is a version 1 witness program. The last item in the witness is popped off, hashed with SHA256, compared against the 32-byte-hash-value in scriptPubKey, and deserialized:
Since the actual program is larger than 40 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
170
+
Since the actual program is larger than 32 bytes, it cannot be accommodated in a version 0 witness program. A version 1 witness program allows arbitrarily large script as the 520-byte push limit is bypassed.
172
171
173
172
The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). The spending script is same as the one for an equivalent P2SH output but is moved to witness.
174
173
@@ -177,12 +176,12 @@ The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of P2SH. The increase
177
176
The following example is the same 1-of-2 multi-signature version 1 witness program, but nested in a P2SH output.
The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as a single push of:
182
+
The only item in scriptSig is hashed with HASH160, compared against the 20-byte-hash-value in scriptPubKey, and interpreted as:
184
183
185
-
<0x01{32-byte-hash-value}>
184
+
OP_1 <0x{32-byte-hash-value}>
186
185
187
186
The version 1 witness program is then executed as described in the last example
188
187
@@ -210,11 +209,11 @@ In the current Bitcoin protocol, it is possible to generate compact fraud proof
210
209
It is possible to proof the first 2 types of fraud if a block is committed to a Merkle-sum-tree of the fee, size, and sigop count of each transaction. It is also possible to proof the last type of fraud if a block is committed to a Merkle tree with the originating block height and transaction index of all inputs. These commitments could be included in the extensible witness commitment through a soft fork and will be transparent to nodes that do not understand such new rules.
211
210
212
211
=== New script system ===
213
-
Since all witness programs begin with a version byte, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.
212
+
Since a version byte is pushed before a witness program, and programs with unknown versions are always considered as anyone-can-spend script, it is possible to introduce any new script system with a soft fork. The witness as a structure is not restricted by any existing script semantics and constraints, the 520-byte push limit in particular, and therefore allows arbitrarily large scripts and signatures.
214
213
215
214
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.
216
215
217
-
The 41-byte limitation for witness programme 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 by introducing a secondary version byte for some specific primary version values.
216
+
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.
218
217
219
218
=== Per-input lock-time and relative-lock-time ===
220
219
Currently there is only one nLockTime field in a transaction and all inputs must share the same value. BIP68 enables per-input relative-lock-time using the nSequence field, however, with a limited lock-time period and resolution.
@@ -224,11 +223,16 @@ With a soft fork, it is possible to introduce a separate witness structure to al
224
223
== Backward compatibility ==
225
224
As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs as anyone-can-spend scripts (except a few edge cases in version 0 witness programs which are provably unspendable with original script semantics). Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion. Non-upgraded nodes are strongly encouraged to upgrade in order to take advantage of the new features.
226
225
227
-
=== Version 0 witness programs ===
228
-
Witness programs are hashed to 256 bit "redeemscripts" which are then hashed to 160 bit P2SH. This format is fully compatible with currently existing wallets that support P2SH. Upgraded wallets will be able to send and receive to and from older wallets without any problems.
226
+
'''What a non-upgraded wallet can do'''
229
227
230
-
=== Version 1 witness programs ===
231
-
Witness programs are hashed to a 256 bit output. This format will not be compatible with older wallets but will require less block space and will have better security due to increased collision resistance.
228
+
* Receiving bitcoin from non-upgraded and upgraded wallets
229
+
* Sending bitcoin to non-upgraded wallets
230
+
* Sending bitcoin to upgraded wallets using a P2SH address (a less efficient way to use segregated witness)
231
+
232
+
'''What a non-upgraded wallet cannot do'''
233
+
234
+
* Validating segregated witness transaction. It assumes such a transaction is always valid
235
+
* Sending bitcoin to upgraded wallets using a native witness program (a more efficient way to use segregated witness)
0 commit comments