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
|
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 D805DC000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 17:48:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id CF4DA86CBA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 17:48:04 +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 EmEQiBYZMQ9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 17:48:03 +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 7A85086B2F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 17:48:03 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 5D35A4A6D85;
Fri, 19 Feb 2021 17:48:00 +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=1613755263; t=1613756880;
bh=LjQZ/G1wSv9l27b9rAIaKtlIDT2w93hep/rH9DdyL/0=;
h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
b=nYM0N6rOkYxRkIZlD3mDdkg741s8KVI0ebZe5kaJJEHJb0A25l5cAcNPlDZ/Ai2P7
8GXg9nBLDCcmjNV62Dk7k1l1y6xNVPFDwrMDEKApNf0xULkjzcq28b9mv1jbXTANpi
kx/E87y7jt2R52T52RlS9UXfARSUCd9dUTFZph1Nq9cuOgGkz887Kjx0O00uugqSin
f1YDJasQntZL35iyLzNgLdPA4A8X1fnynUBSzNXbk+aXekiygs/BKnqFDKGBJ6zA+Z
3U/ozldE+YySNVBnC5HAdYQvkFulQSEH8+N4XZVnbk8UdU7Bx6e46zvOkzq6Luz7LP
tAQPQNn09iorA==
Message-ID: <ce8925d5-d2f1-1adb-530d-36f89f5b6352@bluematt.me>
Date: Fri, 19 Feb 2021 12:48:00 -0500
MIME-Version: 1.0
Content-Language: en-US
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Adam Back <adam@cypherspace.org>, ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <CALqxMTFKbjg3yDPnrmL8TgtypirB_fDMMJD=AJxjYav51hmEAw@mail.gmail.com>
<E3E39A9A-82B4-4096-9DA1-A4D758CC7B68@mattcorallo.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <E3E39A9A-82B4-4096-9DA1-A4D758CC7B68@mattcorallo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Michael Folkson <michaelfolkson@gmail.com>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
lockinontimeout (LOT)
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: Fri, 19 Feb 2021 17:48:04 -0000
It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an
option like this is likely not practical/what people would wish to see.
Bitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with
uasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to
enable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles
needed seem to be not worth it.
Instead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest,
testnet, and signet are treated), including its own separate datadir and the like.
Matt
On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:
> (Also in response to ZMN...)
>
> Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks.
>
> There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit).
>
> Matt
>
>> On Feb 19, 2021, at 07:08, Adam Back <adam@cypherspace.org> wrote:
>>> would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
>>
>> given there are clearly people of both views, or for now don't care
>> but might later, it would minimally be friendly and useful if
>> bitcoin-core has a LOT=true option - and that IMO goes some way to
>> avoid the assumptive control via defaults.
>
>> Otherwise it could be read as saying "developers on average
>> disapprove, but if you, the market disagree, go figure it out for
>> yourself" which is not a good message for being defensive and avoiding
>> mis-interpretation of code repositories or shipped defaults as
>> "control".
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
