summaryrefslogtreecommitdiff
path: root/56/d505c47fadb8169f960279c6deb85e5b2d082f
blob: 49e4760de0eb6f93471bb9da59d99b3edfb8d268 (plain)
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
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F132AC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 16:45:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with UTF8SMTP id ED1004EF4D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 16:45:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5
 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
 DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with UTF8SMTP id G1qPJ-nisQLX
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 16:45:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
 by smtp4.osuosl.org (Postfix) with UTF8SMTPS id 5D6FA4EF49
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 16:45:25 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 1130F4BDCB8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 28 Feb 2021 16:45:23 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
 s=1614529264; t=1614530723;
 bh=5vIZs5f2kbAljXkOUbBOlVh3avtuT4rEm2Jhm01JBJc=;
 h=Date:To:From:Subject:From;
 b=ON2pRfEb51libG6keOaqZPrOkJzOZQQgmtj3hXbrZ3NPD0qc17hNctl2KJBftdiYJ
 VK0oXXi6KAahVd9bssXm0FhSbVaRYxIsF3nGxKtTp6pnkaw9/3X7bZZGxRhk1LkLP0
 01Zjy6XjsNUhUoVbg7Gl/RBemTs8fdlEefZTqVRETu5d+czsfx0vQTbzWcHrv2aJ1x
 5GBTv9xx1HnGpmVYPZLfeRreXIIXEzSFARQx/4oUpCcOkr+Lf71EQwIMxgSRzMoEvg
 ujVEtOEyzf5PArrJNX03TaJFNvBVgQV57drNAozas1UkGWq4CT1Esh/wAi0fDZCX39
 sYHH2utH42RRw==
Message-ID: <c35e1761-43ca-e157-6a5c-72d27f2c6c6e@mattcorallo.com>
Date: Sun, 28 Feb 2021 11:45:22 -0500
MIME-Version: 1.0
Content-Language: en-US
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
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, 28 Feb 2021 16:45:27 -0000

As anyone reading this list is aware, there is significant debate around the activation method for the proposed Taproot 
soft fork. So much so, and with so much conviction, that many individuals are committing themselves to running 
incompatible consensus rules. Obviously, such commitments, were they to come to pass, and were a fork to occur as a 
result, would do more harm than any soft-fork does good. Further, such commitments and debate have likely delayed any 
possible release of a future Taproot activation while issues around locked-in activation are debated, instead of 
avoiding it as was the original intent of the "just ship BIP 8 LOT=false and we'll debate the rest if we need to" approach.

Given this, it seems one way to keep the network in consensus would be to simply activate taproot through a traditional, 
no-frills, flag-day (or -height) activation with a flag day of roughly August, 2022. Going back to my criteria laid out 
in [1],

1) I don't believe we have or will see significant, reasonable, and directed objection. This has largely always been the 
case, but it is also critical that the lack of such objection is demonstrable to outside observers. Ironically, the 
ongoing debate (and clear lack of consensus) around activation methods can be said to have had that effect, at least as 
far as the active Bitcoin Reddit/Twitter userbase is concerned. In addition, the public support for Taproot activation 
made by mining pool operators further shows public review and acceptance. Ideally, large Bitcoin business operators who 
previously took part in Bitcoin Optech's Taproot workshop [2] would publicly state something similar prior to release of 
Taproot activation parameters. Because this expectation is social, no technical solution exists, only public statements 
made in broad venues - something which I'd previously argued comes through soft fork activation parameter deployment, 
but which can also come from elsewhere.

2) The high node-level-adoption bar is one of the most critical goals, and the one most currently in jeopardy in a BIP 8 
approach. Users demanding alternative consensus rules (or, worse, configuration flags to change consensus rules on 
individual nodes with an expectation of use) makes this very complicated in the context of BIP 8. Instead of debating 
activation parameters and entrenching individuals into running their own consensus rules, a flag day activation changes 
the problem to one of simply encouraging upgrades, avoiding a lot of possibility for games. Of course in order to meet 
this goal we still need significant time to pass between activation parameter release and activation. Given the delays 
likely to result from debates around BIP 8 parameters, I don't think this is a huge loss. Capitalizing on current 
interest and demand for Taproot further implies a shortened timeline (eg a year and a half instead of two) may be merited.

3) The potential loss of hashpower is likely the biggest risk of this approach. It is derisked somewhat by the public 
commitment of pool operators to Taproot activation, and can be de-risked further by seeking more immediate commitment 
prior to release. Still, given the desire to push for a forced-signaling approach by many, there is more significant 
risk of loss of hashpower in today's approach. In an ideal world, we could do something more akin to BIP 9/BIP 8(false) 
to reduce risk of this further, but its increasingly likely that this is not possible. A flag-day which takes advantage 
of the nonstandardness of Taproot transactions in current Bitcoin Core releases may suffice.

4) Similar arguments apply as the above around the public commitment from pool operators to enforce the Taproot 
consensus rules.

5) Similar arguments apply as the discussion in (1).


Ultimately, the risk which is present in doing flag day activations (and the reason I've argued against them as a 
"default" in the past) are present as well in BIP 8(true), forced-signaling activations where community debate splits 
the consensus rules across nodes. While such a deployment could delay Taproot somewhat, it sidesteps a sufficient amount 
of debate and resulting delay that I wouldn't be surprised if it did not. Further, Taproot has been worked on for many 
years now with no apparent urgency from the many who are suddenly expressing activation urgency, making it more likely 
such urgency is artificial. Those who seek Taproot activation for Bitcoin market reasons should also rejoice - not only 
can the market celebrate the final release of Taproot, but it gets a second celebratory event in 2022 when the 
activation occurs.

Matt


[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
[2] https://bitcoinops.org/en/schorr-taproot-workshop/