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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id D15B7C013E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Feb 2020 23:29:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id B3D1220489
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Feb 2020 23:29:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9-QOxWTZfjIv
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Feb 2020 23:29:33 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com
[209.85.210.44])
by silver.osuosl.org (Postfix) with ESMTPS id CC08F2000F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Feb 2020 23:29:33 +0000 (UTC)
Received: by mail-ot1-f44.google.com with SMTP id p8so21268849oth.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Feb 2020 15:29:33 -0800 (PST)
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; bh=5/97wtlfX8NqBsDRxFd9+C7VBzycha10rdee7psFiPA=;
b=hkc0K/Wq82lO3pTNevNsWozN7tqfNC1fxoxnY2gPVCkkGOOsi/DNH8jftjZ63CBSSx
sd4kH+JhKETG+qdPyqM/I7eQhGLvDOan16G8VLZpdeXYj8jNu0QOaD5DOnbXeTXzL94a
b21g4JAptbdINNqCORJVufmxv18tv4YnBsg9wc02UAoZRP8tri+4kIJDNi5MLIL2YqvC
GPjWfDMBx7u4W7bmtqKNIdmzrckXAdi4e3p18kfe5pduIgUnOgY7aP99WzAz4wdAX50x
rDK1qZyja6XSzN/xxDJRFROQrkjs5VncedThABoUi6BsQgEMg40bwyOWGYXTDeerUPNg
fDVQ==
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;
bh=5/97wtlfX8NqBsDRxFd9+C7VBzycha10rdee7psFiPA=;
b=RGCWNvqyE3g87RSG2MJcNP+plehXGaz2ChpmamikwYFbHXnY4SsytB83Vuy2hIDeA/
e6dUOM6asZgdrshs+Cv4W/7CjMLbrQoM20fq6haS1oz+ctU6b4gy8IOLL0r2LO7Nw2qe
8vFUhnoh0w4tAKWgmBFZ+19qqjaAgbO7fBrSxv4zPaHKRWw6kh51QcGWaZLxTJpiLFlp
KMbqldm7c+oYOh2TG5s+83jYgMvMOg+9x2paznAS8ddfnNvTMwioRjkthYaGIxxLdJUi
4Zxp+lbefMVbXWELi1GbxJ4btJYWAxzD4Zt7PnnNymdOFYJa8+EltHXNAZQtp1uU0lk+
zsgA==
X-Gm-Message-State: APjAAAVaMcylbyJwyaJWxrvs5A1GffYNA1bSM6LF8AYeYxjoHIHIcMp6
u+0FGTSwykpvz3PHq2akJspCnOyhrdFjUpwA+FU=
X-Google-Smtp-Source: APXvYqwGSAgDo0VzphW6gfaofOIYvS7ZD3m+2qI3g++k59Ra2d/D0YrMvwJSBSFQ+tkAWMvZfZj8d1NtJULpULp+lDI=
X-Received: by 2002:a9d:7357:: with SMTP id l23mr16929425otk.10.1582068572805;
Tue, 18 Feb 2020 15:29:32 -0800 (PST)
MIME-Version: 1.0
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
<CABaSBawPJnoxf+9A0ocG_yec2fga+e1w2tk8_Tr6oj+FomDZZQ@mail.gmail.com>
<d42234f4-411c-40a6-dcb8-b9408c21ef16@gmail.com>
<CAD5xwhh=71XDAcSCJL9AQhZOriWmdGq4C5xT34K5wjR_g7FDfA@mail.gmail.com>
<20200214223642.djdvosj7t7e6nrdz@ganymede>
In-Reply-To: <20200214223642.djdvosj7t7e6nrdz@ganymede>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Tue, 18 Feb 2020 15:29:21 -0800
Message-ID: <CAPg+sBiL-m4AM8NiJP24JxPYoA8i_ZO1RuvB7YL4qmXOUd0z_w@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 18 Feb 2020 23:29:37 -0000
On Fri, 14 Feb 2020 at 14:37, David A. Harding via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote:
> > Is the same if Schnorr + Merkle Branch without Taproot optimization, unless
> > I'm missing something in one of the cases?
>
> That's fair. However, it's only true if everyone constructs their
> merkle tree in the same way, with a single `<schnorr_pk> OP_CHECKSIG` as
> one of the top leaves. Taproot effectively standardizes the position
> of the all-parties-agree condition and so its anonymity set may contain
> spends from scripts whose creators buried or excluded the the all-agree
> option because they didn't think it was likely to be used.
>
> More importantly, there's no incentive for pure single-sig users to use a
> merkle tree, since that would make both the scriptPubKey and the witness
> data are larger for them than just continuing to use v0 segwit P2WPKH.
> Given that single-sig users represent a majority of transactions at
> present (see AJ Towns's previous email in this thread), I think we
> really want to make it as convenient as possible for them to participate
> in the anonymity set.
Right, I think we shouldn't just see Taproot as adding a possibility
of a cheap single-key branch to Merkle tree. It is actively choosing
to incentivize protocols and implementations that can use the key
path, making sure that the cheapest way spending of spending is also
the most private one - as we can assume that it indeed will be the
most frequent one. I don't believe having a separate MAST-no-Taproot
spending type (through whatever mechanism) is beneficial to that.
Taproot effectively gives everyone a "key path spend is included in
the price", making it maximally appealing even to those who don't care
about privacy.
I don't think this is an unreasonable angle. There are plenty of other
options that exists if we just want to make verification constructions
cheap but disregard incentives for privacy. For example, why don't we
research account-based state/payments? Being able to avoid change
would make simple payments significantly cheaper (both in terms of
block space and computation). Of course, the reason (or at least one
of them) is that it would result in a discount for those willing to
reduce their privacy (use accounts = reuse address = don't pay for
change), and this hurts everyone (and indirectly the fungibility of
the system as a whole). This is true even when there are use cases
that would legitimately benefit from having this option.
This is of course a much weaker case, but I think it is similar.
Having no-Taproot available would reduce the incentives for those who
don't care about spending policy privacy to put the engineering effort
into building key-path-spendable protocols and implementations - and I
think such protocols, wherever possible, should be the goal. There
probably are some use cases where key path spending is truly not an
option, but I suspect they're rare, or sufficiently high value that 8
vbyte differences don't matter to them. If that turns out to be wrong,
it remains possible to add a new output type/witness version that does
support them. This does mean distinguishable outputs, but only for
things that would be distinguishable at spending time anyway, and
that's a cost we'll have to pay anyway for future structural script
improvements (like cross-input aggregation or graftroot).
Cheers,
--
Pieter
|
