From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A6E70BBC for ; Fri, 3 Jul 2015 03:25:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6EF22108 for ; Fri, 3 Jul 2015 03:25:04 +0000 (UTC) Received: by wicgi11 with SMTP id gi11so89072215wic.0 for ; Thu, 02 Jul 2015 20:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mvIuxlLke01IgZT06KpbSchchBHkrUz6lUYuvkwWh7w=; b=OpigfCO5J0vo/tSaPmf0J3IfHUUzQdQgVJyxW228+eOLuD6H/KH2I5uI7zoU73df9N F1yZ9II1ZO5ltHiG50AYw4TTLEbcJY4TX5TP0u4xoWZy4BIGnTgaObMzCxBIitfOzhyI Iv32OgDofzz3ax+Gd3fuxYosBeU0yeu4SbKe23w678tp51G1UPSSbxnYcfW3FAu4/KN+ LZ5Bafp74G3IJrbffu+Wlp5R4aTTeVGJAPosgAYIhfrWRdaTGPbaMq8gRSjmCCrkoscD AlLVpZStEJdkateNwpq6eJBJytYCDAlQDz6VGRXOM6ZKN/RP8wu4lJNa7BgkAnl7NIRI 8qBQ== MIME-Version: 1.0 X-Received: by 10.180.79.162 with SMTP id k2mr42536472wix.46.1435893903154; Thu, 02 Jul 2015 20:25:03 -0700 (PDT) Received: by 10.28.140.196 with HTTP; Thu, 2 Jul 2015 20:25:03 -0700 (PDT) In-Reply-To: References: <5595503D.2010608@phauna.org> Date: Thu, 2 Jul 2015 23:25:03 -0400 Message-ID: From: Jeff Garzik To: Jeremy Rubin Content-Type: multipart/alternative; boundary=f46d043745110865500519f01adc X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Defining a min spec X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 03:25:05 -0000 --f46d043745110865500519f01adc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If the freedom to pick architecture exists, Moxie is a nice, compact, easy to audit alternative: http://moxielogic.org/blog/pages/architecture.html https://github.com/jgarzik/moxiebox Scaling can occur at the core level, rather than hyper-pipelining, keeping the architecture itself nice and clean and simple. On Thu, Jul 2, 2015 at 11:13 PM, Jeremy Rubin < jeremy.l.rubin.travel@gmail.com> wrote: > Might I suggest that the min-spec, if developed, target the RISC-V Rocket > architecture (running on FPGA, I suppose) as a reference point for > performance? This may be much lower performance than desirable, however, = it > means that we don't lock people into using large-vendor chipsets which ha= ve > unknown, or known to be bad, security properties such as Intel AMT. > > In general, targeting open hardware seems to me to be more critical than > performance metrics for the long term health of Bitcoin, however, > performance is still important. > > Does anyone know how the RISC-V FPGA performance stacks up to, say, a > Raspberry Pi? > > On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden wrote: > >> I'm also a user who runs a full node, and I also like this idea. I think >> Gavin has done some back-of-the-envelope calculations around this stuff, >> but nothing so clearly defined as what you propose. >> >> On 07/02/2015 08:33 AM, Mistr Bigs wrote: >> >>> I'm an end user running a full node on an aging laptop. >>> I think this is a great suggestion! I'd love to know what system >>> requirements are needed for running Bitcoin Core. >>> >>> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman >>> > wrote: >>> >>> I=E2=80=99m a game developer. I write time critical code for a livi= ng and >>> have to deal with memory, CPU, GPU and I/O budgets on a daily basis= . >>> These budgets are based on what we call a minimum specification (of >>> hardware); min spec for short. In most cases the min spec is based >>> on entry model machines that are available during launch, and will >>> give the user an enjoyable experience when playing our games. >>> Obviously, we can turn on a number of bells and whistles for people >>> with faster machines, but that=E2=80=99s not the point of this mail= . >>> >>> The point is, can we define a min spec for Bitcoin Core? The number >>> one reason for this is: if you know how your changes affect your >>> available budgets, then the risk of breaking something due to >>> capacity problems is reduced to practically zero. >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f46d043745110865500519f01adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the freedom to pick architecture exists, Moxie is a nic= e, compact, easy to audit alternative:
=C2=A0 =C2=A0 =C2=A0https://github.com/jgarzik/moxiebox

Scaling can occur at the core level, rather than hy= per-pipelining, keeping the architecture itself nice and clean and simple.<= /div>



On Thu, Jul 2, 2015 at 11:13 PM, Jeremy Rubin <jeremy.l.rubin.travel@gmail.com> wrote:
Might I suggest that the=C2=A0min-spec, if developed, target the RISC-V Rocket archite= cture (running on FPGA, I suppose) as a reference point for performance? Th= is may be much lower performance than desirable, however, it means that we = don't lock people into using large-vendor chipsets which have unknown, = or known to be bad, security properties such as Intel AMT.

In general, targeting open hardware seems to me to be more cri= tical than performance metrics for the long term health of Bitcoin, however= , performance is still important.

Does anyone know how t= he RISC-V FPGA performance stacks up to, say, a Raspberry Pi?

=
On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden <= ogunden@phauna.org> wrote:
= I'm also a user who runs a full node, and I also like this idea. I thin= k Gavin has done some back-of-the-envelope calculations around this stuff, = but nothing so clearly defined as what you propose.

On 07/02/2015 08:33 AM, Mistr Bigs wrote:
I'm an end user running a full node on an aging laptop.
I think this is a great suggestion! I'd love to know what system
requirements are needed for running Bitcoin Core.

On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
 <jeanpaulko= gelman@me.com <mailto:jeanpaulkogelman@me.com>> wrote:

=C2=A0 =C2=A0 I=E2=80=99m a game developer. I write time critical code for = a living and
=C2=A0 =C2=A0 have to deal with memory, CPU, GPU and I/O budgets on a daily= basis.
=C2=A0 =C2=A0 These budgets are based on what we call a minimum specificati= on (of
=C2=A0 =C2=A0 hardware); min spec for short. In most cases the min spec is = based
=C2=A0 =C2=A0 on entry model machines that are available during launch, and= will
=C2=A0 =C2=A0 give the user an enjoyable experience when playing our games.=
=C2=A0 =C2=A0 Obviously, we can turn on a number of bells and whistles for = people
=C2=A0 =C2=A0 with faster machines, but that=E2=80=99s not the point of thi= s mail.

=C2=A0 =C2=A0 The point is, can we define a min spec for Bitcoin Core? The = number
=C2=A0 =C2=A0 one reason for this is: if you know how your changes affect y= our
=C2=A0 =C2=A0 available budgets, then the risk of breaking something due to=
=C2=A0 =C2=A0 capacity problems is reduced to practically zero.



 _______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--f46d043745110865500519f01adc--