path: root/0e/0e711f8db0c43f0e1b5f6a04581a22e2e9deef

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F43A9DA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Aug 2018 20:38:18 +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 420E07D1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Aug 2018 20:38:16 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1535661492; cv=none; d=zoho.com; s=zohoarc; 
	b=G4SSKo0H6uxuxW8ZJ6aFb7RZT4uhCSfLBZaHsbBYq2cJ/kvOg0FamVWr4RHx7aEpSX5eLs7kxcIM1+9pvGUpSANsSaIvTM5J+LRKWn/cdxdtfHw7dUHF/ueS4dT7A3IQzFlOpVIITIHlpU2Ng+fupz8xLzy2fI1Ba4+L2mhiVF8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
	s=zohoarc; t=1535661492;
	h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
	bh=AeE9+JlibhkbVNo+SmLBQqYfUfNS806Q892cv2SgunU=; 
	b=oGeDGVRWzjrUA3uto/w9LEMrbdhWVerdD/bYRHfmlNh2ABvmibPnXadDPz/M1rMCXOuaKlys07ui/A0nG5+PqOrajoVzzd0KfbSO2Az7tg3uv1XazAOIqIP6f5R3xrK0NBE/ayc64V502laqwqt2FksMUvjYt7Ey1+wmIqAqmo8=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass  header.i=xbt.hk;
	spf=pass  smtp.mailfrom=jl2012@xbt.hk;
	dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.103] (n218103136198.netvigator.com [218.103.136.198])
	by mx.zohomail.com with SMTPS id 1535661490818479.31486685064147;
	Thu, 30 Aug 2018 13:38:10 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <B35E0135-2135-405A-9627-F67EFB9D2614@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FAF547CA-8DC0-4E99-88C5-8385E2D727CD"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Fri, 31 Aug 2018 04:38:06 +0800
In-Reply-To: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk>
To: Johnson Lau <jl2012@xbt.hk>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk>
X-Mailer: Apple Mail (2.3445.8.2)
X-ZohoMailClient: External
X-ZohoMail: Z_634019925 SPT_1 Z_634019924 SPT_1 SLF_D S_170 ZMSCN
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	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
X-Mailman-Approved-At: Thu, 30 Aug 2018 23:19:12 +0000
Subject: Re: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 20:38:18 -0000


--Apple-Mail=_FAF547CA-8DC0-4E99-88C5-8385E2D727CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

After gathering some feedbacks I substantially revised the proposal. =
This version focus on improving security, and reduces the number of =
optional features.

Formatted BIP and sample code at:
https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
https://github.com/jl2012/bitcoin/commits/sighash2

The major new features compared with BIP143:

1. If signing all inputs, also sign all input value. BIP143 signature =
only covers the value of the same input. In some cases this may not be =
adequate for hardware wallet to determine the right amount of fees. =
Signing all input values will secure any possible case.
2. Sign both scriptCode and previous scriptPubKey. In the original =
bitcoin design, previous scriptPubKey is signed as the scriptCode. =
However, this is not the case with P2SH and segwit. Explicitly =
committing to the scriptPubKey allows hardware wallet to confirm what it =
is actually signing (e.g. P2SH-segwit vs. Native-segwit).
3. SIGHASH2_NOINPUT: basically same as BIP118, but the signature commits =
to both scriptCode and scriptPubKey. This prevents signature replay if =
the same public key is used in different scripts.
4. SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows =
out-of-range case.
5. SIGHASH2_LASTOUTPUT: signs only the highest index output.
6. SIGHASH2_DUALOUTPUT: signs the matched output and the highest index =
output. Described by gmaxwell at =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.h=
tml =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.=
html>
7. Signing the amount of fees (optional, yes by default). In case of not =
signing all inputs or outputs, users may still want to commit to a =
specific fee amount.
8. Signing the witness size (optional, yes by default). While segwit =
fixed txid malleability, it is not a fix of script malleability. It may =
cause some trouble if an attacker could bloat the witness and reduce the =
fee priority of a transaction. Although the witness size is not =
malleable for most simple scripts, this is not guaranteed for more =
complex ones. Such kind of size malleability could be avoided if =
signatures commit to the size of witness.

Any suggestions are welcomed. But I have the following questions:

