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
|
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 1Yz5QD-0001QG-1E
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 15:45:09 +0000
Received: from mail-wg0-f52.google.com ([74.125.82.52])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yz5QB-0001tE-Rt
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 15:45:09 +0000
Received: by wgbgq6 with SMTP id gq6so96471091wgb.3
for <bitcoin-development@lists.sourceforge.net>;
Sun, 31 May 2015 08:45:01 -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=k071dSDuM2Jz3OnniqxDrVuiAskS4MlRLBmwcORVTS0=;
b=GDqfkaMdEM242VY3qjAvgl3/WcZBndyjaCtmqWRPGeuGE7/vmGunMR8UgdX1g6HYbh
arEa3j5WekzmT1UbNN950m2IoSjy6jiyoNLjWPz7V0LVrAkDs6qCC4FKlrV8vYoa6/0T
IdoyraVDaT7AXGo1qkqIODyxYwdEroBbTvqNzDs+GBt0Z5QFoVM/9n9UJiA4kXWAgRtG
wh+eFp3pEqh2wIVLdr/3/czjaV2W6hAe9r3PbiU74qaCbZ7hO1lTSJd+GRkpsHZMy5WR
X8ejqwShK45BWxyNN1A4TYAXcN1lQWMiaRyjXbRkt48z20Cu68v85kJfxs51eV/l+EOl
wPew==
X-Gm-Message-State: ALoCoQmWusjrbmnDlyR+CSCkGiZx12+BZEAl8nv7I9tWMpRJtqvW8WWc08OWmUEREC+JZPKn7FNS
MIME-Version: 1.0
X-Received: by 10.194.60.164 with SMTP id i4mr33470058wjr.133.1433087101823;
Sun, 31 May 2015 08:45:01 -0700 (PDT)
Received: by 10.194.139.235 with HTTP; Sun, 31 May 2015 08:45:01 -0700 (PDT)
Received: by 10.194.139.235 with HTTP; Sun, 31 May 2015 08:45:01 -0700 (PDT)
In-Reply-To: <CABsx9T3_MVw6WBv8b35E0+NdJreRTbHHbweckdO=XZu4LRcOEQ@mail.gmail.com>
References: <554BE0E1.5030001@bluematt.me>
<CABsx9T2ysKj5HVbN_7_o33fMehs4KH6E_R583Mt_VPC4gDA0LQ@mail.gmail.com>
<5568F567.3050608@bluematt.me>
<CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
<556A1046.50807@bluematt.me>
<CABsx9T3qPiQ+PL3ZNT+QJzw4ALEzKjMjC4=uEKTG+4vVPdXr-g@mail.gmail.com>
<CABm2gDoE5kbE2cnFzZPAOZbHMdXBaZG7pB7c6dovj=1unPentw@mail.gmail.com>
<CABsx9T0SVW9ASBH=Xyet5EKQtjAoJ7nLpAab5_yLQdUo=QpV7w@mail.gmail.com>
<CABm2gDr4G7V5OLfiFq0onGNb3HCWHk9K46FtVcLOVetvxiLqRg@mail.gmail.com>
<CABsx9T3_MVw6WBv8b35E0+NdJreRTbHHbweckdO=XZu4LRcOEQ@mail.gmail.com>
Date: Sun, 31 May 2015 17:45:01 +0200
Message-ID: <CABm2gDobPy+j4+7F=boUG4DkbzOUwcWTT2iPorCiptFwgE3yJw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7ba97f1aa303510517629734
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Yz5QB-0001tE-Rt
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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: Sun, 31 May 2015 15:45:09 -0000
--047d7ba97f1aa303510517629734
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On May 31, 2015 5:08 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> On Sun, May 31, 2015 at 10:59 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro=
te:
>>
>> Whatever...let's use the current subsidies, the same argument applies,
it's just 20 + 25 =3D 45 btc per block for miner B vs 27 btc for miner B.
>> Miner B would still go out of business, bigger blocks still mean more
mining and validation centralization
>
> Sorry, but that's ridiculous.
>
> If Miner B is leaving 18BTC per block on the table because they have bad
connectivity, then they need to pay for better connectivity.
Well, I was assuming they just can't upgrade their connection (without
moving thei operations to another place). Maybe that assumption is
ridiculous as well.
> If you are arguing "I should be able to mine on a 56K modem connection
from the middle of the Sahara" then we're going to have to agree to
disagree.
No, I'm not suggesting that.
> So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
costs are not excessive.
Well, you were I think assuming a new desktop connecting from somewhere in
the US. I would be more confortable with an eee pc from a hotel in India,
for example. But yeah, targeting some concrete minimum specs seems like the
right approach for deciding "how far to go when increasing centralization".
But "hitting the limit will be chaos" seems to imply that completely
removing the consensus maximum blocksize is the only logical solution. What
happens when we hit the limit next time? When do we stop kicking the can
down the road? When do we voluntarily get that "chaos"?
Again, "that's too far away in the future to worry about it" is not a very
conving answer to me.
--047d7ba97f1aa303510517629734
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On May 31, 2015 5:08 PM, "Gavin Andresen" <<a href=3D"mailto:g=
avinandresen@gmail.com">gavinandresen@gmail.com</a>> wrote:<br>
><br>
> On Sun, May 31, 2015 at 10:59 AM, Jorge Tim=C3=B3n <jtimon@jtimon.c=
c> wrote:<br>
>><br>
>> Whatever...let's use the current subsidies, the same argument =
applies, it's just 20 + 25 =3D 45 btc per block for miner B vs 27 btc f=
or miner B.<br>
>> Miner B would still go out of business, bigger blocks still mean m=
ore mining and validation centralization<br>
><br>
> Sorry, but that's ridiculous.<br>
><br>
> If Miner B is leaving 18BTC per block on the table because they have b=
ad connectivity, then they need to pay for better connectivity.</p>
<p dir=3D"ltr">Well, I was assuming they just can't upgrade their conne=
ction (without moving thei operations to another place). Maybe that assumpt=
ion is ridiculous as well.</p>
<p dir=3D"ltr">> If you are arguing "I should be able to mine on a =
56K modem connection from the middle of the Sahara" then we're goi=
ng to have to agree to disagree.</p>
<p dir=3D"ltr">No, I'm not suggesting that.</p>
<p dir=3D"ltr">> So: what is your specific proposal for minimum requirem=
ents for connectivity to run a full node? The 20MB number comes from estima=
ting costs to run a full node, and as my back-and-forth to Chang Wung shows=
, the costs are not excessive.</p>
<p dir=3D"ltr">Well, you were I think assuming a new desktop connecting fro=
m somewhere in the US. I would be more confortable with an eee pc from a ho=
tel in India, for example. But yeah, targeting some concrete minimum specs =
seems like the right approach for deciding "how far to go when increas=
ing centralization".</p>
<p dir=3D"ltr">But "hitting the limit will be chaos" seems to imp=
ly that completely removing the consensus maximum blocksize is the only log=
ical solution. What happens when we hit the limit next time? When do we sto=
p kicking the can down the road? When do we voluntarily get that "chao=
s"?<br>
Again, "that's too far away in the future to worry about it" =
is not a very conving answer to me.<br>
</p>
--047d7ba97f1aa303510517629734--
|
