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
|
Return-Path: <arielluaces@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5D018C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Feb 2021 22:37:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 36A3C43176
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Feb 2021 22:37:15 +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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id nd-xXf_jZdZz
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Feb 2021 22:37:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com
[209.85.167.53])
by smtp2.osuosl.org (Postfix) with ESMTPS id 28C814316E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Feb 2021 22:37:14 +0000 (UTC)
Received: by mail-lf1-f53.google.com with SMTP id f1so5577228lfu.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Feb 2021 14:37:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-transfer-encoding;
bh=kriK0xsfh/YqpZsz3qXTxWfsu4/7CoUnfJc4eeTSWGw=;
b=AjOxYEbU4qEqXzwrjuD3SuKLc6y2rcAxNa+cBHffe01LVFsiO66lbfoWRbB2gYSuSi
cEXkBdMdR+jLMRWjIfk/CGYHC9EJvP27i2BbfLz6i1psnS8GLhY7vXOJ59FLBM6iIt7Y
MViHANtrBzOq4FvQTl1HXosNL1iQs0463mEpnY4N0HcrCr0Bu1Ucl1d7z3OFfezfLm4J
dTFSdZG74A/yVkRgaVkTiTWoNWaydNG2k1/DjEohc+gsKfrA9H9wEIWTbAwD087ijLlL
NZrXuMDOkNoqxHg5/k/s3coxhfF3jHXjihOfb3hILVHQdMl5GqxPuVjh+wTiiE01OBp+
uizQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-transfer-encoding;
bh=kriK0xsfh/YqpZsz3qXTxWfsu4/7CoUnfJc4eeTSWGw=;
b=gNvem3O7xS1bUgmQlcL9eJVdc+fSrfrXc4SG3ikNzGVXvR31/pOOuGjKSIfCvd5nia
W0HXPqA8pijcg6DKmvQ6LWk4VxewmNejdVsYpOS79DeY0T3lot4o83uccOaroaTDjl7L
mvAHfyxeMQaBxMpMs2daV3zWGWAY58CZK7ju7IUVLchQVQ+1Om+peKTPnYSyReNpXSCw
i49w1hDap4aCUCdl7guS4HK3SkYsgaR0zFrCMGYpS7ESe+IpNH+dAjdA4cCbQeKJGOVn
lNpnpvOXGteEW3r/51YIGK8CMI+H5R8elC/LM07vRY+XQ4/rFc6h4Whq25z7WhsoPyGP
FAhg==
X-Gm-Message-State: AOAM530nOmF4gS9jbizaohBYBxLx1RnTCFd9rugkxjD/QhfIEEn6lTPn
NU9r9rzgmZRhQqPSuyjji0mbNRGVTXtX+y1gOvw=
X-Google-Smtp-Source: ABdhPJxe0acSWCR4YYQhbctwq8CunFzxPaOIYHGCIY00CjtBtyu4Atj4qRLkMPLs9S9O2QgWhAbjPEYhhsffG2CaQ38=
X-Received: by 2002:a05:6512:10c5:: with SMTP id
k5mr92562lfg.583.1614206231809;
Wed, 24 Feb 2021 14:37:11 -0800 (PST)
MIME-Version: 1.0
References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au>
<7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com>
<CABm2gDrbKdxMuKdwYh0HBXNUxhqWtq1x2oLC0Ni=dbfP8b_a7Q@mail.gmail.com>
<CABm2gDp5dRTrPEqPfrjOeeYBn6RMS=HFMbtkJ+MM0SMVnSfK5A@mail.gmail.com>
<CAD5xwhg0pWJykWUusdoNQd60L9_MgCzzky1dvViLERADMcoysQ@mail.gmail.com>
<CALeFGL1UbXx14aX7RK7nh7b4jwvmfF6AXrvqPJpriSB4ZvYT2A@mail.gmail.com>
In-Reply-To: <CALeFGL1UbXx14aX7RK7nh7b4jwvmfF6AXrvqPJpriSB4ZvYT2A@mail.gmail.com>
From: Ariel Luaces <arielluaces@gmail.com>
Date: Wed, 24 Feb 2021 14:37:09 -0800
Message-ID: <CAOv1TnhQcYrc5q6GTUTuQMEi9RAV4dy5mmyNp--HuYTPzEUfJQ@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 25 Feb 2021 11:43:04 +0000
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: Wed, 24 Feb 2021 22:37:15 -0000
On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> If social consensus is what drives technical consensus and not the other =
way around it seems as if there cannot exist a valid (rational?) reason to =
oppose Taproot itself, and then by extension with the arguments laid out ab=
ove, LOT=3Dtrue seems to be the logical conclusion of all of this, even if =
Core ships LOT=3Dfalse at the outset.
>
> Where am I wrong here?
>
> Keagan
>
> On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>>
>> Personally, I think with either plan the ultimate risk of forking is low=
given probability to activate before timeout, so we should just pick somet=
hing and move on, accepting that we aren't setting a precedent by which all=
future forks should abide. Given my understanding of the tradeoffs, I beli=
eve that the safest choice is LOT=3Dtrue, but I wouldn't move to hold back =
a plan of LOT=3Dfalse (but would probably take mitigative steps on communit=
y advocacy if it looks like there is non majority but non negligible LOT=3D=
true uptake).
>>
>> Cheers,
>>
>> Jeremy
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
To favor LOT=3Dtrue because it seems like the inevitable result is like
playing the prisoner's dilemma and never cooperating instead of using
the most optimal strategy which is tit-for-tat (cooperating at first
and then cheating once for every time your counterparty cheats).
During segwit users started by cooperating (BIP9, or "LOT=3Dfalse"),
then a minority of
miners didn't cooperate (small veto but remember the majority of
miners cooperated), then users stopped cooperating in response (UASF),
then miners
reverted to cooperating (MASF while intolerant miners forked off).
Today users should start cooperating again to continue using the
optimal strategy.
Cheers
Ariel Lorenzo-Luaces
|