1. Should NOINPUT commit to scriptCode and/or scriptPubKey? I think it =
should, because that helps avoid signature replay in some cases, and =
also lets hardware wallets know what they are signing. I am asking this =
because BIP118 proposes the opposite. I want to make sure I=E2=80=99m =
not missing something here.
2. Do we want to add LASTOUTPUT and DUALOUTPUT? Suggested by gmaxwell, =
an example use case is kickstarter, where individual supporters send =
money to the last output for a kickstarter project, and send change to =
the matched output. However, I doubt if this would be actually used this =
way, because the kickstarter organiser could always take the money =
before the target is met, by making up the difference with his own =
input. This is an inherent problem for any anonymous kickstarter scheme. =
If these new SIGHASHs are not useful in other applications, I am not =
sure if we should add them.
3. Instead of these restrictive MATCH/LAST/DUALOUTPUT, do we want a =
fully flexible way to sign a subset of outputs? The indexes of signed =
outputs are put at the end of the signature, and the signature won=E2=80=99=
t commit to these index values. Therefore, a third party could collect =
all transactions of this kind and merge them into one transaction. To =
limit the sighash cost, number of signed outputs might not be more than =
2 or 3. Some potential problems: a) code complexity; b) 1-byte or 2-byte =
index: 1-byte will limit the number of outputs to 256. 2-byte will use =
more space even for smaller txs; c) highly variable signature size makes =
witness size estimation more difficult
4. Should we sign the exact witness size (as proposed), or an upper size =
limit? Signing an upper limit will take up more space, as the limit has =
to be explicitly shown in the witness. The overhead could be avoided by =
showing the limit only if the actual witness size is not equal to the =
committed limit. However, I tend to keep it simple and sign the exact =
value. If in a multi-sig setup some signers are unable to accurately =
estimate the witness size, they should leave this responsibility to the =
last signer who should know the exact size.


> On 1 Jun 2018, at 2:35 AM, Johnson Lau via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> 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.
>=20
> 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
>=20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D
>=20
> BIP: YYY
>  Layer: Consensus (soft fork)
>  Title: Signature checking operations in version 1 witness program
>  Author: Johnson Lau <jl2012@xbt.hk>
>  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
>=20
>=20
> *Abstract
>=20
> This BIP defines signature checking operations in version 1 witness =
program.
>=20
> *Motivation
>=20
> Use of compact signatures to save space.
>=20
> More SIGHASH options, more flexibility
>=20
> *Specification
>=20
> The following specification is applicable to OP_CHECKSIG and =
OP_CHECKSIGVERIFY in version 1 witness program.
>=20
> **Public Key Format
>=20
> The pubic key MUST be exactly 33 bytes.
>=20
> 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)
>=20
> If the first byte of the public key is neither 0x02 nor 0x03, the =
signature is assumed valid. This is for future upgrade.
>=20
> **Signature Format
>=20
> The following rules apply only if the first byte of the public key is =
a 0x02 or 0x03.
>=20
> 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).
>=20
> hashtype MUST be minimally encoded. Any trailing zero MUST be removed.
>=20
> 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)
>=20
> The script execution MUST fail with a signature size not 0, 64, 65, or =
66-byte.
>=20
> **New hashtype definitions
>=20
> hashtype and the SignatureHash function are re-defined:
>=20
>  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)
>=20
> The bit 0 to 3 of hashtype denotes a value between 0 and 15:
>=20
> 	=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.
>=20
> The bit 4 and 5 of hashtype denotes a value between 0 and 3:
>=20
> 	=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.
>=20
> If bit 8 is set (SIGHASH2_NOVERSION), nVersion is 0x00000000. =
Otherwise, it is the transaction nVersion.
>=20
> If bit 9 is set (SIGHASH2_NOSCRIPTCODE), scriptCode is an empty =
script. Otherwise, it is same as described in BIP143.
>=20
> Bits 10 to 15 are reserved and ignored, but the signature still =
commits to their value as hashtype.
>=20
> 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.
>=20
> 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.
>=20
> *Rationale
>=20
> **Signature Format
>=20
> The current DER format is a complete waste of block space. The new =
format saves ~8 bytes per signature.
>=20
> **New hashtype definitions
>=20
> 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)
>=20
> Why decouple INPUT and SEQUENCE? Maybe you want NOINPUT but still have =
a relative lock-time?
>=20
> 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.
>=20
> 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.
>=20
> Why signing INPUTINDEX? Legacy and BIP143 SINGLE|ANYONECANPAY behaves =
differently for input index. Better make it explicit and optional.
>=20
> Why signing FEE? Sometimes you don't sign all inputs / outputs but =
still want to make sure the fees amount is correct.
>=20
> Putting NOVERSION and NOSCRIPTCODE in the second byte makes most =
signatures below 66 bytes:
>=20
> 	=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).
>=20
> *Examples
>=20
> 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)
>=20
> Notes:
>=20
> 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.
>=20
> *Backward compatibility
>=20
> This is a soft-fork.
>=20
> *Deployment
>=20
> Exact details TBD.
>=20
> *Reference Implementation
>=20
> https://github.com/jl2012/bitcoin/commits/sighash2 (To be updated)
>=20
> *Copyright
>=20
> This document is licensed as BSD 3-clause.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_FAF547CA-8DC0-4E99-88C5-8385E2D727CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">After=
 gathering some feedbacks I substantially revised the proposal. This =
