summaryrefslogtreecommitdiff
path: root/0d/c80c71dbe24d5a7bc3fb1a7031986bc626886d
blob: 9d22ba1ddb7c6c42576affabd682f11fda4cdc44 (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
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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <bernie@hashplex.com>) id 1YqRsZ-0004ek-BF
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 19:54:43 +0000
Received-SPF: softfail (sog-mx-3.v43.ch3.sourceforge.com: transitioning domain
	of hashplex.com does not designate 209.85.218.51 as permitted
	sender) client-ip=209.85.218.51;
	envelope-from=bernie@hashplex.com; helo=mail-oi0-f51.google.com;
Received: from mail-oi0-f51.google.com ([209.85.218.51])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqRsY-0005aR-6P
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 19:54:43 +0000
Received: by oign205 with SMTP id n205so42366570oig.2
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 07 May 2015 12:54:36 -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:content-type;
	bh=JyGhtQ+vPdsTVY5geaOdX+4p9QcwqjA7+bnGhGH8mbw=;
	b=jCiVfA99LeIxJ0lCbMmi2teG/XoT4neAsq3BEILr2g645E8ZS3hmyjcEvLfln+dnt/
	Ryj5prL8WNOGingTBEMAijiZ/AlGzUiG2ZtjcLryyZ1/ZDGrWS0d4esIT6A0QRbkywgQ
	Kk8KYMuzw89ycARzozoblEtkaJfJPLWJMTlt+DmeWU901QLESa4kg/v3Q3+/6vhMcKXS
	0B/t/ifBs7RN0nGASPlXX6lq+ou14a+KyIrKuaJHOslznammhaJV+pfsrAwbbeWmPsCw
	SaDbp2gRm9jXvmc6eLdjwI4N92IoHHHQSJxijNAGvAie+zd5DZQqp53hog9gqh4gm62E
	6tFA==
X-Gm-Message-State: ALoCoQmdTpFfOrnAN8FtZxwz9eJn1ARpJiVd81vNPR93MJsa873Z1GX78POJQStFzKKP0Iyq4Zjb
MIME-Version: 1.0
X-Received: by 10.202.62.212 with SMTP id l203mr132056oia.67.1431027113838;
	Thu, 07 May 2015 12:31:53 -0700 (PDT)
Received: by 10.202.53.70 with HTTP; Thu, 7 May 2015 12:31:53 -0700 (PDT)
In-Reply-To: <CADJgMzvePYATxggBrvm4C=X-_a4fLKzyjqS_E-1Dk5anmE2cog@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>
	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
	<554BA032.4040405@bluematt.me>
	<CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com>
	<CADJgMzti7ROH90APiwg4NOAT5+Av=4i295b8VN0sbSLr4+WWRw@mail.gmail.com>
	<CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
	<BLU436-SMTP318E346839A76DB15D7DC5C6DF0@phx.gbl>
	<CADJgMzvePYATxggBrvm4C=X-_a4fLKzyjqS_E-1Dk5anmE2cog@mail.gmail.com>
Date: Thu, 7 May 2015 12:31:53 -0700
Message-ID: <CAJBhXOKSb_hgPupj39QSPbr3VyQ3nJ2gd0z+YyUMRis-ahWNxg@mail.gmail.com>
From: Bernard Rihn <bernie@hashplex.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113ccf3ac8e5ee051582f62e
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YqRsY-0005aR-6P
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 19:54:43 -0000

--001a113ccf3ac8e5ee051582f62e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It seems to me like some (maybe most) of the pressure is actually external
from companies that might release something that dramatically increases
"adoption" & transaction rates (and that the data on historic rate of
adoption & slumps is somewhat disconnected from their interests in a quick
roll-out)?

It seems like the question actually becomes what is our maximum acceptable
cost (hardware capex & bandwidth & power opex) associated with running a
full node without hardware acceleration and with hardware acceleration
(something which presumably "doesn't exist" yet)? Are we making the
assumption that hardware acceleration for confirmation will become broadly
available and that the primary limiter will become anonymous bandwidth?

