summaryrefslogtreecommitdiff
path: root/a5/5b6bfc9e747c551e657ab41979da7f37022578
blob: 6439290719683ee7f440b3ea7d80b51a323cf3d2 (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
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
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 484ABC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 00:46:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with UTF8SMTP id 2198560681
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 00:46:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level: 
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with UTF8SMTP id U1FkaunXan_U
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 00:46:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net
 [IPv6:2620:6e:a000:dead:beef:15:bad:f00d])
 by smtp3.osuosl.org (Postfix) with UTF8SMTPS id DBBD06060A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 00:46:18 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 222FB5198B2;
 Wed,  7 Apr 2021 00:46:17 +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=1617754864; t=1617756377;
 bh=3Fkm6GbSZedByipcUPL1orwQgJC+rlZqm7axTKEGt+Y=;
 h=Date:Subject:To:References:From:In-Reply-To:From;
 b=bi+expxRX1Cq5CLs+CFhaTRtVWONXWu8/0EeDi4J92Fpk5gU2SrrZafc+ZCyG0lVj
 DV+7LNmnxSQMwvnJQpFG/n7yZmuqvlGvP5x0Y+Py1LnDoXzhhKJXMGzo4VO3DpPF4B
 N5NNKqx/Pknv3yQy18cO/prpaaUVg1Ed6U36C7GDqZ+idLLQTY023G/HkzGLRimfzW
 wuAHrX+kRu8QAPdSgYJxdSdi+knzMnq2OXywV63u+GfdsYUO6XNFoIkF/C1ferCBAr
 yTn/bA+MnZpW/vg1M0hjd1QMufuAENl4aPORo1WOGg8VOEfosriofm0BiXisPusWfd
 kss0AXraNKu6A==
Message-ID: <a496407f-f58c-8099-355b-e32e4e97c6cb@mattcorallo.com>
Date: Tue, 6 Apr 2021 20:46:16 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Jeremy <jlrubin@mit.edu>
References: <CAD5xwhh=E00DVxqhZc7gDTBXtA-_HgybEaP_ysnA4n6AAVbWsA@mail.gmail.com>
 <87o8esja94.fsf@rustcorp.com.au>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <87o8esja94.fsf@rustcorp.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Response to Rusty Russell from Github
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: Wed, 07 Apr 2021 00:46:20 -0000

I'm somewhat gobsmacked that this entire conversation hasn't included the word "market" in it at all. If there's one 
thing we can all agree we learned from Segwit2x, BCH, BSV, BU, etc, its that, ultimately, the market decides. Not only 
does the market decide, but there's lots of money to be made by being the market maker or operator letting the market 
make its voice heard. There is nothing we can, or should, do to ensure the market can make its voice heard - it always will.

We don't need to bend over backwards to make sure individual users are forced to try to form consensus among themselves 
via options or chain splits, we can just let the market decide. Within reason, the market will probably decide "yep, 
what the brains are doing looks good, Bitcoin needs to stay in consensus, no point in trying to nitpick something or 
we'll never come to consensus about anything". If what's being proposed is ever disagreed with by some small-ish but 
nontrivial group, futures markets are going to decide the fate of the system no matter what the consensus rules or 
activation method is, why do we need to do very much else?

Matt

On 4/6/21 00:40, Rusty Russell via bitcoin-dev wrote:
> Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
>> Where I disagree is that I do not believe that BIP8 with LOT configuration
>> is the improved long term option we should ossify around either. I
>> understand the triumvirate model you desire to achieve, but BIP8 with an
>> individually set LOT configuration does not formalize how economic nodes
>> send a network legible signal ahead of a chain split. A regular flag day,
>> with no signalling, but communally released and communicated openly most
>> likely better achieves the goal of providing users choice.
> 
> You're ignoring the role of infrastructure.  It's similar to saying that
> there is no need for elections: if things are bad enough, citizens can
> rise up and overthrow their government.
> 
>> 1. Developers release, but do not activate
>> 2. Miners signal
>> 3. Users may override by compiling and releasing a patched Bitcoin with
>> moderate changes that activates Taproot at a later date. While this might
>> *seem* more complicated a procedure than configurable LOT, here are four
>> reasons why it may be simpler (and safer) to just do a fresh release:
> 
> Users may indeed, fire the devs and replace them, as this implies.  This
> is not empowering users, but in effect risks reducing their role to "beg
> the devs or beg the miners".
> 
>> A. No time-based consensus sensitivity on when LOT must be set (e.g., what
>> happens if mid final signal period users decide to set LOT? Do all users
>> set it at the same time? Or different times and end up causing nodes to ban
>> each other for various reasons?)
> 
> Yes, this Schelling point is important.  If you read BIP-8, you will see
> that LOT=true activates at the last moment for this very reason.
> 
>> B. No "missed window" if users don't coordinate on setting LOT before the
>> final period -- release whenever ready.
> 
> Of course there is: they need to upgrade in time.
> 
>> C. ST fails fast, permitting users ample time to prepare an alternative
>> release
> 
> You'd think so, but given the confusion surrounding Segwit, it seems a
> year was barely time to debate, decide and coordinate.  You want this
> ready to go at the *beginning* of the 1 year process, not being decided,
> debated, build and deployed once the crisis is upon us.  That existing
> deployment is a vital stake in the calculus of those who might try to
> disrupt the process for any reason.
> 
>> D. If miners continue to mine without signalling, and users abandon a
>> LOT=true setting, their node will have already marked those blocks invalid
>> and they will need to figure out how to re-validate the block.
> 
> This is true, in fact, of any soft fork: a Luke points out, our lack of
> revalidation of blocks after upgrade is a bug.  Which should be fixed:
> IMHO a decent PR to make LOT runtime configurable would reevaluate any
> blocks >= timeoutheight-2016 when it is altered.
> 
>> RE: point 3, is it as easy as it *could* be? No, but I don't have any
>> genius ideas on how to make it easier either. (Note that I've previously
>> argued for adding configurable LOT=true on the basis that a user-run script
>> could emulate LOT without any software change as a harm reduction, but I
>> did not advocate that particular technique be formalized as a part of the
>> activation process)
> 
> BIP-8 (with the recent modifications to allow maximal number of
> non-signalling blocks) is technically as fork-preventative as we can
> seek to make it.
> 
> I am hopeful that our ecosystem will remain harmonious and we won't have
> to use it.  But I am significantly more hopeful that we won't have to
> use it if we have it deployed and ready.
> 
> Cheers,
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>