Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXEmO-0002tI-26 for bitcoin-development@lists.sourceforge.net; Mon, 07 Apr 2014 19:00:24 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WXEmM-0004vi-0o for bitcoin-development@lists.sourceforge.net; Mon, 07 Apr 2014 19:00:24 +0000 Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WXEmF-0005eU-0d; Mon, 07 Apr 2014 21:00:15 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_11BA485A-697C-4764-97B9-BB2C17805957"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Tamas Blummer In-Reply-To: Date: Mon, 7 Apr 2014 21:00:27 +0200 Message-Id: <8A6DEBA4-EA59-4BAE-95CF-C964C2DBB84B@bitsofproof.com> References: <5342C833.5030906@gmail.com> <6D430188-CE00-44B1-BD8C-B623CF04D466@icloudtools.net> <6D6E55CE-2F04-4C34-BEE6-98AEF1478346@bitsofproof.com> To: Gregory Maxwell X-Mailer: Apple Mail (2.1874) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396897222; 5f6558e8; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WXEmM-0004vi-0o 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 19:00:24 -0000 --Apple-Mail=_11BA485A-697C-4764-97B9-BB2C17805957 Content-Type: multipart/alternative; boundary="Apple-Mail=_C164A8DF-69ED-421A-AD19-B74BA6117EB3" --Apple-Mail=_C164A8DF-69ED-421A-AD19-B74BA6117EB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Once a single transaction in pruned in a block, the block is no longer = eligible to be served to other nodes.=20 Which transactions are pruned can be rather custom e.g. even depending = on the wallet(s) of the node, therefore I guess it is more handy to return some bitmap of pruned/full = blocks than ranges. Tamas Blummer http://bitsofproof.com On 07.04.2014, at 20:49, Gregory Maxwell wrote: > On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer = wrote: >> BTW, did we already agree on the service bits for an archive node? >=20 > I'm still very concerned that a binary archive bit will cause extreme > load hot-spotting and the kind of binary "Use lots of resources YES or > NO" I think we're currently suffering some from, but at that point > enshrined in the protocol. >=20 > It would be much better to extend the addr messages so that nodes can > indicate a range or two of blocks that they're serving, so that all > nodes can contribute fractionally according to their means. E.g. if > you want to offer up 8 GB of distributed storage and contribute to the > availability of the blockchain, without having to swollow the whole > 20, 30, 40 ... gigabyte pill. >=20 > Already we need that kind of distributed storage for the most recent > blocks to prevent extreme bandwidth load on archives, so extending it > to arbitrary ranges is only more complicated because there is > currently no room to signal it. >=20 --Apple-Mail=_C164A8DF-69ED-421A-AD19-B74BA6117EB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Once a single transaction in pruned in a block, = the block is no longer eligible to be served to other = nodes. 
Which transactions are pruned can be rather = custom e.g. even depending on the wallet(s) of the = node,
therefore I guess it is more handy to return some bitmap = of pruned/full blocks than ranges.


On 07.04.2014, at 20:49, Gregory Maxwell <gmaxwell@gmail.com> = wrote:

On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer <tamas@bitsofproof.com> = wrote:
BTW, did we already agree on the = service bits for an archive node?

I'm still very = concerned that a binary archive bit will cause extreme
load = hot-spotting and the kind of binary "Use lots of resources YES or
NO" = I think we're currently suffering some from, but at that = point
enshrined in the protocol.

It would be much better to = extend the addr messages so that nodes can
indicate a range or two of = blocks that they're serving, so that all
nodes can contribute = fractionally according to their means. E.g. if
you want to offer up 8 = GB of distributed storage and contribute to the
availability of the = blockchain,  without having to swollow the whole
20, 30, 40 ... = gigabyte pill.

Already we need that kind of distributed storage = for the most recent
blocks to prevent extreme bandwidth load on = archives, so extending it
to arbitrary ranges is only more = complicated because there is
currently no room to signal = it.


= --Apple-Mail=_C164A8DF-69ED-421A-AD19-B74BA6117EB3-- --Apple-Mail=_11BA485A-697C-4764-97B9-BB2C17805957 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTQvXLAAoJEPZykcUXcTkcjDIH/1G1Ma1uuO+6a2r1DqAEWiUK Z2Zdlx6M4u53HQLj26B0uKRCIBTzNkNdg31FZJAsuRW6UMQqm147YibzYbeFg3E3 PdL/oTNtH+zEWyGgzyu261m4HaztraACk+IRYirRQNpA3IdtaNeOWO5QY+noKj/e K073CGVytrjvWK94viaPUryKoYox8O6LKlNTs+kxLuxZXWhBE0U9bGVWGDJRlC38 B7AiquP30XhS+6FPGtm/CWEOSqSEYsH6fll/Efrj8MrxqRaVHnSNF0Z1vf6yGy/9 picqBnlJ3M/55Y9deROTbh3w2BbyZJKlvBnWZQWoIYgeBJlOfUVCGQJVsx+bl78= =ykNd -----END PGP SIGNATURE----- --Apple-Mail=_11BA485A-697C-4764-97B9-BB2C17805957--