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
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
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 5C433E6F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 May 2019 23:07:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com
[209.85.167.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 928A9196
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 8 May 2019 23:07:04 +0000 (UTC)
Received: by mail-oi1-f174.google.com with SMTP id u199so463140oie.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 08 May 2019 16:07:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=CpC13BLNdkyDec1uNdUlJrTeXZE/RihAvf6LjgqqVk4=;
b=iYHdilWPcyFCGK9/XLupP+bdLcIa0KnbEALxs/AMgXLg1yRy/mCsGYpyjLCVIA5NE+
/3ZXcFIvSANIyK6i5y5Vp8pz8ua0dsMJGTsD2RTNU6e/Rt/o6Q2GmdlFi+3AMY7CcmfK
hMyJGOvlu67u1TgN2PsI5Ef9Y5BLeuzBGJw6U12ZfoabF7Ze20awuVotsEgG+p3lJwWG
1qb9HFlSOziiVCaQ7iEtSD+NQA+nZXMWZsjxBFW2nWk2ka/sadfFWwtahgKDWskPhq+I
Bcrf54bZFy4mrOqSA3VeDOSu25GCB6W513OOd7QXVo7X4j0MNIHkMVrjnywOoQAcATB1
eqzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=CpC13BLNdkyDec1uNdUlJrTeXZE/RihAvf6LjgqqVk4=;
b=lYmNAUbBk/H+zc/yyXr4h9ayOdlryaeE5+KDIrexqVM086hibwibe9a53iHR0eBoC0
AuU+MpRxWrv7Xh8nIoOVmlD8t2sROIBPEC2+Ge+/vwdRz4bGgmJTXBxH/+JB9kEl6e1J
SoHcPVomXZ3XnEVnQ9Vfj2u5SQz3aVftIrG0X5kno1tcqaBemTxK8jR4nhR9PJUNVbmS
T1F6UHXUnr2g4QB+rWo64qWos4fBWiPxeWTBd4CqxFdWPLrcows4WVbALuv2opCiWLGS
BY8KIbpYVp2KZK27C5vtxA0hAYOLUeIuZNVeQU1sFKhuVGT6aXIp7YwsXNQqXXur8pZU
mcjA==
X-Gm-Message-State: APjAAAXptgCHrEgmsUhuFSFfXPDxGCWDqAdeUu7qQxmZD8V9X+gVzyg/
/VRezvbIbZ8ygipWpJXqF30YO2Gwus5Wuvb9/uw=
X-Google-Smtp-Source: APXvYqyw4RJB25Wvj/S3KP4vd4UUO+giajVyW2DS88AowwYTnq/9Miv4+MZ5fx4nK8Pl8nrgHG7EWzgvQ3n3SYSxY2w=
X-Received: by 2002:aca:db45:: with SMTP id s66mr215918oig.59.1557356823621;
Wed, 08 May 2019 16:07:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
<201905062017.11396.luke@dashjr.org>
<34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl>
In-Reply-To: <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 8 May 2019 16:06:51 -0700
Message-ID: <CAPg+sBjqgyu=Do-8P=7Q1S3tehr30K58=o_SokAE7H_SP-pf8g@mail.gmail.com>
To: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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, 09 May 2019 14:48:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot proposal
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, 08 May 2019 23:07:05 -0000
Thanks for the comments so far!
I'm going to respond to some of the comments here. Things which I plan
to address with changes in the BIP I'll leave for later.
On Mon, 6 May 2019 at 13:17, Luke Dashjr <luke@dashjr.org> wrote:
> Tagged hashes put the tagging at the start of the hash input. This means
> implementations can pre-cache SHA2 states, but it also means they can't r=
euse
> states to produce data for different contexts. (I'm not sure if there is =
a
> use for doing so... but maybe as part of further hiding MAST branches?)
It's true you can't cache/precompute things across tags, but I also
think there is no need. The type of data hashed in a sighash vs a
merkle branch/leaf vs a tweak is fundamentally different. I think this
is perhaps a good guidance to include about when separate tags are
warranted vs. simply making sure the input does not collide: there
shouldn't be much or any shared data with things that are expected to
be inputs under other tags.
> Is there any way to use the Taproot construct here while retaining extern=
al
> script limitations that the involved party(ies) *cannot* agree to overrid=
e?
> For example, it is conceivable that one might wish to have an uncondition=
al
> CLTV enforced in all circumstances.
Yes, absolutely - you can use a point with unknown discrete logarithm
as internal key. This will result in only script path spends being
available. For the specific goal you're stating an alternative may be
using a valid known private key, using it to pre-sign a timelocked
transaction, and destroying the key.
> It may be useful to have a way to add a salt to tap branches.
If you don't reuse public keys, effectively every branch is
automatically salted (and the position in the tree gets randomized
automatically when doing so, providing a small additional privacy
benefit).
>> Some way to sign an additional script (not committed to by the witness
>> program) seems like it could be a trivial addition.
> This would be especially useful for things like OP_CHECKBLOCKATHEIGHT:
> https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki
If you're talking about the ability to sign over the ability to spend
to another script ("delegation"), there are lots of interesting
applications and ways to implement it. But it overlaps with Graftroot,
and doing it efficiently in general has some interesting and
non-obvious engineering challenges (for example, signing over to a
script that enforces "f(tx)=3Dy" for some f can be done by only storing
f and then including y in the sighash).
For the specific example of BIP115's functionality, that seems like a
reasonable thing that could be dealt with using the annex construction
in the proposed BIP. A consensus rule could define a region inside the
annex that functions as a height-blockhash assertion. The annex is
included in all sighashes, so it can't be removed from the input;
later opcodes could include the ability to inspect that assertion
even.
On Tue, 7 May 2019 at 13:43, Sjors Provoost <sjors@sprovoost.nl> wrote:
> One reason why someone would want to avoid a "everone agrees" branch, is =
duress (or self-discipline, or limiting powers of a trustee). In particular=
with respect to time-locks.>
Indeed, though as I suggested above, you can also use timelocked
transactions (but using only CLTV branches is more flexible
certainly).
> Can this "unknown discrete logarithm" be made provably unknown, so all si=
gners are assured of this property? Bonus points if the outside world can't=
tell. The exact mechanism could be outside the scope of the BIP, but knowi=
ng that it's possible is useful.
Yes, that's a TODO that's left in the draft, but this is absolutely
possible (using a hash-to-curve operation). As ZmnSCPxj already
suggested, there can even be a fixed known constant you can use for
this. However, you get better privacy by taking this fixed known
constant (call it C) and using as internal key a blinded version of it
(C+rG, for some random value r, and G the normal secp256k1 generator);
as long as the DL between G and C is unknown, this is safe (and does
not reveal to the world that in fact no key-path was permitted when
spending).
> Regarding usage of Schnorr: do I understand correctly that the "everyone =
agrees" internal key MUST use Schnorr, and that individual branches MAY use=
Schnorr, but only if they're marked as tapscript spend?
>
> Why is tapscript not mandatory?
Spending using the internal key always uses a single Schnorr signature
and nothing else. When you spend using a script path, you must reveal
both the script and its leaf version. If that leaf version is 0xc0,
the script is interpreted as a tapscript (in which only Schnorr
opcodes exist). If that leaf version is not 0xc0, the script is
undefined, and is unconditionally valid. This is one of the included
extension mechanisms, allowing replacing the whole script language
with something else, but without revealing it unless a branch using it
is actually used (different Merkle tree leaves can have a distinct
leaf versions).
So the reason that tapscript is not mandatory is because other leaf
versions are undefined, and left for future extensions (similar to how
future segwit versions at the output level are undefined).
Cheers,
--=20
Pieter
|