version focus on improving security, and reduces the number of optional =
features.<div class=3D""><br class=3D""></div><div class=3D"">Formatted =
BIP and sample code at:</div><div class=3D""><div style=3D"margin: 0px; =
font-stretch: normal; line-height: normal; color: rgb(88, 86, 214);" =
class=3D""><span style=3D"font-kerning: none" class=3D""><a =
href=3D"https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawik=
i" =
class=3D"">https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.media=
wiki</a></span></div><div style=3D"margin: 0px; font-stretch: normal; =
line-height: normal; color: rgb(88, 86, 214);" class=3D""><span =
style=3D"font-kerning: none" class=3D""><a =
href=3D"https://github.com/jl2012/bitcoin/commits/sighash2" =
class=3D"">https://github.com/jl2012/bitcoin/commits/sighash2</a></span></=
div></div><div class=3D""><br class=3D""></div><div class=3D"">The major =
new features compared with BIP143:</div><div class=3D""><br =
class=3D""></div><div class=3D"">1. If signing all inputs, also sign all =
input value. BIP143 signature only covers the value of the same input. =
In some cases this may not be adequate for hardware wallet to determine =
the right amount of fees. Signing all input values will secure any =
possible case.</div><div class=3D"">2. Sign both scriptCode and previous =
scriptPubKey. In the original bitcoin design, previous scriptPubKey is =
signed as the scriptCode. However, this is not the case with P2SH and =
segwit. Explicitly committing to the scriptPubKey allows hardware wallet =
to confirm what it is actually signing (e.g. P2SH-segwit vs. =
Native-segwit).</div><div class=3D"">3. SIGHASH2_NOINPUT: basically same =
as BIP118, but the signature commits to both scriptCode and =
scriptPubKey.&nbsp;This prevents signature replay if the same public key =
is used in different scripts.</div><div class=3D"">4. =
SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows out-of-range =
case.</div><div class=3D"">5. SIGHASH2_LASTOUTPUT: signs only the =
highest index output.</div><div class=3D"">6. SIGHASH2_DUALOUTPUT: signs =
the matched output and the highest index output. Described by gmaxwell =
at&nbsp;<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/=
016188.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Ju=
ly/016188.html</a></div><div class=3D"">7. Signing the amount of fees =
(optional, yes by default). In case of not signing all inputs or =
outputs, users may still want to commit to a specific fee =
amount.</div><div class=3D"">8. Signing the witness size (optional, yes =
by default). While segwit fixed txid malleability, it is not a fix of =
script malleability. It may cause some trouble if an attacker could =
bloat the witness and reduce the fee priority of a transaction. Although =
the witness size is not malleable for most simple scripts, this is not =
guaranteed for more complex ones. Such kind of size malleability could =
be avoided if signatures commit to the size of witness.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Any suggestions are =
welcomed. But I have the following questions:</div><div class=3D""><br =
class=3D""></div><div class=3D"">1. Should NOINPUT commit to scriptCode =
and/or scriptPubKey? I think it should, because that helps avoid =
signature replay in some cases, and also lets hardware wallets know what =
they are signing. I am asking this because BIP118 proposes the opposite. =
I want to make sure I=E2=80=99m not missing something here.</div><div =
class=3D"">2. Do we want to add LASTOUTPUT and DUALOUTPUT? Suggested by =
gmaxwell, an example use case is kickstarter, where individual =
supporters send money to the last output for a kickstarter project, and =
send change to the matched output. However, I doubt if this would be =
actually used this way, because the kickstarter organiser could always =
take the money before the target is met, by making up the difference =
with his own input. This is an inherent problem for any anonymous =
kickstarter scheme. If these new SIGHASHs are not useful in other =
applications, I am not sure if we should add them.</div><div class=3D"">3.=
 Instead of these restrictive MATCH/LAST/DUALOUTPUT, do we want a fully =
