From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <554A91BE.6060105@bluematt.me> <554BA032.4040405@bluematt.me> Date: Thu, 7 May 2015 12:31:53 -0700 Message-ID: From: Bernard Rihn To: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Thu, May 7, 2015 at 7:40 PM, Gavin Costin > 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
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 "adoption" & transaction rates (and that the da= ta on historic rate of adoption & slumps is somewhat disconnected from = their interests in a quick roll-out)?=C2=A0

It seems lik= e the question actually becomes what is our maximum acceptable cost (hardwa= re capex & bandwidth & power opex) associated with running a full n= ode without hardware acceleration and with hardware acceleration (something= which presumably "doesn't exist" 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>

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>Re Moore'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'd guess that a quadrati= c increase (both in storage & compute) probably isn't a safe assump= tion.=C2=A0

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 op= posed to this proposal articulate in plain english the worst case scenario(= s) if it goes ahead?

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


-----------------------------------------------------------------------= -------
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a113ccf3ac8e5ee051582f62e--