Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SUiAN-0005yS-1I for bitcoin-development@lists.sourceforge.net; Wed, 16 May 2012 17:37:39 +0000 X-ACL-Warn: Received: from nm23-vm4.bullet.mail.ne1.yahoo.com ([98.138.91.183]) by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1SUiAM-0000U9-8i for bitcoin-development@lists.sourceforge.net; Wed, 16 May 2012 17:37:38 +0000 Received: from [98.138.90.53] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 16 May 2012 17:37:32 -0000 Received: from [98.138.89.169] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 16 May 2012 17:37:32 -0000 Received: from [127.0.0.1] by omp1025.mail.ne1.yahoo.com with NNFMP; 16 May 2012 17:37:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 674224.81922.bm@omp1025.mail.ne1.yahoo.com Received: (qmail 2941 invoked by uid 60001); 16 May 2012 17:37:32 -0000 X-YMail-OSG: xJ3dS30VM1kBasr9ZAY1UdXKKiP8h5G8aYC7gIW4w5AlvGM u_sOMN5RWF6RXE3uCIf7jJn7CVk_uAF1OcXG.sM1l34TWngLzBKS9utcB7w4 8ulBEacVZu7krTtGkfYEcFsnv2.ixgcaUAm2XHNedOC73R6hF8YqPU6Yy5nv dq6j04Jm4563TONNRD4SbbWTd6AbBULL57ns9umJ8zmHc_HQUFk5wf7rb6Tz Ch7rMkfvgEXglId9mZY61Xwko3EroZdPIl0q7vxyLI.4O_xbsbvdSzOS4hj3 AiG8Mqo2LSvUEK3o_WFDRTjdJF4xChE2J69X18TmON7JoruC7YUVzEZ1d37T P_4nZ_Y4N3nwtVe7sCQeozsCWrA.EnGtfrerWnamISOnlp6R3PAExc7BZbc0 tyQe8IMJYhArQszQljsXN Received: from [194.29.236.67] by web121001.mail.ne1.yahoo.com via HTTP; Wed, 16 May 2012 10:37:32 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <1337186094.12490.YahooMailNeo@web121005.mail.ne1.yahoo.com> Message-ID: <1337189852.2839.YahooMailNeo@web121001.mail.ne1.yahoo.com> Date: Wed, 16 May 2012 10:37:32 -0700 (PDT) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.91.183 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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: 1SUiAM-0000U9-8i Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:37:39 -0000 > 1) This is cool and useful (but see 3)=0A=0A> 2) This is significantly le= ss secure than validating an entire blockchain; it's certainly worth workin= g out some use cases here in more detail than just a sample conversation. M= ore on this below=0A> 3) What about discovery? Will a client now have the c= hance to look for NODE_STRATIZED clients on IRC? How do you envision a stra= tized server decides which transactions to relay/store? Or is it just a cac= hing layer in front of a high quality blockchain service? If it is just a c= aching service, the question of cache hits / misses is an interesting one a= s well.=A0=0A=0AStratized nodes do discovery as normal. Service nodes are e= xplicitly chosen like IRC servers are for IRC clients.=0A=0A=0A> 4) What ar= e the economic motivations to run a stratized server? Other than cheating p= eople of course.=0A=0ANone. Same as BitTorrent super-nodes, Tor relays or e= mail servers. People don't need economic motivation for everything.=0A=0A= =0A> 5) Seems like a 'send me everything for this source address' is going = to save a lot of roundtrip conversations for what I imagine the most common= request will be.=0A=0AThat's a bad idea. I prefer to keep each request min= imal to prevent resource starvation and simplify the protocol (while shifti= ng the onus onto the client). Also the history can be resolved with multipl= e services while the data is being downloaded and sorted.