flexible way to sign a subset of outputs? The indexes of signed outputs =
are put at the end of the signature, and the signature won=E2=80=99t =
commit to these index values. Therefore, a third party could collect all =
transactions of this kind and merge them into one transaction. To limit =
the sighash cost, number of signed outputs might not be more than 2 or =
3. Some potential problems: a) code complexity; b) 1-byte or 2-byte =
index: 1-byte will limit the number of outputs to 256. 2-byte will use =
more space even for smaller txs; c) highly variable signature size makes =
witness size estimation more difficult</div><div class=3D"">4. Should we =
sign the exact witness size (as proposed), or an upper size limit? =
Signing an upper limit will take up more space, as the limit has to be =
explicitly shown in the witness. The overhead could be avoided by =
showing the limit only if the actual witness size is not equal to the =
committed limit. However, I tend to keep it simple and sign the exact =
value. If in a multi-sig setup some signers are unable to accurately =
estimate the witness size, they should leave this responsibility to the =
last signer who should know the exact size.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On 1 Jun 2018, at 2:35 AM, =
Johnson Lau via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">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.<br class=3D""><br class=3D"">A =
formatted version and example code could be found here:<br class=3D""><a =
href=3D"https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawik=
i" =
class=3D"">https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.media=
wiki</a><br =
class=3D"">https://github.com/jl2012/bitcoin/commits/sighash2<br =
class=3D""><br class=3D""><br class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D<br =
class=3D""><br class=3D"">BIP: YYY<br class=3D""> &nbsp;Layer: Consensus =
(soft fork)<br class=3D""> &nbsp;Title: Signature checking operations in =
version 1 witness program<br class=3D""> &nbsp;Author: Johnson Lau =
&lt;jl2012@xbt.hk&gt;<br class=3D""> &nbsp;Comments-Summary: No comments =
yet.<br class=3D""> &nbsp;Comments-URI: =
https://github.com/bitcoin/bips/wiki/Comments:BIP-0YYY<br class=3D""> =
&nbsp;Status: Draft<br class=3D""> &nbsp;Type: Standards Track<br =
class=3D""> &nbsp;Created: 2017-07-19<br class=3D""> &nbsp;License: =
BSD-3-Clause<br class=3D""><br class=3D""><br class=3D"">*Abstract<br =
class=3D""><br class=3D"">This BIP defines signature checking operations =
in version 1 witness program.<br class=3D""><br class=3D"">*Motivation<br =
class=3D""><br class=3D"">Use of compact signatures to save space.<br =
class=3D""><br class=3D"">More SIGHASH options, more flexibility<br =
class=3D""><br class=3D"">*Specification<br class=3D""><br class=3D"">The =
following specification is applicable to OP_CHECKSIG and =
OP_CHECKSIGVERIFY in version 1 witness program.<br class=3D""><br =
class=3D"">**Public Key Format<br class=3D""><br class=3D"">The pubic =
key MUST be exactly 33 bytes.<br class=3D""><br class=3D"">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)<br =
class=3D""><br class=3D"">If the first byte of the public key is neither =
0x02 nor 0x03, the signature is assumed valid. This is for future =
upgrade.<br class=3D""><br class=3D"">**Signature Format<br class=3D""><br=
 class=3D"">The following rules apply only if the first byte of the =
public key is a 0x02 or 0x03.<br class=3D""><br class=3D"">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).<br class=3D""><br class=3D"">hashtype MUST =
be minimally encoded. Any trailing zero MUST be removed.<br class=3D""><br=
 class=3D"">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)<br class=3D""><br class=3D"">The script execution MUST fail =
