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
154
155
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 510E4C3D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Jun 2018 17:04:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f195.google.com (mail-ot0-f195.google.com
[74.125.82.195])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D7A1E4F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Jun 2018 17:04:25 +0000 (UTC)
Received: by mail-ot0-f195.google.com with SMTP id l15-v6so7081860oth.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 06 Jun 2018 10:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=52MLq8sD3jiqndaOKoOBeM//wfseldiycy8KdJllgws=;
b=O3l/xjpN9x8tlKS2FuOC/K2TCIZP8shpgh/v7SVKSr+KkOU0GYjt7ME6ejOCxywRFw
jc1X3zf6Efzc2UVCZfUce14vtSv+lPGRjrAPS87oBoCtyGN04t8OElkhVOnTTYWVi/fl
vd5XZbB1rxT+mAH5Y5yGbVXvzrWRw063Tbs3LQ+94N95T/dk9jG/JU7aHAqol4f78r9S
8gPr9zqE1IK4801NXEP6XSi0EeQzDQC9CNwVb5XkWwPrG+YxeyiE5Czs5dphzTUHmfUo
aX09VlVvTKX4L7AsrWeutXgFGq8hTcjDkyd9JY3nLTor4y63D2Y6A6oTRZtXlGrJYJ+1
mJSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=52MLq8sD3jiqndaOKoOBeM//wfseldiycy8KdJllgws=;
b=FzM7KNAQcstry/qe8aOu1XVfgpohrSLlM15vtMC7LP6QCcSO1KjvFjYEEDvo/TVHIR
1cR7fG9kOIokMtzZTlmPLG20r2uczx9h/AXlwfnAxWnkKJUFYgpueeyqIItjGni0M5EJ
7ZB0xR/X5Y8WYP519p3wPnIBLxO4RgykL0HI5nbnZ8jQSv46+sXXfYv8tzukJTcxZAAI
bw1QJsw/5zGVV0iA226EYqbaDgTRFCHNIhbldhbA/+dPJCo05TJLUJ0UqSFIIlXGzJwg
MKaKfMYhra2aoRCas/1YBvpjyg/ZPnVkADR8p8z59F/0cu5cwnJuhupxJFnfolkk2/Ll
l5Dw==
X-Gm-Message-State: APt69E1BckIOHhXqWCB4D6igYARuAHd76tkqsDuo5gqs04YWlxXZikna
GbD5EiKpDBia5vaq7JxwNRfrQLmovIV/5Jl/t/qQBg==
X-Google-Smtp-Source: ADUXVKLDxgRGF6fMZnHpMuqvve42bhnE3k1JDTiiqKj+ON99a3kEbdpaLg18eRAd4wFai1cyjx+7nI+Wx3M02czkHgo=
X-Received: by 2002:a9d:2f91:: with SMTP id
r17-v6mr2670611otb.356.1528304664840;
Wed, 06 Jun 2018 10:04:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:6a89:0:0:0:0:0 with HTTP;
Wed, 6 Jun 2018 10:04:23 -0700 (PDT)
In-Reply-To: <f5c0012e55242d85ec2cc740cc8d081ef5da9145.camel@timruffing.de>
References: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
<CAPg+sBh4CESPV_5TpPn0H3Zpv2Ump_0txxS63W_S2f3Lxezq1A@mail.gmail.com>
<CAAS2fgRXYtTyqqQp8Ehs_q_KsT7usA+vYSmngStnndd1rWNVNw@mail.gmail.com>
<D996F4E8-ACC6-4A49-B841-0F3285344DF6@xbt.hk>
<CAPg+sBgEUV5KNFi1L4MhR-3KAX9gbQKdzWneaEzF+QsKSXYu8A@mail.gmail.com>
<f5c0012e55242d85ec2cc740cc8d081ef5da9145.camel@timruffing.de>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 6 Jun 2018 10:04:23 -0700
Message-ID: <CAPg+sBhYkQdjDcKvxUiGZCs220N0dqRMYoweCbOB2dgzD9UpzA@mail.gmail.com>
To: Tim Ruffing <crypto@timruffing.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
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
Subject: Re: [bitcoin-dev] Should Graftroot be optional?
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, 06 Jun 2018 17:04:26 -0000
On Wed, Jun 6, 2018 at 5:48 AM, Tim Ruffing via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote:
>> The best argument for why Graftroot does not need to be optional I
>> think was how Greg put it: "since the signer(s) could have signed an
>> arbitrary transaction instead, being able to delegate is strictly
>> less
>> powerful.".
...
> So
> I think Graftroot delegation is not "strictly less powerful" than just
> using a normal transaction: Graftroot enables to delegate in a way such
> that the delegation itself cannot be fixed in the chain. I think this
> is not possible currently. (Okay, you can just pass around the secret
> keys but has other problems obviously).
>
> Does this have practical implications?
> I don't see any but maybe this helps someone to identify an undesirable
> implication.
Interesting point; I don't see any relevant implications to this
either, but it's indeed good to point out this as a distinction.
> One way to be on the safe side and probably make Greg's argument go
> through is to just define the semantics such that (*) is allowed, i.e.,
> call g-sig a "Graftroot transaction" and give it transaction semantics.
> This provides a new perspective on Graftroot: Then Graftroot does not
> introduce new semantics but (*) is just an optimized version of (**)
> that uses fewer bytes and may be better for privacy.
So you're saying: the Graftroot signature data could be made identical
to the signature hash of an implicit 1-input-1-output transaction
spending the coin and creating a new output with the delegated script
as sPK, and the same amount.
I like that idea, but I don't think it can be *exactly* that. If it's
possible to take a Graftroot signature and instead construct a
transaction with it, you have inherently introduced a malleability.
The created outpoint will be different in both cases (different txid),
meaning that a chain of dependent unconfirmed transactions may be
broken by giving one participant the ability to choose between
Graftroot delegation or actual spending.
Two points here: (1) the implicit transaction would be 0 fee (unless
we somehow assign a portion of the fee to the delegation itself for
purposes of sighash computing), and (2) this sounds very similar to
the issue SIGHASH_NOINPUT is intended to solve. About that...
> Interestingly Andrew's blind-sig example and Johnson's fix (g-sig signs
> the outpoint) are just a special case. If g-sig has transaction
> semantics, it must sign the outpoint (and other stuff).
You're right when you're comparing with existing transaction sighash
semantics, but not when SIGHASH_NOINPUT would exist. If that were the
case, the only real difference is your point above of not being able
to commit the implicit transaction separately. In other words, we're
back to something Johnson pointed out earlier: some of the perceived
problems with Graftroot are also issues with SIGHASH_NOINPUT.
I wonder if we can make this explicit: Graftroot spending becomes a
special sighash flag (which possibly is only allowed at the top level)
- it builds an implicit transaction which moves all the coins to a
newly provided script, computes the sighash of that transaction
(taking all of the Graftroot signature's sighash flags into account -
including potentially SIGHASH_NOINPUT), and requires a signature with
that. The delegated script is then evaluated in the context of that
implicit transaction.
However, in order to avoid the malleability issue I think the actual
signature should still be different - possibly by simply passing
through the Graftroot sighash flag into the sighash being computed.
Cheers,
--
Pieter
|
