From 4cb4534fd918653975709a3cf4877ed77ec576c4 Mon Sep 17 00:00:00 2001 From: Bryan Bishop Date: Wed, 20 Apr 2016 12:29:44 -0500 Subject: BIP143: fix typo ("including") --- bip-0143.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'bip-0143.mediawiki') diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 4c6503b..ed5cfec 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -191,7 +191,7 @@ This proposal is deployed with Segregated Witness softfork (BIP 141) == Backward compatibility == -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, inculding the redefined sigops, as anyone-can-spend scripts. +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, including the redefined sigops, as anyone-can-spend scripts. == Reference Implementation == -- cgit v1.2.3 From c1ef3a05e32bf477ebc4b05db9eba5d85ac24b49 Mon Sep 17 00:00:00 2001 From: Johnson Lau Date: Wed, 20 Apr 2016 13:16:39 +0800 Subject: BIP143 clarifying semantics of ACP|SINGLE --- bip-0143.mediawiki | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) (limited to 'bip-0143.mediawiki') diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index 4c6503b..d39fdd8 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -1,4 +1,4 @@ -
+
   BIP: 143
   Title: Transaction Signature Verification for Version 0 Witness Program
   Author: Johnson Lau 
@@ -28,37 +28,41 @@ A new transaction digest algorithm is defined, but only applicable to sigops in
      2. hashPrevouts (32-byte hash)
      3. hashSequence (32-byte hash)
      4. outpoint (32-byte hash + 4-byte little endian) 
-     5. scriptCode of the input (varInt for the length + script)
+     5. scriptCode of the input (serialized as scripts inside CTxOuts)
      6. value of the output spent by this input (8-byte little endian)
      7. nSequence of the input (4-byte little endian)
      8. hashOutputs (32-byte hash)
      9. nLocktime of the transaction (4-byte little endian)
     10. sighash type of the signature (4-byte little endian)
 
-All components in the original algorithm, including the behavior OP_CODESEPERATOR, remains unchanged. The only difference is the way of serialization and the inclusion of amount being spent.
+Semantics of the original sighash types remain unchanged, except the followings:
+# The way of serialization is changed;
+# All sighash types commit to the amount being spent by the signed input;
+# FindAndDelete of the signature is not applied to the scriptCode;
+# SINGLE does not commit to the input index. When ANYONECANPAY is not set, the semantics are unchanged since hashPrevouts and outpoint together implictly commit to the input index. When SINGLE is used with ANYONECANPAY, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index.
 
 The items 1, 4, 7, 9, 10 have the same meaning as the original algorithm. 
 
 The item 5:
 *For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac.
 *For P2WSH witness program,
-**if the witnessScript does not contain any OP_CODESEPERATOR, the scriptCode is a varInt for the length of the witnessScript, followed by the witnessScript.
-**if the witnessScript contains any OP_CODESEPERATOR, the scriptCode is the evaluated script, with all OP_CODESEPARATOR and everything up to the last OP_CODESEPARATOR before the signature checking opcode being executed removed, and prepended by a varInt for the length of the truncated script.
+**if the witnessScript does not contain any OP_CODESEPERATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOuts.
+**if the witnessScript contains any OP_CODESEPERATOR, the scriptCode is the evaluated script, with all OP_CODESEPARATOR and everything up to the last OP_CODESEPARATOR before the signature checking opcode being executed removed, serialized as scripts inside CTxOuts.
 
 The item 6 is a 8-byte value of the amount of bitcoin spent in this input.
 
 hashPrevouts:
-*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints;
+*If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints;
 *Otherwise, hashPrevouts is a uint256 of 0x0000......0000.
 
 hashSequence:
-*If none of the ANYONECANPAY, SINGLE, NONE sighash type is set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs;
+*If none of the ANYONECANPAY, SINGLE, NONE sighash type is set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs;
 *Otherwise, hashSequence is a uint256 of 0x0000......0000.
 
 hashOutputs:
-*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output value (8-byte little endian) with scriptPubKey (varInt for the length + script);
-*If sighash type is SINGLE and the input index is not greater than the number of outputs, hashOutputs is the double SHA256 of the output value with scriptPubKey of the same index as the input;
-*Otherwise, hashOutputs is a uint256 of 0x0000......0000.
+*If the sighash type is neither SINGLE nor NONE, hashOutputs is the double SHA256 of the serialization of all output value (8-byte little endian) with scriptPubKey (serialized as scripts inside CTxOuts);
+*If sighash type is SINGLE and the input index is not greater than the number of outputs, hashOutputs is the double SHA256 of the output value with scriptPubKey of the same index as the input;
+*Otherwise, hashOutputs is a uint256 of 0x0000......0000.In the original algorithm, a uint256 of 0x0000......0001 is commited if the input index for a SINGLE signature is greater than the number of outputs. In this BIP a 0x0000......0000 is commited, without changing the semantics.
 
 The hashPrevouts, hashSequence, and hashOutputs calculated in an earlier verification may be reused in other inputs of the same transaction, so that the time complexity of the whole hashing process reduces from O(n2) to O(n).
 
@@ -195,7 +199,7 @@ As a soft fork, older software will continue to operate without modification. No
 
 == Reference Implementation ==
 
-https://github.com/sipa/bitcoin/commits/segwit
+https://github.com/bitcoin/bitcoin/pull/7910
 
 == References ==
 
-- 
cgit v1.2.3


From a488367502f9b3187c0e993588894a8b24807e11 Mon Sep 17 00:00:00 2001
From: Bryan Bishop 
Date: Wed, 20 Apr 2016 12:45:48 -0500
Subject: BIP143: explicitly mention the SignatureHash function

The purpose of BIP143 is to propose an updated SignatureHash function
but "sighash" only appears near the end buried in the text. By
explicitly mentioning the SignatureHash function, readers can more
readily understand the context of the proposal.
---
 bip-0143.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'bip-0143.mediawiki')

diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki
index 4c6503b..1f921c0 100644
--- a/bip-0143.mediawiki
+++ b/bip-0143.mediawiki
@@ -14,7 +14,7 @@ This proposal defines a new transaction digest algorithm for signature verificat
 == Motivation ==
 There are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. The detailed procedure is described in a Bitcoin Wiki article. [https://en.bitcoin.it/wiki/OP_CHECKSIG]
 
-Unfortunately, there are at least 2 weaknesses in the original transaction digest algorithm:
+Unfortunately, there are at least 2 weaknesses in the original SignatureHash transaction digest algorithm:
 
 * For the verification of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n2) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest algorithm by introducing some reusable “midstate”, so the time complexity becomes O(n). [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2292 CVE-2013-2292][https://bitcointalk.org/?topic=140078 New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify][http://rusty.ozlabs.org/?p=522 The Megatransaction: Why Does It Take 25 Seconds?]
 * The algorithm does not involve the amount of Bitcoin being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the unknowing of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funding might be lost. [https://bitcointalk.org/index.php?topic=181734.0 SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data]
-- 
cgit v1.2.3