From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 54302FA8 for ; Thu, 31 May 2018 18:35:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26F806BA for ; Thu, 31 May 2018 18:35:47 +0000 (UTC) Received: from [10.8.0.110] (n218103136198.netvigator.com [218.103.136.198]) by mx.zohomail.com with SMTPS id 1527791745425244.38591135414094; Thu, 31 May 2018 11:35:45 -0700 (PDT) From: Johnson Lau Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk> Date: Fri, 1 Jun 2018 02:35:41 +0800 To: bitcoin-dev X-Mailer: Apple Mail (2.3445.5.20) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] SIGHASH2 for version 1 witness programme X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 18:35:49 -0000 Since 2016, I have made a number of proposals for the next generation of = script. Since then, there has been a lot of exciting development on this = topic. The most notable ones are Taproot and Graftroot proposed by = Maxwell. It seems the most logical way is to implement MAST and other = new script functions inside Taproot and/or Graftroot. Therefore, I = substantially simplified my earlier proposal on SIGHASH2. It is a = superset of the existing SIGHASH and the BIP118 SIGHASH_NOINPUT, with = further flexibility but not being too complicated. It also fixes some = minor problems that we found in the late stage of BIP143 review. For = example, the theoretical (but not statistical) possibility of having = same SignatureHash() results for a legacy and a witness transaction. = This is fixed by padding a constant at the end of the message so = collision would not be possible. A formatted version and example code could be found here: https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki https://github.com/jl2012/bitcoin/commits/sighash2 =3D=3D=3D=3D=3D=3D=3D=3D BIP: YYY Layer: Consensus (soft fork) Title: Signature checking operations in version 1 witness program Author: Johnson Lau Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0YYY Status: Draft Type: Standards Track Created: 2017-07-19 License: BSD-3-Clause *Abstract This BIP defines signature checking operations in version 1 witness = program. *Motivation Use of compact signatures to save space. More SIGHASH options, more flexibility *Specification The following specification is applicable to OP_CHECKSIG and = OP_CHECKSIGVERIFY in version 1 witness program. **Public Key Format The pubic key MUST be exactly 33 bytes. If the first byte of the public key is a 0x02 or 0x03, it MUST be a = compressed public key. The signature is a Schnorr signature (To be = defined separately) If the first byte of the public key is neither 0x02 nor 0x03, the = signature is assumed valid. This is for future upgrade. **Signature Format The following rules apply only if the first byte of the public key is a = 0x02 or 0x03. If the signature size is 64 to 66 byte, it MUST be a valid Schnorr = signature or the script execution MUST fail (cf. BIP146 NULLFAIL). The = first 32-byte is the R value in big-endian. The next 32-byte is the S = value in big-endian. The remaining data, if any, denotes the hashtype in = little-endian (0 to 0xffff). hashtype MUST be minimally encoded. Any trailing zero MUST be removed. If the signature size is zero, it is accepted as the "valid failing" = signature for OP_CHECKSIG to return a FALSE value to the stack. (cf. = BIP66) The script execution MUST fail with a signature size not 0, 64, 65, or = 66-byte. **New hashtype definitions hashtype and the SignatureHash function are re-defined: Double SHA256 of the serialization of: 1. nVersion (4-byte little endian) 2. hashPrevouts (32-byte hash) 3. hashSequence (32-byte hash) 4. outpoint (32-byte hash + 4-byte little endian) 5. scriptCode (serialized as scripts inside CTxOuts) 6. nAmount (8-byte little endian) 7. nSequence (4-byte little endian) 8. hashOutputs (32-byte hash) 9. nLocktime (4-byte little endian) 10. nInputIndex (4-byte little endian) 11. nFees (8-byte little endian) 12. hashtype (4-byte little endian) 13. sigversion (4-byte little endian for the fixed value 0x01000000) The bit 0 to 3 of hashtype denotes a value between 0 and 15: =E2=80=A2 If the value is 1, the signature is invalid. =E2=80=A2 If the value is 3 or below, hashPrevouts is the hash = of all input, same as defined in BIP143. Otherwise, it is 32-byte of = 0x0000......0000. =E2=80=A2 If the value is 7 or below, outpoint is the COutPoint = of the current input. Otherwise, it is 36-byte of 0x0000......0000. =E2=80=A2 If the value is 0, hashSequence is the hash of all = sequence, same as defined in BIP143. Otherwise, it is 32-byte of = 0x0000......0000. =E2=80=A2 If the value is even (including 0), nSequence is the = nSequence of the current input. Otherwise, it is 0x00000000. =E2=80=A2 If the value is 6, 7, 10, 11, 14, or 15, nInputIndex = is 0x00000000. Otherwise, it is the index of the current input. =E2=80=A2 If the value is 11 or below, nAmount is the value of = the current input (same as BIP143). Otherwise, it is 0x0000000000000000. The bit 4 and 5 of hashtype denotes a value between 0 and 3: =E2=80=A2 If the value is 0, hashOutputs is same as the = SIGHASH_ALL case in BIP143 as a hash of all outputs. =E2=80=A2 If the value is 1, the signature is invalid. =E2=80=A2 If the value is 2, hashOutputs is same as the = SIGHASH_SINGLE case in BIP143 as a hash of the matching output. If a = matching output does not exist, hashOutputs is 32-byte of = 0x0000......0000. =E2=80=A2 If the value is 3, hashOutputs is 32-byte of = 0x0000......0000. If bit 6 is set (SIGHASH2_NOFEE), nFees is 0x0000000000000000. = Otherwise, it is the fee paid by the transaction. If bit 7 is set (SIGHASH2_NOLOCKTIME), nLockTime is 0x00000000. = Otherwise, it is the transaction nLockTime. If bit 8 is set (SIGHASH2_NOVERSION), nVersion is 0x00000000. Otherwise, = it is the transaction nVersion. If bit 9 is set (SIGHASH2_NOSCRIPTCODE), scriptCode is an empty script. = Otherwise, it is same as described in BIP143. Bits 10 to 15 are reserved and ignored, but the signature still commits = to their value as hashtype. hashtype of 0 is also known as SIGHASH2_ALL, which covers all the = available options. In this case the singnature MUST be exactly 64-byte. hashtype of 0x3ff is also known as SIGHASH2_NONE, which covers nothing = and is effectively forfeiting the right related to this public key to = anyone. *Rationale **Signature Format The current DER format is a complete waste of block space. The new = format saves ~8 bytes per signature. **New hashtype definitions The default and most commonly used case is SIGHASH2_ALL. Making it zero = size to save space. As a result, the bit flags are defined in a negative = way (e.g. NOLOCKTIME) Why decouple INPUT and SEQUENCE? Maybe you want NOINPUT but still have a = relative lock-time? Why some combinations are missing? To save some bits for useless flags. = If you sign all inputs, you must know its index and value. If you sign = only this input, you must know its value, but probably don't know its = index in the input vector. Why only allow signing all SEQUENCE if all INPUT are signed? It doesn't = make much sense if you care about their sequence without even knowing = what they are. Why signing INPUTINDEX? Legacy and BIP143 SINGLE|ANYONECANPAY behaves = differently for input index. Better make it explicit and optional. Why signing FEE? Sometimes you don't sign all inputs / outputs but still = want to make sure the fees amount is correct. Putting NOVERSION and NOSCRIPTCODE in the second byte makes most = signatures below 66 bytes: =E2=80=A2 NOVERSION: Currently the only use of transaction = version is to enforce BIP68. It could be safely assumed that version 2 = is used. The only case one would like to use NOVERSION is to make the = signature compatible with some unknown new features that use a different = transaction version. =E2=80=A2 NOSCRIPTCODE: It would be very rare if one could make = a signature without knowing what the script is (at least they know the = public key). The only scenario that a NOSCRIPTCODE is really needed is = the public key being reused in different scripts, and the user wants to = use a single signature to cover all these scripts. Reserved bits: These bits are ignored but should normally be unset. = Users MUST NOT set these bits until they are defined by a future = proposal, or they might lose money. Why sigversion? Make sure the message digest won't collide with SIGHASH = schemes in the past (legacy and BIP143) and future (which will use a = different sigversion). *Examples Equivalent SIGHASH2 value for other SIGHASH schemes: Legacy/BIP143 ALL: 0 (commit to everything) Legacy/BIP143 SINGLE with matching output: 0x62 (all input, one = sequence, one output, no fee) Legacy SINGLE without matching output: 0x3ff (Not exactly. Both = signatures commit to nothing, but the legacy one is valid only without a = matched output. Practically, they are both "wildcard" signatures that = allow anyone to spend any related UTXO) Legacy/BIP143 NONE: 0x72 (all input, one sequence, no output, no fee) Legacy/BIP143 ANYONECANPAY|ALL: 0x46 (one input without index, one = sequence, all output, no fee) Legacy ANYONECANPAY|SINGLE with matching output: 0x64 (one input with = index, one sequence, one output, no fee) Legacy/BIP143 ANYONECANPAY|NONE: 0x76 (one input without index, one = sequence, no output, no fee) BIP143 SINGLE without matching output: 0x62 (all input, one sequence, no = output, no fee) BIP143 ANYONECANPAY|SINGLE with matching output: 0x66 (one input without = index, one sequence, one output, no fee) BIP143 ANYONECANPAY|SINGLE without matching output: 0x66 (one input = without index, one sequence, no output, no fee) BIP118 NOINPUT: 0x14b (no input but with value, no index, no sequence, = no fee, no scriptcode) Notes: 1. In legacy and BIP143 SIGHASH, only ALL but not other types implicitly = commits to the fee paid. 2. Legacy SIGHASH always implicitly commits to the input value. BIP143 = and BIP118 commits to that explicitly. 3. Legacy and BIP143 SIGHASH behaves differently in the case of SINGLE = without matching output. In legacy SIGHASH it is a true "wildcard = signature" that allows anyone to spend any related UTXO. In BIP143 such = signature applies only to a specific UTXO. 4. BIP143 ANYONECANPAY never commits to the input index. Legacy = ANYONECANPAY|SINGLE implicitly commits to the input index. *Backward compatibility This is a soft-fork. *Deployment Exact details TBD. *Reference Implementation https://github.com/jl2012/bitcoin/commits/sighash2 (To be updated) *Copyright This document is licensed as BSD 3-clause.=