with a signature size not 0, 64, 65, or 66-byte.<br class=3D""><br =
class=3D"">**New hashtype definitions<br class=3D""><br =
class=3D"">hashtype and the SignatureHash function are re-defined:<br =
class=3D""><br class=3D""> &nbsp;Double SHA256 of the serialization =
of:<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;1. nVersion (4-byte little =
endian)<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;2. hashPrevouts (32-byte =
hash)<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;3. hashSequence (32-byte =
hash)<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;4. outpoint (32-byte hash + =
4-byte little endian)<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;5. =
scriptCode (serialized as scripts inside CTxOuts)<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;6. nAmount (8-byte little endian)<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;7. nSequence (4-byte little endian)<br class=3D"">=
 &nbsp;&nbsp;&nbsp;&nbsp;8. hashOutputs (32-byte hash)<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;9. nLocktime (4-byte little endian)<br class=3D"">=
 &nbsp;&nbsp;&nbsp;10. nInputIndex (4-byte little endian)<br class=3D""> =
&nbsp;&nbsp;&nbsp;11. nFees (8-byte little endian)<br class=3D""> =
&nbsp;&nbsp;&nbsp;12. hashtype (4-byte little endian)<br class=3D""> =
&nbsp;&nbsp;&nbsp;13. sigversion (4-byte little endian for the fixed =
value 0x01000000)<br class=3D""><br class=3D"">The bit 0 to 3 of =
hashtype denotes a value between 0 and 15:<br class=3D""><br =
class=3D""><span style=3D"white-space:pre" class=3D"Apple-tab-span">	=
</span>=E2=80=A2 If the value is 1, the signature is invalid.<br =
class=3D""><span style=3D"white-space:pre" class=3D"Apple-tab-span">	=
</span>=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.<br class=3D""><span style=3D"white-space:pre" =
class=3D"Apple-tab-span">	</span>=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.<br class=3D""><span style=3D"white-space:pre"=
 class=3D"Apple-tab-span">	</span>=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.<br class=3D""><span =
style=3D"white-space:pre" class=3D"Apple-tab-span">	</span>=E2=80=A2 =
If the value is even (including 0), nSequence is the nSequence of the =
current input. Otherwise, it is 0x00000000.<br class=3D""><span =
style=3D"white-space:pre" class=3D"Apple-tab-span">	</span>=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.<br class=3D""><span =
style=3D"white-space:pre" class=3D"Apple-tab-span">	</span>=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.<br class=3D""><br =
class=3D"">The bit 4 and 5 of hashtype denotes a value between 0 and =
3:<br class=3D""><br class=3D""><span style=3D"white-space:pre" =
class=3D"Apple-tab-span">	</span>=E2=80=A2 If the value is 0, =
hashOutputs is same as the SIGHASH_ALL case in BIP143 as a hash of all =
outputs.<br class=3D""><span style=3D"white-space:pre" =
class=3D"Apple-tab-span">	</span>=E2=80=A2 If the value is 1, the =
signature is invalid.<br class=3D""><span style=3D"white-space:pre" =
class=3D"Apple-tab-span">	</span>=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.<br class=3D""><span style=3D"white-space:pre"=
 class=3D"Apple-tab-span">	</span>=E2=80=A2 If the value is 3, =
