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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4C5FFC0171
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:40:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 3B4B084D9F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:40:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ccPlm9r0aPK9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:40:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by whitealder.osuosl.org (Postfix) with ESMTPS id 8A82D84AB2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:40:44 +0000 (UTC)
Received: from [10.233.42.100] (unknown [69.59.18.156])
by mail.as397444.net (Postfix) with ESMTPSA id 81F4419BEF7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:40:40 +0000 (UTC)
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <2d9970d8-209d-7223-6564-ad858dce5981@mattcorallo.com>
Date: Sun, 9 Feb 2020 20:40:27 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity
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: Sun, 09 Feb 2020 20:40:45 -0000
Responding purely to one point as this may be sufficient to clear up
lots of discussion:
On 2/9/20 8:19 PM, Bryan Bishop via bitcoin-dev wrote:
> Is Taproot just a probability assumption about the frequency and
> likelihood of
> the signature case over the script case? Is this a good assumption? The BIP
> only goes as far as to claim that the advantage is apparent if the outputs
> *could be spent* as an N of N, but doesn't make representations about
> how likely
> that N of N case would be in practice compared to the script paths. Perhaps
> among use cases, more than half of the ones we expect people to be doing
> could be
> spent as an N of N. But how frequently would that path get used?
> Further, while
> the *use cases* might skew toward things with N of N opt-out, we might
> end up in
> a power law case where it's the one case that doesn't use an N of N opt
> out at
> all (or at a de minimis level) that becomes very popular, thereby making
> Taproot
> more costly then beneficial.
Its not just about the frequency and likelihood, no. If there is a
clearly-provided optimization for this common case in the protocol, then
it becomes further more likely that developers put in the additional
effort required to make this possibility a reality. This has a very
significant positive impact on user privacy, especially those who wish
to utilize more advanced functionality in Bitcoin. Further, yes, it is
anticipated that the N of N case is possible to take in the vast
majority of deployed use-cases for advanced scripting systems, ensuring
that it is maximally efficient to do so (and thereby encouraging
developers to do so) is a key goal in this work.
Matt
|
