1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6D1409BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 00:24:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6232835
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 00:24:48 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1gXEnz-0006Mj-Bb; Thu, 13 Dec 2018 10:24:45 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 13 Dec 2018 10:24:38 +1000
Date: Thu, 13 Dec 2018 10:24:38 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20181213002438.r3bylrjcpwit5v2k@erisian.com.au>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
<87ftv3xerx.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ftv3xerx.fsf@rustcorp.com.au>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
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, 13 Dec 2018 22:09:29 +0000
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
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, 13 Dec 2018 00:24:49 -0000
On Wed, Dec 12, 2018 at 08:12:10PM +1030, Rusty Russell via bitcoin-dev wrote:
> Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> > Here is a combined proposal:
> > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
> > and SIGHASH_SCRIPTMASK.
> > * A new opcode OP_MASK is added, which acts as a NOP during execution.
> > * The sighash is computed like in BIP143, but:
> > * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
> > the subsequent opcode/push is removed.
> I'm asking on-list because I'm sure I'm not the only confused one.
> Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always
> perform mask-removal for signing?
The way I'm thinking about it is there's four amounts of knowledge you
could have about the input you're spending at the time you generate a
signature:
ALL: you know everything about every input for this tx
SINGLE: you know everything about the input you're signing for, but
not necessarily the others
SCRIPTPUBKEY: you know the exact scriptPubKey you're trying to satisfy, but
don't know the txid
SCRIPTMASK: you don't know the txid, don't know the scriptPubKey, don't
know the other taproot branches, and maybe don't even know the masked
out terms in the script -- but you do know the structure of the
script, and the non-masked terms
There's no value to masking in any but the final case -- the txid and
scriptPubKey commit to the full scriptcode already, so also signing the
scriptcode is just belt-and-suspenders protection.
(It might be that the "SCRIPTPUBKEY" option isn't very useful in
practice; maybe you'll always either know the txid, or need to mask
something?)
> And I am struggling to understand the role of scriptmask in a taproot
> world, where the alternate script is both hidden and general?
In a taproot world, your scriptPubKey is a point P=Q+H(Q,S)*G, where S
is a merkle root of possibly many scripts, and is spendable either by:
sig(P)
Q, path(S,script), script, witness(script)
SCRIPTMASK lets you prepare a signature for one particular script in
advance, even before you've decided what the other scripts are (and even
what the base point Q is), let alone built an actual transaction.
At least, that's my current understanding; and I think it makes sense...
Cheers,
aj
|
