summaryrefslogtreecommitdiff
path: root/76/c10ef960402a28832bc4873b6a0bab7506fad2
blob: 2b5db1f112044a04628957aabc9d522856d98df8 (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
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CB3A0C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 14:42:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id B73728428E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 14:42:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id TGNO8KmjLpUl
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 14:42:46 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 11C8284287
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 14:42:45 +0000 (UTC)
Date: Wed, 09 Mar 2022 14:42:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1646836963;
 bh=9EqmcXCpNyZBkoC69m/smO3qBU2DAajmCpLTqZpPGp8=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=uuYIAZ9VTaNx/D17lIzcVLYXkLzdbMA/VkmrhzBzPKcOabToVkuGKqyYUisM44jJH
 FsOw/Hxgq75sYTHArzj1Fs0tsMFEGj3ziOwKIgOh7gbS/Rfmxky1WAiuz7M76IXnrp
 0Hlrh4ezA8XMOnpeT+nJMV7AR7E3CwCKlfYMrCeWlymY9g2ehOsEHPVYXxMUJ2uGhd
 UpCSuPEIqnyKnyCjhF/T/nm1gE2CyoV0djmDnWfOE4wr7nbbgGDmJR1M1A4XJ6fusr
 CPy2wbKAeZpgYzuei7BBpvY0rWRxZTGGnVSIv45hC+OZstiEiCfCBgdZV2qKDQ7tys
 B1XkgMyRabxSA==
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <CCrU07T0pDYBkAwCnUK3QZ3SFCtH1jSlH9ec6fUz5QxiNh7HT8lEx_2i6uR0Xedb6fdU94RZ4UXag9_Kchf6uELNjwSAxvyY4XgZ64aL-xI=@protonmail.com>
In-Reply-To: <CABm2gDqMcgcyYErNgMe9shXUxX5E85n+VqheDf1_E1mPq3ijLg@mail.gmail.com>
References: <CAD5xwhgvW_ATpWuMv1fF6hhjTyp8imkxfAY1CcCvYk1AwgqfhA@mail.gmail.com>
 <CABm2gDqMcgcyYErNgMe9shXUxX5E85n+VqheDf1_E1mPq3ijLg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5
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, 09 Mar 2022 14:42:46 -0000

Good morning Jorge,

> What is ST? If it may be a reason to oppose CTV, why not talk about it mo=
re explicitly so that others can understand the criticisms?

ST is Speedy Trial.
Basically, a short softfork attempt with `lockinontimeout=3Dfalse` is first=
 done.
If this fails, then developers stop and think and decide whether to offer a=
 UASF `lockinontimeout=3Dtrue` version or not.

Jeremy showed a state diagram of Speedy Trial on the IRC, which was complic=
ated enough that I ***joked*** that it would be better to not implement `OP=
_CTV` and just use One OPCODE To Rule Them All, a.k.a. `OP_RING`.

If you had actually read the IRC logs you would have understood it, I even =
explicitly asked "ST ?=3D" so that the IRC logs have it explicitly listed a=
s "Speedy Trial".


> It seems that criticism isn't really that welcomed and is just explained =
away.

It seems that you are trying to grasp at any criticism and thus fell victim=
 to a joke.

> Perhaps it is just my subjective perception.
> Sometimes it feels we're going from "don't trust, verify" to "just trust =
jeremy rubin", i hope this is really just my subjective perception. Because=
 I think it would be really bad that we started to blindly trust people lik=
e that, and specially jeremy.

Why "specially jeremy"?
Any particular information you think is relevant?

The IRC logs were linked, you know, you could have seen what was discussed.

In particular, on the other thread you mention:

> We should talk more about activation mechanisms and how users should be a=
ble to actively resist them more.

Speedy Trial means that users with mining hashpower can block the initial S=
peedy Trial, and the failure to lock in ***should*** cause the developers t=
o stop-and-listen.
If the developers fail to stop-and-listen, then a counter-UASF can be writt=
en which *rejects* blocks signalling *for* the upgrade, which will chainspl=
it from a pro-UASF `lockinontimeout=3Dtrue`, but clients using the initial =
Speedy Trial code will follow which one has better hashpower.

If we assume that hashpower follows price, then users who want for / agains=
t a particular softfork will be able to resist the Speedy Trial, and if dev=
elopers release a UASF `lockinontimeout=3Dtrue` later, will have the choice=
 to reject running the UASF and even running a counter-UASF.


Regards,
ZmnSCPxj