hashOutputs is 32-byte of 0x0000......0000.<br class=3D"">If bit 6 is =
set (SIGHASH2_NOFEE), nFees is 0x0000000000000000. Otherwise, it is the =
fee paid by the transaction.<br class=3D"">If bit 7 is set =
(SIGHASH2_NOLOCKTIME), nLockTime is 0x00000000. Otherwise, it is the =
transaction nLockTime.<br class=3D""><br class=3D"">If bit 8 is set =
(SIGHASH2_NOVERSION), nVersion is 0x00000000. Otherwise, it is the =
transaction nVersion.<br class=3D""><br class=3D"">If bit 9 is set =
(SIGHASH2_NOSCRIPTCODE), scriptCode is an empty script. Otherwise, it is =
same as described in BIP143.<br class=3D""><br class=3D"">Bits 10 to 15 =
are reserved and ignored, but the signature still commits to their value =
as hashtype.<br class=3D""><br class=3D"">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.<br class=3D""><br class=3D"">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.<br class=3D""><br class=3D"">*Rationale<br class=3D""><br =
class=3D"">**Signature Format<br class=3D""><br class=3D"">The current =
DER format is a complete waste of block space. The new format saves ~8 =
bytes per signature.<br class=3D""><br class=3D"">**New hashtype =
definitions<br class=3D""><br class=3D"">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)<br =
class=3D""><br class=3D"">Why decouple INPUT and SEQUENCE? Maybe you =
want NOINPUT but still have a relative lock-time?<br class=3D""><br =
class=3D"">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.<br class=3D""><br =
class=3D"">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.<br class=3D""><br class=3D"">Why signing =
INPUTINDEX? Legacy and BIP143 SINGLE|ANYONECANPAY behaves differently =
for input index. Better make it explicit and optional.<br class=3D""><br =
class=3D"">Why signing FEE? Sometimes you don't sign all inputs / =
outputs but still want to make sure the fees amount is correct.<br =
class=3D""><br class=3D"">Putting NOVERSION and NOSCRIPTCODE in the =
second byte makes most signatures below 66 bytes:<br class=3D""><br =
class=3D""><span style=3D"white-space:pre" class=3D"Apple-tab-span">	=
</span>=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.<br class=3D""><span style=3D"white-space:pre" =
class=3D"Apple-tab-span">	</span>=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.<br class=3D"">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.<br =
class=3D"">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).<br class=3D""><br =
class=3D"">*Examples<br class=3D""><br class=3D"">Equivalent SIGHASH2 =
value for other SIGHASH schemes:<br class=3D"">Legacy/BIP143 ALL: 0 =
(commit to everything)<br class=3D"">Legacy/BIP143 SINGLE with matching =
output: 0x62 (all input, one sequence, one output, no fee)<br =
class=3D"">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)<br =
class=3D"">Legacy/BIP143 NONE: 0x72 (all input, one sequence, no output, =
no fee)<br class=3D"">Legacy/BIP143 ANYONECANPAY|ALL: 0x46 (one input =
without index, one sequence, all output, no fee)<br class=3D"">Legacy =
ANYONECANPAY|SINGLE with matching output: 0x64 (one input with index, =
one sequence, one output, no fee)<br class=3D"">Legacy/BIP143 =
ANYONECANPAY|NONE: 0x76 (one input without index, one sequence, no =
output, no fee)<br class=3D"">BIP143 SINGLE without matching output: =
0x62 (all input, one sequence, no output, no fee)<br class=3D"">BIP143 =
ANYONECANPAY|SINGLE with matching output: 0x66 (one input without index, =
one sequence, one output, no fee)<br class=3D"">BIP143 =
ANYONECANPAY|SINGLE without matching output: 0x66 (one input without =
index, one sequence, no output, no fee)<br class=3D"">BIP118 NOINPUT: =
0x14b (no input but with value, no index, no sequence, no fee, no =
scriptcode)<br class=3D""><br class=3D"">Notes:<br class=3D""><br =
class=3D"">1. In legacy and BIP143 SIGHASH, only ALL but not other types =
implicitly commits to the fee paid.<br class=3D"">2. Legacy SIGHASH =
always implicitly commits to the input value. BIP143 and BIP118 commits =
to that explicitly.<br class=3D"">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.<br class=3D"">4. BIP143 ANYONECANPAY never commits to the input =
index. Legacy ANYONECANPAY|SINGLE implicitly commits to the input =
index.<br class=3D""><br class=3D"">*Backward compatibility<br =
class=3D""><br class=3D"">This is a soft-fork.<br class=3D""><br =
class=3D"">*Deployment<br class=3D""><br class=3D"">Exact details =
TBD.<br class=3D""><br class=3D"">*Reference Implementation<br =
class=3D""><br =
class=3D"">https://github.com/jl2012/bitcoin/commits/sighash2 (To be =
updated)<br class=3D""><br class=3D"">*Copyright<br class=3D""><br =
class=3D"">This document is licensed as BSD 3-clause.<br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br =
class=3D"">bitcoin-dev@lists.linuxfoundation.org<br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_FAF547CA-8DC0-4E99-88C5-8385E2D727CD--