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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 06F35C000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Apr 2021 11:11:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id E2B5C6079C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Apr 2021 11:11:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 3.687
X-Spam-Level: ***
X-Spam-Status: No, score=3.687 tagged_above=-999 required=5
tests=[BAYES_50=0.8, KHOP_HELO_FCRDNS=0.399, LOTS_OF_MONEY=0.001,
MONEY_NOHTML=2.484, SPF_HELO_NONE=0.001, SPF_NONE=0.001,
UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id FwAozimt-5KO
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Apr 2021 11:11:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp3.osuosl.org (Postfix) with ESMTPS id AF81960703
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Apr 2021 11:11:18 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1lUSZ3-0004NX-T4; Thu, 08 Apr 2021 21:11:13 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 08 Apr 2021 21:11:06 +1000
Date: Thu, 8 Apr 2021 21:11:06 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210408111106.GA31864@erisian.com.au>
References: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
<874kgkkpji.fsf@rustcorp.com.au>
<CAMnpzfopMNO=73wqvXpOn9u8X4MwJArqGxODJAS4-9iFiZOd6A@mail.gmail.com>
<87pmz6it7q.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87pmz6it7q.fsf@rustcorp.com.au>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: 6
X-Spam-Bar: /
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
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: Thu, 08 Apr 2021 11:11:20 -0000
On Wed, Apr 07, 2021 at 02:31:13PM +0930, Rusty Russell via bitcoin-dev wrote:
> >> It's totally a political approach, to avoid facing the awkward question.
> >> Since I believe that such prevaricating makes a future crisis less
> >> predictable, I am forced to conclude that it makes bitcoin less robust.
> > LOT=true does face the awkward question, but there are downsides:
> > - in the requirement to drop blocks from apathetic miners (although
> > as Luke-Jr pointed out in a previous reply on this list they have
> > no contract under which to raise a complaint); and
> Surely, yes. If the users of bitcoin decide blocks are invalid, they're
> invalid.
That's begging the question though -- yes, if _everyone_ decides bitcoin
works such-n-such a way, then there's no debate. But that's trivial:
who's left to debate, when everyone agrees?
On the otherhand, if people disagree with you, who's to say they're in
the minority and "the users" are on your side?
> With a year's warning, and developer and user consensus
> against them, I think we've reached the limits of acceptable miner
> apathy.
The question is "how do you establish developer and user consensus?"
In particular, if you're running a business accepting payments via
"bitcoin", how do you know what software to run to stay in consensus
with everyone else running bitcoin, so you know the payments you receive
are good?
Ideally, we try to make the answer to that trivial: just download any
version of bitcoind and run it with the default configuration. More
recent (supported) versions are better due to potential security fixes
and performance improvements, of course.
> > - in the risk of a chain split, should gauging economic majority
> > support - which there is zero intrinsic tooling for - go poorly.
> Agreed that we should definitely do better here: in practice people
> would rely on third party explorers for information on the other side of
> the split. Tracking the cumulative work on invalid chains would be a
> good idea for bitcoind in general (AJ suggested this, IIRC).
Those measures are only useful *after* there's been a chain split. I'm
certainly in favour of better protections like that -- adversarial
thinking, prepper-ism, whatever -- but we should be trying really hard to
avoid ending up in that situation; and even better to avoid even ending
up *risking* that situation.
> Again, openly creating a contingency plan is not brinkmanship,
I think the word "brinkmanship" is being a bit overused in this thread...
lockinontimeout is designed for a chain split -- its only action is
to ignore one side of a split should it occur. That's not useless --
splitting the chain is a plausible scenario in the event of someone
dedicating something like $200M+ per week to attacking bitcoin, and we
should have contingencies in place for that sort of thing.
But it's like carrying a gun around -- yeah, there are times when that
might be helpful for self-protection or to put a tyrant into the ground;
but putting it down on the table everytime you sit down for a coffee*
and tapping it and saying "look, I'm sure you'll do the right thing and
serve me properly and I'll leave happy and give you a big tip; this is
just a contingency plan" isn't super great.
And even then, lockinontimeout isn't really a very *good* contingency
plan in the event of a chain split: if your side of the split isn't
in the majority, you're relying on the other side -- the one with all
the money -- being stupid and not having a dontlockinever=yes option to
protect them from wipeout, and without a hardfork to change proof-of-work
or the difficulty adjustment, you'll have enormous difficulties getting
blocks at all.
* The only thing worth spending bitcoin on.
> I think we should be normalizing the understanding that bitcoin users
> are the ultimate decider.
Yes.
What we shouldn't be normalising is that the way users decide is by
risking their business by having their node reject blocks and hoping
that everyone else will also reject the same set of blocks.
(After all, businesses handling lots of bitcoin being willing to force
the issue via running node software that rejects "invalid" blocks,
was the whole plan for making s2x a fait accompli...)
I've written up what I believe is a better approach to dealing with
the possibility of miners not upgrading to enforce a soft-fork quickly
here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018723.html
I belive it would be straightforward to implement that after a failed
speedy trial; technically anyway.
Cheers,
aj
|
