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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YqNoI-0000Zn-D3
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 15:34:02 +0000
Received: from mail-wi0-f170.google.com ([209.85.212.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqNoG-0005b6-MM
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 15:34:02 +0000
Received: by wizk4 with SMTP id k4so247648956wiz.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 08:33:54 -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=KT/OB5EbCcLgo70C8cH6e6SEJGavUPN1utIDb9rxcJ8=;
b=WNLV7CmSqr6z2aA+AwyaWRJG4MOPtAP7PpRKI9LnFQ+n8ZmmB6Uetxrp5nnK4uuZX4
FDsq0cs2EL8AKHGSQ3N7UpaFLBqbgj5yjd29HnAeaH+0Cj67h16NS0iBc32sylsta7Gg
yfDiNkOS9kT2FYLi/pUpieXsD8wEOpskekSqfmf0sN4ZaYAIZt/HX1V51BeqUnu2yOjP
Q9KnF9DR1HqojLdSps+HCGwYE94mav3RE7X0iWJobPm2EL0tc3LeMvN3wSlDVX1OdHEQ
KNyBaieDLadt8b0hlKmTGkd1EdOKRqgWD5ieMZ5TCuwaIe3Ihg+D36m1nMtcI95yRN65
N95g==
X-Gm-Message-State: ALoCoQkPqZYhQK7Ks197dpwnlEwhF2f/YbydsR74TXsrZ5N3mwXOWqOhkrMCiXQPvd4NH7l3V+C7
MIME-Version: 1.0
X-Received: by 10.180.99.166 with SMTP id er6mr7818803wib.58.1431012834539;
Thu, 07 May 2015 08:33:54 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Thu, 7 May 2015 08:33:54 -0700 (PDT)
In-Reply-To: <CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@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>
Date: Thu, 7 May 2015 17:33:54 +0200
Message-ID: <CABm2gDpgBNjuPLnFiU2TspgLws7JjWnsxih09JG9bQycraS=sQ@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: 1YqNoG-0005b6-MM
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 15:34:02 -0000
On Thu, May 7, 2015 at 4:05 PM, Mike Hearn <mike@plan99.net> wrote:
>> If his explanation was "I will change my mind after we increase block
>>
>> size", I guess the community should say "then we will just ignore your
>> nack because it makes no sense".
>
>
> Oh good! We can just kick anyone out of the consensus process if we think
> they make no sense.
>
> I guess that means me and Gavin can remove everyone else from the developer
> consensus, because we think trying to stop Bitcoin growing makes no sense.
>
> Do you see the problem with this whole notion? It cannot possibly work.
> Whenever you try and make the idea of developer consensus work, what you end
> up with is "I believe in consensus as long as it goes my way". Which is
> worthless.
That is not what I said. Then you demonstrated that it was absurd.
That's called a straw man argument and it's a well known fallacy, it
is precisely the example of arguments that can be safely ignored.
It is an argument against my admittedly vague definition of
"non-controversial change".
More importantly, I never said anything about "removing anyone", I was
always talking about arguments and not people.
One person could use fallacious arguments to attack or defend a given
proposal and use perfectly valid ones in another, a person can even
mix valid and invalid arguments in the same mail.
>> One thing is the Bitcoin core project where you could argue that the 5
>> committers decide (I don't know why Wladimir would have any more
>> authority than the others).
>
>
> Because he is formally the maintainer.
Yes, the maintainer of the Bitcoin core free software project (I
cannot stressed this enough, that can be forked by anyone), not the
president of Bitcoin the p2p network.
> Maybe you dislike that idea. It's so .... centralised. So let's say Gavin
> commits his patch, because his authority is equal to all other committers.
> Someone else rolls it back. Gavin sets up a cron job to keep committing the
> patch. Game over.
>
> You cannot have committers fighting over what goes in and what doesn't.
> That's madness. There must be a single decision maker for any given
> codebase.
I'm sure that if they become that stupid, developers would move to a
fork of the project in no time.
>> Ok, so in simple terms, you expect people to have to pay enormous fees
>> and/or wait thousands of blocks for their transactions to get included
>> in the chain. Is that correct?
>
>
> No. I'll write an article like the others, it's better than email for more
> complicated discourse.
Ok, thanks in advance.
>> As others have said, if the answer is "forever, adoption is always the
>> most important thing" then we will end up with an improved version of Visa.
>
>
> This appears to be another one of those fundamental areas of disagreement. I
> believe there is no chance of Bitcoin ending up like Visa, even if it is
> wildly successful. I did the calculations years ago that show that won't
> happen:
>
> https://en.bitcoin.it/wiki/Scalability
>
> Decentralisation is a spectrum and Bitcoin will move around on that spectrum
> over time. But claiming we have to pick between 1mb blocks and "Bitcoin =
> VISA" is silly.
Again, I didn't say any of that. My point is that a network that
becomes too "centralized" (like visa, that is centralized vs p2p, not
vs distributed) doesn't offer any security or decentralization
advantage over current networks (and of course I meant that could
happen with larger blocks, not 1 MB blocks).
I'm sure that's not what the proponents of the size increase want, and
I'm not defending 1 MB as a sacred limit or anything, but my question
is "where is the limit for them?"
Even a limitless block size would technically work because miners
would limit it to limit the orphan rate. So "no hardcoded consensus
limit on transaction volume/block size" could be a valid answer to the
question "what is the right consensus limit to block size?" for which
there's no real right answer because there is a tradeoff between
transaction volume and centralization.
Should we maintain 1 MB forever? Probably not.
Is 20 MB a bad size? I honestly don't know.
Is this urgent? I don't think so.
Should we rush things when we don't have clear answers to many related
questions? I don't think so.
You think that it is too soon to start restricting transaction volume
in any way. You will answer why in your post.
When is the right time and what is the right limitation then?
I want to have fee competition as soon as possible, at least
temporarily. But you say that it can wait for later.
Ok, when do you think we should make that happen then?
When 20 MB are full, will that be the right time to let the fee market
develop then or will it be urgent to increase the block size again?
Should we directly remove the limit then and let miners handle it as
they want?
If so, why not now?
Maybe we can increase to 2 MB, then wait for fee competition, then
wait for 2 more subsidy halvings and then increase to 11 or 20 MB?
There's so many possibilities that I don't understand how can be
surprising that "20 MB, as soon as possible" is not the obvious answer
to everyone...
|