Excuse my ignorance, but I imagine somebody must have already looked at
confirmation times vs. block size for various existing hardware platforms
(like at least 3 or 4? maybe a minnowboard, old laptop, and modern desktop
at least?)? Is there an easy way to setup bitcoind or some other script to
test this? (happy to help)

Re Moore's law: yeah, some say stuff like 5nm may never happen. We're
already using EUV with plasma emitters, immersed reflective optics, and
double-patterning... and in storage land switching to helium. Things may
slow A LOT over the next couple decades and I'd guess that a quadratic
increase (both in storage & compute) probably isn't a safe assumption.

On Thu, May 7, 2015 at 11:46 AM, Btc Drak <btcdrak@gmail.com> wrote:

> On Thu, May 7, 2015 at 7:40 PM, Gavin Costin <slashdevnull@hotmail.com>
> wrote:
>
>> Can anyone opposed to this proposal articulate in plain english the wors=
t
>> case scenario(s) if it goes ahead?
>>
>> Some people in the conversation appear to be uncomfortable, perturbed,
>> defensive etc about the proposal =E2=80=A6. But I am not seeing specific=
s on why it
>> is not a feasible plan.
>>
>
> See this response:
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg=
07462.html
>
>
>
> -------------------------------------------------------------------------=
-----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a113ccf3ac8e5ee051582f62e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It seems to me like some (maybe most) of the pressure is a=
ctually external from companies that might release something that dramatica=
lly increases &quot;adoption&quot; &amp; transaction rates (and that the da=
ta on historic rate of adoption &amp; slumps is somewhat disconnected from =
their interests in a quick roll-out)?=C2=A0<div><br></div><div>It seems lik=
e the question actually becomes what is our maximum acceptable cost (hardwa=
re capex &amp; bandwidth &amp; power opex) associated with running a full n=
ode without hardware acceleration and with hardware acceleration (something=
 which presumably &quot;doesn&#39;t exist&quot; yet)? Are we making the ass=
umption that hardware acceleration for confirmation will become broadly ava=
ilable and that the primary limiter will become anonymous bandwidth?=C2=A0<=
/div><div><br></div><div>Excuse my ignorance, but I imagine somebody must h=
ave already looked at confirmation times vs. block size for various existin=
g hardware platforms (like at least 3 or 4? maybe a minnowboard, old laptop=
, and modern desktop at least?)? Is there an easy way to setup bitcoind or =
some other script to test this? (happy to help)=C2=A0</div><div><br></div><=
div>Re Moore&#39;s law: yeah, some say stuff like 5nm may never happen. We&=
#39;re already using EUV with plasma emitters, immersed reflective optics, =
and double-patterning... and in storage land switching to helium. Things ma=
y slow A LOT over the next couple decades and I&#39;d guess that a quadrati=
c increase (both in storage &amp; compute) probably isn&#39;t a safe assump=
tion.=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Thu, May 7, 2015 at 11:46 AM, Btc Drak <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:btcdrak@gmail.com" target=3D"_blank">btcdrak@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, May 7=
, 2015 at 7:40 PM, Gavin Costin <span dir=3D"ltr">&lt;<a href=3D"mailto:sla=
shdevnull@hotmail.com" target=3D"_blank">slashdevnull@hotmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word;color:r=
gb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div>Can anyone op=
posed to this proposal articulate in plain english the worst case scenario(=
s) if it goes ahead?</div><div><br></div><div>Some people in the conversati=
on appear to be uncomfortable, perturbed, defensive etc about the proposal =
=E2=80=A6. But I am not seeing specifics on why it is not a feasible plan. =
=C2=A0</div></div></blockquote><div><br></div></span><div>See this response=
: <a href=3D"http://www.mail-archive.com/bitcoin-development@lists.sourcefo=
rge.net/msg07462.html" target=3D"_blank">http://www.mail-archive.com/bitcoi=
n-development@lists.sourceforge.net/msg07462.html</a>=C2=A0</div></div></di=
v></div>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--001a113ccf3ac8e5ee051582f62e--