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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YqOxt-0005rE-VY
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 16:48:01 +0000
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqOxr-000809-Ni
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 16:48:01 +0000
Received: by wiun10 with SMTP id n10so67032356wiu.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 09:47:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=3JbtExqBzViRqT+Gisepaavg3Ca6TL8ae6dibSVxvlk=;
b=BsBS5d4DFXKZf86Nj+6MIlFRLZdjhGexc8ySTFD92sMCX9WFrfKN93KeOcRuH76HL3
Cuz8niyF6WiJPag7AJOBDu8DcIt40uZL0uSssCmKh3K6qZ2mQCFvHZJInYJXuhxfIUzM
nVFCihbWn/qq16q3QmbNozCsg8YC/FAVQOFc3nCtu3NHr5bl6aUfU2Kr7i6FbD3QFpBA
q2otbUkomj+xFj/WXTtaPvtSMwyGSty7eZh6AkcEtl5T5t24lCFrTFZbHNuSj9YGKXzp
4Uz3HtO2n8Z9ptYXfCVwZ5u5HyVgryjxOBgj+4X5o/VELEJIFStyvXdbxtcoSUhhWKDD
/0ew==
X-Gm-Message-State: ALoCoQmfKr4O7QR+i9R6C7OiyRDstzk5JsIoAiA0k8lDBXSyX45XEdkwgbuzGVBHM4dBIi3ax7U8
MIME-Version: 1.0
X-Received: by 10.180.105.193 with SMTP id go1mr8167146wib.92.1431017273702;
Thu, 07 May 2015 09:47:53 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Thu, 7 May 2015 09:47:53 -0700 (PDT)
In-Reply-To: <CANEZrP1ay64jryeUyDJ9Y+1C-Bre1U_1xMyuB4cqQprd1-qbCA@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
<CABm2gDpgBNjuPLnFiU2TspgLws7JjWnsxih09JG9bQycraS=sQ@mail.gmail.com>
<CANEZrP1ay64jryeUyDJ9Y+1C-Bre1U_1xMyuB4cqQprd1-qbCA@mail.gmail.com>
Date: Thu, 7 May 2015 18:47:53 +0200
Message-ID: <CABm2gDq12a8p8+fB14nM5S8CVz=sdESMowZJUeKBwvx16WDSDQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YqOxr-000809-Ni
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 16:48:02 -0000
On Thu, May 7, 2015 at 6:11 PM, Mike Hearn <mike@plan99.net> wrote:
>> It is an argument against my admittedly vague definition of
>> "non-controversial change".
>
>
> If it's an argument against something you said, it's not a straw man, right
> ;)
Yes, but it was an argument against something I didn't said ;)
> Consensus has to be defined as agreement between a group of people. Who are
> those people? If you don't know, it's impossible to decide when there is
> consensus or not.
>
> Right now there is this nice warm fuzzy notion that decisions in Bitcoin
> Core are made by consensus. "Controversial" changes are avoided. I am trying
> to show you that this is just marketing. Nobody can define what these terms
> even mean. It would be more accurate to say decisions are vetoed by whoever
> shows up and complains enough, regardless of technical merit.
Yes, that's why I drafted a definition for "uncontroversial change"
rather than "change accepted by consensus".
It will still be vague and hard to define, but consensus seems much harder.
And, yes, you're right, it is more like giving power to anyone with
valid arguments to veto hardfork changes.
But as you say, that could lead to make hardforks actually impossible,
so we should limit what constitutes a valid argument.
I later listed some examples of invalid arguments: logical fallacies,
unrelated arguments, outright lies.
Certainly I don't think technical merits should count here or that we
could veto a particular person from vetoing.
We should filter the arguments, not require an identity layer to
blacklist individuals.
We should even accept arguments from anonymous people in the internet
(you know, it wouldn't be the first time).
> Unfortunately it's hard to know what other kinds of meet-in-the-middle
> compromise could be made here. I'm sure Gavin would consider them if he
> knew. But the concerns provided are too vague to address. There are no
> numbers in them, for example:
>
> We need more research -> how much more?
Some research at all about fee market dynamics with limited size that
hasn't happened at all.
If we're increasing the consensus max size maybe we could at least
maintain the 1MB limit as a standard policy limit, so that we can
study it a little bit (like we could have done instead of removing the
initial policy limit).
> I'm not against changing the size, just not now -> then when?
I don't know yet, but I understand now that having a clearer roadmap
is what's actually urgent, not the change itself.
> I'm not wedded to 1mb, but not sure 20mb is right -> then what?
What about 2 MB consensus limit and 1 MB policy limit for now? I know
that's arbitrary too.
> Full node count is going down -> then what size do you think would fix that?
> 100kb?
As others have explained, the number of full nodes is not the
improtant part, but how easy it is to run one.
I think a modest laptop with the average internet connection of say,
India or Brazil, should be able to run a full node.
I haven't made those numbers myself but I'm sure that's possible with
1 MB blocks today, and probably with 2 MB blocks too.
> It will make mining more centralised -> how do you measure that and how much
> centralisation would you accept?
This is an excellent question for both sides.
Unfortunately I don't know the answer to this. Do you?
|
