Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9A0BCD48 for ; Mon, 2 Jul 2018 18:23:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f195.google.com (mail-ua0-f195.google.com [209.85.217.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 25E9B334 for ; Mon, 2 Jul 2018 18:23:50 +0000 (UTC) Received: by mail-ua0-f195.google.com with SMTP id x18-v6so10619895uaj.9 for ; Mon, 02 Jul 2018 11:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-transfer-encoding; bh=6nCs3aJjcORVIjjKwEUTizbNxXeF2BbnHJvOVFMjVZE=; b=GVRMDnilmXtrbze7B19/YeBXyCzm3SKYQ6LLZeUTz5teyKmWFTgh6erkngDS8fgPXv DIsJ8dxYJMJSu9gnwJsj3yzcRjwrTJU0lbAPS2iqPZPa6UNz2eWxhiS/4Xt77bRUHXw0 id+4DcYS7IiGDU53FMKeHP6fO/zH/hrz4Xbk/D57KX1SWEA8/AvQNysVOl5RU1tC5h3a pBqmQ7KdLY7ICp4wxbKB0Bbh6JWrC9kzMTfJ8gz91iT4cBIofR1ldxeIUSjVKEuwPJJi AYCpUzztuY3/2y6G3EgpvUGovhyB6g0yWKuihkv7syTknANAayoEY1Jkiom3bRrmvaCl fjyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-transfer-encoding; bh=6nCs3aJjcORVIjjKwEUTizbNxXeF2BbnHJvOVFMjVZE=; b=jGHvQORpJMtnyNZQ6fDv34Wf8Z0NCI8z8qiUkIVMuOgUGjsY5boS2MxHD/Mjj3O9dg +FA9KZ2tGM3j1umel54rORfj96s4/OUa7NJKhWm/CthhPJPrGRcCuLK+1bqNvNadi2FN zGOAl93me4zHpcPEB/6wPUIlHteC77x1vZj5hIzNwMcwrqu490i4p+5IH3mmzK27pVl8 MncNe7M9c+QpHsUm3Y7GDC3L4/tQArxWA6GaRnWUvkMi34iEE3uio2n9Qsu0h+Ger25j UTIURaocZGVNcaVX5EVnkey9jRq9xDr54Q8tzXE5LT00ry3c/WaTw811ljEMcWzeeFvE sl0g== X-Gm-Message-State: APt69E1aCz9zLLjUk3hHNVzfa0nPxk3rcSR3IO8mSvjc32KGr6MooIvy fKakeAVmRDzzKrtSsRRxvGa4+y63kde+Z8LWul4= X-Google-Smtp-Source: AAOMgpfj89/GVBnvxF1xDn4X0o8BSsAlXmLJ0qeUqkZNFRuvmdXDsIIKOVp9Xqn42Wq1gY6b9Os/TbXQNNQ9YbeHZfs= X-Received: by 2002:a9f:2723:: with SMTP id a32-v6mr15517896uaa.76.1530555829088; Mon, 02 Jul 2018 11:23:49 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 2002:a67:51c9:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 11:23:48 -0700 (PDT) In-Reply-To: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk> References: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk> From: Gregory Maxwell Date: Mon, 2 Jul 2018 18:23:48 +0000 X-Google-Sender-Auth: 6zD82lw9PKSNZIhoVV9d95Wx2Jc Message-ID: To: Johnson Lau , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 18:23:50 -0000 On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev wrote: > 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 o= f 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 sequ= ence, same as defined in BIP143. Otherwise, it is 32-byte of 0x0000......00= 00. > =E2=80=A2 If the value is even (including 0), nSequence is the nS= equence 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 th= e 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_A= LL 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_S= INGLE 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. O= therwise, it is same as described in BIP143. > > Bits 10 to 15 are reserved and ignored, but the signature still commits t= o their value as hashtype. > > hashtype of 0 is also known as SIGHASH2_ALL, which covers all the availab= le options. In this case the singnature MUST be exactly 64-byte. > > hashtype of 0x3ff is also known as SIGHASH2_NONE, which covers nothing an= d is effectively forfeiting the right related to this public key to anyone. This seems fairly complicated and yet-- if I don't misunderstand-- it doesn't capture the one special output masking case that I've seen actual applications want (which itself, is one out of the only two special sighash cases I've seen applications want-- the other being no-input). The case I think this is missing is SIGHASH_SINGLE | SIGHASH_LAST_OUTPUT e.g. "Sign the matching output, and the last output regardless of its index". The application for this style is "kickstarter" joint-payment transactions where you wish to sign both your change output (SIGHASH_SINGLE) and the joint-payment output (SIGHASH_LAST_OUTPUT). Without it, this kind of usage requires usually a chain of depth two for each input to split off the change. I came back around to your post at Sipa's recommendation because I was musing on is there a _simple_ set of enhanced sighash flags that capture real useful behaviour without falling down a rathole of specifying a totally general behaviour.