From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rc28D-0008Lb-9O for bitcoin-development@lists.sourceforge.net; Sat, 17 Dec 2011 21:49:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of mm.st designates 66.111.4.28 as permitted sender) client-ip=66.111.4.28; envelope-from=theymos@mm.st; helo=out4.smtp.messagingengine.com; Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Rc28C-0007sO-BP for bitcoin-development@lists.sourceforge.net; Sat, 17 Dec 2011 21:49:25 +0000 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CB04921473 for ; Sat, 17 Dec 2011 16:49:18 -0500 (EST) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute5.internal (MEProxy); Sat, 17 Dec 2011 16:49:18 -0500 Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id A4BAD40077; Sat, 17 Dec 2011 16:49:18 -0500 (EST) Message-Id: <1324158558.26106.140661012932641@webmail.messagingengine.com> X-Sasl-Enc: vfGNmMJC7G0LBNkDYuUPfhtxszxrjsHp1L4m3+SUDBDR 1324158558 From: "theymos" To: bitcoin-development@lists.sourceforge.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: References: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com> Date: Sat, 17 Dec 2011 15:49:18 -0600 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (theymos[at]mm.st) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1Rc28C-0007sO-BP Subject: Re: [Bitcoin-development] Protocol extensions 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: Sat, 17 Dec 2011 21:49:25 -0000 On Sat, Dec 17, 2011, at 02:06 PM, Gavin Andresen wrote: > Although I do also wonder if we'll ever run into a problem with full > nodes refusing to answer requests from lightweight nodes (there might > be a tragedy-of-the-commons problem lurking there). This seems likely. Also, even if many full nodes are willing to donate resources, there may simply be too few full nodes to handle the load. My preferred solution for handling scalability in the future is to have lightweight clients download only headers and Merkle trees (which are both small and easy to distribute), and then require senders to contact recipients directly in order to transmit their transactions. Then lightweight clients never need full blocks to build their balances, and full nodes don't have to handle expensive queries from lightweight clients. Under this scheme, the current broadcast system could be used among full nodes for a long time. Since clients wouldn't ever need to talk to full nodes, they could form a separate network with less reliable broadcasting and perhaps a fancier network architecture. Members of the full network would connect to the most reliable members of the client network in order to broadcast headers and Merkle trees and receive transactions. Full nodes would *not* answer any client queries, so dealing with the client network would not require many resources, and miners would probably have an incentive to do it. (Creating a "separate" network like this can be done by using the services field.) I don't think requiring senders to email some data to the recipient would be too burdensome, though it's probably also possible to design a system where even offline recipients can receive transactions through the Bitcoin network.