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 <tamas@bitsofproof.com>
In-Reply-To: <CAAS2fgQaJ6P4Aj2A5Zox+CiGQK6jHvF1CkLH1R6xbadYhUXO2g@mail.gmail.com>
Date: Mon, 7 Apr 2014 21:00:27 +0200
Message-Id: <8A6DEBA4-EA59-4BAE-95CF-C964C2DBB84B@bitsofproof.com>
References: <CANEZrP2rgiQHpekEpFviJ22QsiV+s-F2pqosaZOA5WrRtJx5pg@mail.gmail.com>
	<5342C833.5030906@gmail.com>
	<CAAS2fgTqBfEPXh2dfcL_ke6c0wfXw4qUM1rAYMkAHcAM6mYH+g@mail.gmail.com>
	<6D430188-CE00-44B1-BD8C-B623CF04D466@icloudtools.net>
	<CANEZrP1-9LpPw4WuY8bfsEG0OLoDECXTfQCoZsZ4tmOn2H7Omw@mail.gmail.com>
	<6D6E55CE-2F04-4C34-BEE6-98AEF1478346@bitsofproof.com>
	<CAAS2fgQaJ6P4Aj2A5Zox+CiGQK6jHvF1CkLH1R6xbadYhUXO2g@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?
Precedence: list


--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 <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?
>=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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>Once a single transaction in pruned in a block, =
the block is no longer eligible to be served to other =
nodes.&nbsp;</div><div>Which transactions are pruned can be rather =
custom e.g. even depending on the wallet(s) of the =
node,</div><div>therefore I guess it is more handy to return some bitmap =
of pruned/full blocks than ranges.</div><div><br></div><div =
apple-content-edited=3D"true"><span style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; orphans: 2; widows: 2; float: none; =
display: inline !important;">Tamas Blummer</span><br style=3D"color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; orphans: 2; widows: 2;"><span =
style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span =
style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: 2; widows: =
2; float: none; display: inline !important;"><a =
href=3D"http://bitsofproof.com">http://bitsofproof.com</a></span>
</span></div>
<br><div><div>On 07.04.2014, at 20:49, Gregory Maxwell &lt;<a =
href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer &lt;<a =
href=3D"mailto:tamas@bitsofproof.com">tamas@bitsofproof.com</a>&gt; =
wrote:<br><blockquote type=3D"cite">BTW, did we already agree on the =
service bits for an archive node?<br></blockquote><br>I'm still very =
concerned that a binary archive bit will cause extreme<br>load =
hot-spotting and the kind of binary "Use lots of resources YES or<br>NO" =
I think we're currently suffering some from, but at that =
point<br>enshrined in the protocol.<br><br>It would be much better to =
extend the addr messages so that nodes can<br>indicate a range or two of =
blocks that they're serving, so that all<br>nodes can contribute =
fractionally according to their means. E.g. if<br>you want to offer up 8 =
GB of distributed storage and contribute to the<br>availability of the =
blockchain, &nbsp;without having to swollow the whole<br>20, 30, 40 ... =
gigabyte pill.<br><br>Already we need that kind of distributed storage =
for the most recent<br>blocks to prevent extreme bandwidth load on =
archives, so extending it<br>to arbitrary ranges is only more =
complicated because there is<br>currently no room to signal =
it.<br><br></blockquote></div><br></body></html>=

--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--