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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXDSo-0003cU-Hx for bitcoin-development@lists.sourceforge.net; Mon, 07 Apr 2014 17:36:06 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.172 as permitted sender) client-ip=209.85.214.172; envelope-from=brent.shambaugh@gmail.com; helo=mail-ob0-f172.google.com; Received: from mail-ob0-f172.google.com ([209.85.214.172]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WXDSn-0008GJ-3e for bitcoin-development@lists.sourceforge.net; Mon, 07 Apr 2014 17:36:06 +0000 Received: by mail-ob0-f172.google.com with SMTP id wm4so6906140obc.17 for ; Mon, 07 Apr 2014 10:35:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.205.226 with SMTP id lj2mr1698031obc.84.1396892159741; Mon, 07 Apr 2014 10:35:59 -0700 (PDT) Received: by 10.76.12.105 with HTTP; Mon, 7 Apr 2014 10:35:59 -0700 (PDT) In-Reply-To: References: <5342C833.5030906@gmail.com> <5342D1DB.8060203@monetize.io> <5342D9FA.8080102@monetize.io> Date: Mon, 7 Apr 2014 12:35:59 -0500 Message-ID: From: Brent Shambaugh To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a11c22e9af897cd04f6774cad X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (brent.shambaugh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WXDSn-0008GJ-3e Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Why are we bleeding nodes? 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: Mon, 07 Apr 2014 17:36:06 -0000 --001a11c22e9af897cd04f6774cad Content-Type: text/plain; charset=ISO-8859-1 How difficult would it be to set up a node? Using lots of electricity at home (if required) could be an issue, but I do have a Webfaction account. On Mon, Apr 7, 2014 at 12:16 PM, Gregory Maxwell wrote: > On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach > wrote: > > On 04/07/2014 09:57 AM, Gregory Maxwell wrote: > >> That is an implementation issue-- mostly one that arises as an indirect > >> consequence of not having headers first and the parallel fetch, not a > >> requirements issue. > > > > Oh, absolutely. But the question "why are people not running full > > nodes?" has to do with the current implementation, not abstract > > capabilities of a future version of the bitcoind code base. > > The distinction is very important because it's a matter of things we > can and should fix vs things that cannot be fixed except by changing > goals/incentives! Opposite approaches to handling them. > > When I read "resource requirements of a full node are moving beyond" I > didn't extract from that that "there are implementation issues that > need to be improved to make it work better for low resource users" due > to the word "requirements". > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a11c22e9af897cd04f6774cad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How difficult would it be to set up a node? Using lots of = electricity at home (if required) could be an issue, but I do have a Webfac= tion account.


On Mon, Apr 7, 2014 at 12:16 PM, Gregory Maxwell <gmaxwell@gmail.com&= gt; wrote:
On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach <mark@monetize.io> wrote:
> On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
>> That is an implementation issue— mostly one that arises as a= n indirect
>> consequence of not having headers first and the parallel fetch, no= t a
>> requirements issue.
>
> Oh, absolutely. But the question "why are people not running full=
> nodes?" has to do with the current implementation, not abstract > capabilities of a future version of the bitcoind code base.

The distinction is very important because it's a matter of things= we
can and should fix vs things that cannot be fixed except by changing
goals/incentives!  Opposite approaches to handling them.

When I read "resource requirements of a full node are moving beyond&qu= ot; I
didn't extract from that that "there are implementation issues tha= t
need to be improved to make it work better for low resource users" due=
to the word "requirements".

---------------------------------------------------------------------------= ---
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.= sf.net/sfu/13600_Cloudbees
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c22e9af897cd04f6774cad--