Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXQwP-0003FV-46 for bitcoin-development@lists.sourceforge.net; Tue, 08 Apr 2014 07:59:33 +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 1WXQwN-0007CL-6u for bitcoin-development@lists.sourceforge.net; Tue, 08 Apr 2014 07:59:33 +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 1WXQwG-0006HR-QC; Tue, 08 Apr 2014 09:59:24 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_EFED67E5-3988-47B9-B415-774302E61D9A"; 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: Tue, 8 Apr 2014 09:59:24 +0200 Message-Id: <19177DCF-B159-492E-921D-E26226AFB5EF@bitsofproof.com> References: <5342C833.5030906@gmail.com> <6D430188-CE00-44B1-BD8C-B623CF04D466@icloudtools.net> <6D6E55CE-2F04-4C34-BEE6-98AEF1478346@bitsofproof.com> To: Jeff Garzik X-Mailer: Apple Mail (2.1874) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396943971; 0e7beefc; 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: 1WXQwN-0007CL-6u 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: Tue, 08 Apr 2014 07:59:33 -0000 --Apple-Mail=_EFED67E5-3988-47B9-B415-774302E61D9A Content-Type: multipart/alternative; boundary="Apple-Mail=_D8B07DAA-2C9C-4094-8BE4-FFDFFF53331E" --Apple-Mail=_D8B07DAA-2C9C-4094-8BE4-FFDFFF53331E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Specialization of nodes is ongoing most prominent with SPV wallets and = mining. There is a need I see on my own business for software that is able to = serve multiple wallets, and is multi tiered, so the world facing P2P node can be in a DMZ. I target them with a = hybrid model that is SPV plus mempool transaction validation=20 against UTXO and use =91reference=92 implementations as border router. = I think that this setup will be common for enterprises=20 and hence push for a stripped down =91reference=92 border router without = wallet, payment protocol, GUI, RPC calls here.=20 That border router could also serve as archive node evtl. also offering = blocks at bulk e.g. through http.=20 Enterprises that run a multi tiered environment have the bandwith to = serve as archives. Tamas Blummer http://bitsofproof.com On 08.04.2014, at 05:44, Jeff Garzik wrote: > Being Mr. Torrent, I've held open the "80% serious" suggestion to > simply refuse to serve blocks older than X (3 months?). >=20 > That forces download by other means (presumably torrent). >=20 > I do not feel it is productive for any nodes on the network to waste > time/bandwidth/etc. serving static, ancient data. There remain, of > course, issues of older nodes and "getting the word out" that prevents > this switch from being flipped on tomorrow. >=20 >=20 >=20 > On Mon, Apr 7, 2014 at 2:49 PM, 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 >> = --------------------------------------------------------------------------= ---- >> 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 >=20 >=20 >=20 > --=20 > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ >=20 --Apple-Mail=_D8B07DAA-2C9C-4094-8BE4-FFDFFF53331E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Specialization of nodes is ongoing most = prominent with SPV wallets and mining.

There is = a need I see on my own business for software that is able to serve = multiple wallets, and is multi tiered,
so the world facing P2P = node can be in a DMZ. I target them with a hybrid model that is SPV plus = mempool transaction validation 
against UTXO and use = =91reference=92 implementations as border router.  I think that = this setup will be common for enterprises 
and hence push = for a stripped down =91reference=92 border router without wallet, = payment protocol, GUI, RPC calls = here. 

That border router could also serve = as archive node evtl. also offering blocks at bulk e.g. through = http. 
Enterprises that run a multi tiered environment = have the bandwith to serve as archives.


On 08.04.2014, at 05:44, Jeff Garzik <jgarzik@bitpay.com> = wrote:

Being Mr. Torrent, I've held open the "80% serious" = suggestion to
simply refuse to serve blocks older than X (3 = months?).

That forces download by other means (presumably = torrent).

I do not feel it is productive for any nodes on the = network to waste
time/bandwidth/etc. serving static, ancient data. =  There remain, of
course, issues of older nodes and "getting the = word out" that prevents
this switch from being flipped on = tomorrow.



On Mon, Apr 7, 2014 at 2:49 PM, 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.

---------------------------------------------------------------= ---------------
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_Clo= udbees
_______________________________________________
Bitcoin-d= evelopment mailing = list
Bitcoin-development@lists.sourceforge.net
https://lists.sourcef= orge.net/lists/listinfo/bitcoin-development



--=
Jeff Garzik
Bitcoin core developer and open source = evangelist
BitPay, Inc.      https://bitpay.com/

<= /div>
= --Apple-Mail=_D8B07DAA-2C9C-4094-8BE4-FFDFFF53331E-- --Apple-Mail=_EFED67E5-3988-47B9-B415-774302E61D9A 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 iQEcBAEBAgAGBQJTQ6xcAAoJEPZykcUXcTkcw5wH/3HLSMUnpJoZd+oh43TBoTz4 NYe3fOgMlrHPn+n2BaeePDklBG4T54OjTteFnNB8Gh02p0xZWwEgrqNctKxdRMtG Hb4tEXXs5mF1RR8Yv57lYRxnr4TlvQKmgLlrk5IY7J6OiL117NOgQRFwvw1T5CnY vWJ+C/nqgID0v/vItYALVgfmL4f4J3rEGcGTfymlQDdgvB1+02RhFN7QcjmXimC8 Bqnrsf5/t+/vCk0EG713hATq8l7UY9K/v2OvtD4aH1mNs2cSCKHkmnHaWw1rYkX2 Vjx6adj2k4+pWGjVu/K8/IjZ74CyhOXVKqY6cRwhvXxxowGfZ47pxQHcN30YMDA= =zX/M -----END PGP SIGNATURE----- --Apple-Mail=_EFED67E5-3988-47B9-B415-774302E61D9A--