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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A41164A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Nov 2018 11:20:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
[209.85.208.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0770A6C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Nov 2018 11:20:54 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id z28so4559245edi.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Nov 2018 03:20:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:in-reply-to:references:date:message-id:mime-version;
bh=nGIZlu+tp3GPK7vf93qSXBwMfKj66R/duZu7SKH5l+Y=;
b=jbeuy4tFAu3ApeCSwiCJj0MqlQzgItDUiQQ54wuPSudEZCV7J2bcTYTnndgvvXzfwr
IkW4FP6cGyXDYynBI1ANHsiKoqRLuYxjqEjCHJH49iLcgBhr4PA+i8BfZ7b9N4SVZlGl
R0lT6v3kWhx999Rth9PoYl0d645iu0fu/+/DGnAb4AG2Utn4cB33YntZMUHTX1WqlImW
vQtlvZhGNLBNJG/ROOrQ8mr2lK8wtrDwM4ToAu8B9ORQztce3k53PXjEYlOjNAZnZu1j
sCd5XoW32FyFZzWim7cUr2wl0AGY7ZfFcx2gRgHEQPeLFks4PYV568yBmbSG5LnKumRj
F0RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:in-reply-to:references:date
:message-id:mime-version;
bh=nGIZlu+tp3GPK7vf93qSXBwMfKj66R/duZu7SKH5l+Y=;
b=k2kI9MQOi8MfQ3zHf64pCer1yrjPxw8RutAhsN3Oqx1gg/3zbxg/kcAemC12ydCKC6
UajHySFCdXQzAYpYEGq3BeHYEn6kqAcLDqUc6/qK+vpihxf/YiE9R51YX3bFiWrtidMO
VmKGliQ4sd4airUhffyGGv/Z2Z+u3v7zJvqgWeZ3md8oMR8CWZmVx4wlmeTENjPENTon
VlAHP8evXjwAz/wf7PnnRbZsnMDbwE6mkU9pkINcn87QIPpuWhwVpZTPJOX9lJydWFha
QElDgCnAw3+jR5AMslrhQm31S9CFQsskM1JjS71U41cR9VEno1n5rIs/qiGmU6x9iK6u
6q2w==
X-Gm-Message-State: AA+aEWZDCSFY6KGKPiREQIEvMK1ZmG1lO4u4qrv8s7L2I2VbHRTx/Fac
nSRw8cpSYwDlTaQlOHG4T9Q=
X-Google-Smtp-Source: AFSGD/XeyXU+37bEWYf5+1Qhokw3r/hvNKiFKOPh9ZBQhZf1K8Q+l5MLZshuDdj9isN7uk3kHuRnjA==
X-Received: by 2002:a50:b082:: with SMTP id
j2-v6mr5335573edd.150.1542799253467;
Wed, 21 Nov 2018 03:20:53 -0800 (PST)
Received: from localhost ([2a02:aa16:1102:5480:1115:8f2f:6db1:5c0a])
by smtp.gmail.com with ESMTPSA id q4sm9528274eda.50.2018.11.21.03.20.52
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Wed, 21 Nov 2018 03:20:52 -0800 (PST)
From: Christian Decker <decker.christian@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
Date: Wed, 21 Nov 2018 12:15:44 +0100
Message-ID: <87k1l6d6lb.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
X-Mailman-Approved-At: Thu, 22 Nov 2018 14:08:02 +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: Wed, 21 Nov 2018 11:20:55 -0000
Hi Pieter,
great proposal, I think this may address some of the (perceived)
downsides of BIP118, by committing to the script when possible
(always?). One minor thing that I noticed a while ago and that I meant
to fix on BIP118 is that `hashSequence` does not need to be blanked for
eltoo to work (since where it is needed we also use `sighash_single`),
so I'm tempted to remove that redundant blanking. It may not make a lot
of difference but it'd limit the ability to change the number of inputs
to a NOINPUT transaction (this now being the only field that commits to
the set of inputs).
As for your proposal, I really like the `sighash_scriptmask` proposal,
and committing to the fees (with the `nofee` escape hatch) also works
seems also a nice fix. My one concern is that introducing a new opcode
to mask things in the sighash looks like a similar layering violation as
`codeseparator` was, but that's just a minor issue imho.
Cheers,
Christian
Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> Hello everyone,
>
> For future segwit versions, I think it would be good add a few things
> to the sighash by default that were overlooked in BIP143:
> * Committing to the absolute transaction fee (in addition to just the
> amount being spent in each input) would categorically remove concerns
> about wallets lying about fees to HW devices or airgapped signers.
> * Committing to the scriptPubKey (in addition to the scriptCode) would
> prevent lying to devices about the type of output being spent, even
> when the scriptCode is correct. As a reminder, the scriptCode is the
> actually executed script (which is the redeemscript in non-segwit
> P2SH, and the witnesscript in P2WSH/P2WPKH).
>
> As this implies additional information that may not be desirable to
> commit to in all circumstances, it makes sense to make these optional.
> This obviously interacts with SIGHASH_NOINPUT, which really adds two
> different ways of rebinding signatures to inputs:
> * Changing the prevout (so that the txid doesn't need to be known when
> the signature is created)
> * Changing the script (so that the exact scriptPubKey/redeemScript/...
> doesn't need to be known when the signature is created)
>
> Of course, the second implies the first, but do all use cases require
> both being able to change the prevout and (arbitrarily) changing the
> scriptPubKey? While BIP118 correctly points out this is secure if the
> same keys are only used in scripts with which binding is to be
> permitted, I feel it would be preferable if signatures/scripts would
> explicitly state what can change. One way to accomplish this is by
> indicating exactly what in a script is subject to change.
>
> 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.
> * The scriptPubKey being spent is added to the sighash, unless
> SIGHASH_SCRIPTMASK is set.
> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.
> * hashPrevouts, hashSequence, and outpoint are set to null when
> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
>
> So my question is whether anyone can see ways in which this introduces
> redundant flexibility, or misses obvious use cases?
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
