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
|
Return-Path: <emu@emuadmin.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2CD3BC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Mar 2021 10:45:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 138DF40112
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Mar 2021 10:45:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.009
X-Spam-Level:
X-Spam-Status: No, score=0.009 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, T_SPF_PERMERROR=0.01]
autolearn=ham autolearn_force=no
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 UR6AAlC9BkRd
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Mar 2021 10:45:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.emuadmin.com (mail.emuadmin.com [108.61.189.74])
by smtp2.osuosl.org (Postfix) with ESMTPS id A444B400A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Mar 2021 10:45:46 +0000 (UTC)
Received: by mail.emuadmin.com (Postfix, from userid 1001)
id 3ECDA7590E; Fri, 19 Mar 2021 10:45:44 +0000 (UTC)
Date: Fri, 19 Mar 2021 10:45:44 +0000
From: Emil Pfeffer <emu@emuadmin.com>
To: Prayank <prayank@tutanota.de>
Message-ID: <20210319104544.l4z6shndm2xnmk77@www01.emuadmin.com>
References: <MVzGeC---3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MVzGeC---3-2@tutanota.de>
X-Mailman-Approved-At: Fri, 19 Mar 2021 11:27:54 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th
March 19:00 UTC
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 Mar 2021 10:45:48 -0000
On Wed, Mar 17, 2021 at 09:21:39AM +0100, Prayank wrote:
> >??the last thing we need is
> a rushed upgrade
>
> Why do you think this is rushed? Speedy Trial will have few months and if UASF is required it won't involve activation immediately after ST fails. Taproot by 2022 doesn't look rushed approach IMO.
That depends on your perception of time. Back in the day we also had people that thought 10 min avg block time is too much.
Taproot by the end of 2022 *using a single activation method* is not rushed. Taproot
by 2022 by all means necessary is tyranny. (will add to this later on)
>
> >??We're not changing things that we worked out already.??
>
> Which things have we worked out that cannot be changed or not changed earlier?
>
Plenty. Starting from the parameters of bitcoin consensus to the way Bitcoin Core
is organized to the minimum time of 18 months an upgrade needs to last. (based on prior experience)
If you want to challenge any of the old rules it takes more than ignoring them
and doing whatever you feel like (is useful to get the result you want (again the tyrant theme)).
I would go as far as to say that 18 months is not ideal and we might need 24 to 36
and that any upgrade of this kind needs to take at least the amount of time the
previous one took but ideally longer.
The motivation is pretty straight forward. If you pretend users decide then you will
understand users have others things to do than continously keeping up with Bitcoin
and in order for them to make an informed decision there needs to be plenty of time.
Otherwise you're repeating the tyranical argument which has become a recurring theme
of the discourse of some of the Bitcoin Core developers. (which is a loose term)
> > how long till we go back and change the coin supply?
>
> Coin supply has nothing to do with soft fork activation mechanism IMO.
Thats true but not what I said.
>
> > I understand??some of you have no patience and would like mass adoption tomorrow but??those are exactly the people that do not have a say in Bitcoin development. If you want to get rich quick you do not care about Bitcoin.
>
> Taproot activation or discussion about activation mechanism does not have 100% correlation with mass adoption. It just improves Bitcoin and helps few projects mentioned in??https://en.bitcoin.it/wiki/Taproot_Uses
> Nobody is talking about get rich quick schemes in Taproot Activation related meetings. At least I have not seen anyone.
>
Thats also true but also not what I said.
> > If you??want faster development??cycles then you have lightning to play with.
>
> Better development cycles with less delay, less misinformation, less politics, less probability of things being exploited by mining pools or other people, organization etc. with their influence. Lightning Network is a separate project focused on layer 2 and I think it will also benefit from Taproot.
>
This is the recurring theme of the tyrant that shows up in a lot of the posts on this
list.
Who is this entity that gets to decide what happens regardless of what everyone
else has to say? You seem to believe that there exists some entity that gets to decide what goes on and gets to exclude anyone it wants from the decision making process.
> >??we *DO NOT* change things we already established in the past
>
> Interested to know who is "we" in this sentence and what are the "things" that cannot be changed.
"we" is a reference to "we're all Satoshi" and the "things" you will learn by learning the past.
>
> >??In order to solve the LOT debate lets give Wladimir the power??to decide on his own and if he has no strong opinions he should just flip a coin.
>
> LOT has become LOL. If this is about Bitcoin Core maintainers deciding things for Bitcoin Core, sure they already do. But users have the freedom to decide if they want to run it with default settings or use other implementation.
This is your way of passing the buck around. If you do not yet know what your
responsabilities are that does not make you not responsable for anything.
Bitcoin Core has responsabilities regardless of the rethoric.
>
> >??MAST threshold can be even lower because it is not representative of an economic majority??and it could speed up the upgrade.
>
> Agree
>
> >??At this point involve as few people as possible and get it done. This is just about the??software and the parameters of the new consesus.
>
> Everyone should be welcome to participate in meetings, ask questions, learn more and contribute. I don't see anything wrong with it.
That depends on the scope of the meetings. If the meeting is about making progress on
an issue very few people have any clue about then it is desirable that the people
that are looking to learn should do so using other venues.
> --
> Prayank
--
|