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
|
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 66A63E35
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 May 2018 01:58:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f181.google.com (mail-ot0-f181.google.com
[74.125.82.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0B3DB180
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 May 2018 01:58:12 +0000 (UTC)
Received: by mail-ot0-f181.google.com with SMTP id i5-v6so63121otf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 May 2018 18:58:12 -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=oUSwTy9Sy7fJJruWc/1++lXmpV1IyF2v056T9YyxCc8=;
b=RnN9PI9Nhhr0PaHhhgLkfv4m8BS2oJ8qPUE3/mnGNk7JYUXOOdwk1OSAnIM9gWSVA1
cQjgn6NKQZc5r++c0qK5aV+ZEO0Gi33WztrzGufxKq0ZGmgaWtOTV83m/uYgmojH3rgA
hJEbN8qz5tMBDsgokTkRXWRH9xpe7aqjlsrtBC+qDigQpU1xsk1M9nKMCNB2FOGsjy7m
CyAEgQHAmBX3VGfXJJpCdEE4tlFZcsp+r83V4OXME2hHQtVwqLnuVBFiCZWuuA2ts4Do
ccWoFyZ4ElsrSw7trsAxZs5JX/ccFepPhqczCGDm2jzhQ3wK1jTzzdpQbJBNmbWwChH1
Sejw==
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=oUSwTy9Sy7fJJruWc/1++lXmpV1IyF2v056T9YyxCc8=;
b=iPWt0eOC/wruFvuCjp7TBcCnGueyZQHx4dz2X3w6vVuSk3/E1b1wH88K37oAswho+I
ex249Gic3kwUgAOkRma5Km39vrrqQx7feMNGFM46cl3T+R2+DAmvrbSsKD+eassCSd3u
xRXCuVF4Q8YeZBmwa5zt+QvZrdHPFskfmaJYSugS6ylChhaOt8em69AAmNGSUJLQZssJ
6GixBq4sfYVrW6ahOGx8OcjtTQjBQ8VOT1Vv4wGkndOdPhv1+/6SJ3DRGikwlPlQ00wL
ZAp54UtTda9cgAvg78vxBWgbt7E0VoJhRsZy85+FjAU4s1597hZ+oVUQWJWg167tjDII
fb3g==
X-Gm-Message-State: ALKqPwfdS9NvFOJeuGitwVbIgfxPxOZxnYZM/GUT7G8GR3fLt/qzxmQ4
OAnKJDvGPuBYAM8l7ONGnAJ0BDajHLgvQ7JFVV+CfA==
X-Google-Smtp-Source: AB8JxZqDqvN8bXQrJWAj7zugGP7XRTmX7EZamSxd3EwUMhZlkLfzJH2dIfev+CxiQFpRXaOXSBICEpm+gGc0xcRPFWk=
X-Received: by 2002:a9d:4377:: with SMTP id
y52-v6mr3533750oti.170.1527127091979;
Wed, 23 May 2018 18:58:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:6ac8:0:0:0:0:0 with HTTP; Wed, 23 May 2018 18:58:11
-0700 (PDT)
In-Reply-To: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
References: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 23 May 2018 18:58:11 -0700
Message-ID: <CAPg+sBh4CESPV_5TpPn0H3Zpv2Ump_0txxS63W_S2f3Lxezq1A@mail.gmail.com>
To: Bitcoin Dev <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: Thu, 24 May 2018 01:58:13 -0000
On Tue, May 22, 2018 at 11:17 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> Hello all,
>
> Given the recent discussions about Taproot [1] and Graftroot [2], I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending path. I have no strong
> reasons why this would be necessary, but I'd like to hear other
> people's thoughts.
Thanks everyone who commented so far, but let me clarify the context
of this question first a bit more to avoid getting into the weeds too
much.
If it turns out to be necessary to explicitly commit to permitting
Graftroot spending, there are a number of approaches:
* Use a different witness version (or other marker directly in the
scriptPubKey) to enable Graftroot.
* Signal the permission to spend through Graftroot inside the Taproot
script as suggested by ZmnSCPxj.
* Make "Spend through Graftroot" a special script (possibly indirectly
with a Merkle tree in Taproot).
* Implement Graftroot as an opcode/feature inside the scripting
language (which may be more generically useful as a delegation
mechanism).
* Postpone Graftroot.
All of these are worse in either efficiency or privacy than always
permitting Graftroot spends directly. Because of that, I think we
should first focus on reasons why a lack of commitment to enabling
Graftroot may result in it being incompatible with certain use cases,
or other reasons why it could interfere with applications adopting
such outputs.
@Natanael: all of these concerns only apply to a new hypothetical
Taproot/Graftroot output type, which combines pay-to-pubkey and
pay-to-script in a single scriptPubKey that just contains a public
key. It doesn't apply to existing P2SH like constructions.
Also, the concern of making Graftroot optional does not apply to
Taproot, as the Taproot spending path's script is committed to (using
scriptPubKey = P + H(P,script)*G), allowing the script to be
explicitly chosen to be a non-spendable script, which the author could
prove is the case (without revealing it to the entire world).
It is also always possible to create a "script only" Taproot output
(without key that can unconditionally spend), by picking a pubkey that
is provably unspendable (hashing onto a curve point, in particular),
or through pubkey recovery.
Cheers,
--
Pieter
|
