Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.48 as permitted sender)
	client-ip=209.85.215.48; envelope-from=gmaxwell@gmail.com;
	helo=mail-la0-f48.google.com; 
MIME-Version: 1.0
In-Reply-To: <5342D1DB.8060203@monetize.io>
References: <CANEZrP2rgiQHpekEpFviJ22QsiV+s-F2pqosaZOA5WrRtJx5pg@mail.gmail.com>
	<5342C833.5030906@gmail.com>
	<CAAS2fgTqBfEPXh2dfcL_ke6c0wfXw4qUM1rAYMkAHcAM6mYH+g@mail.gmail.com>
	<5342D1DB.8060203@monetize.io>
Date: Mon, 7 Apr 2014 09:57:08 -0700
Message-ID: <CAAS2fgRu-0C_ozaN0qSc9SvF2TpZ56NwceLCrfQjikuQgc85tQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mark Friedenbach <mark@monetize.io>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?
Precedence: list

On Mon, Apr 7, 2014 at 9:27 AM, Mark Friedenbach <mark@monetize.io> wrote:
> Right now running a full-node on my home DSL connection (<1Mbps) makes
> other internet activity periodically unresponsive. I think we've already
> hit a point where resource requirements are pushing out casual users,
> although of course we can't be certain that accounts for all lost nodes.

That is an implementation issue=E2=80=94 mostly one that arises as an indir=
ect
consequence of not having headers first and the parallel fetch, not a
requirements issue.

Under the current bitcoin validity rules it should be completely
reasonable to run a full contributing node with no more than 30 kb/s
inbound (reviving two copies of everything, blocks + tansactions ) and
60 kbit/sec outbound (sending out four copies of everything). (So long
as you're sending out >=3D what you're taking in you're contributing to
the network's capacity). Throw in a factor of two for bursting, though
not every node needs to be contributing super low latency capacity.

This is absolutely not the case with the current implementation, but
it's not a requirements thing.