From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RcKF8-0001T7-Mn for bitcoin-development@lists.sourceforge.net; Sun, 18 Dec 2011 17:09:46 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of mm.st designates 66.111.4.29 as permitted sender) client-ip=66.111.4.29; envelope-from=theymos@mm.st; helo=out5.smtp.messagingengine.com; Received: from out5.smtp.messagingengine.com ([66.111.4.29]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1RcKF7-00051j-NT for bitcoin-development@lists.sourceforge.net; Sun, 18 Dec 2011 17:09:46 +0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4698220C83 for ; Sun, 18 Dec 2011 12:09:40 -0500 (EST) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute6.internal (MEProxy); Sun, 18 Dec 2011 12:09:40 -0500 Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id F39C740078; Sun, 18 Dec 2011 12:09:39 -0500 (EST) Message-Id: <1324228179.7053.140661013136581@webmail.messagingengine.com> X-Sasl-Enc: FCSw9h9gOcJWU060X2rPjBw+WiB9WmSoZ7/oxC9h9YiD 1324228179 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 References: <82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com><1324158558.26106.140661012932641@webmail.messagingengine.com> <4EED416E.3010902@parhelic.com> In-Reply-To: <4EED416E.3010902@parhelic.com> Date: Sun, 18 Dec 2011 11:09:39 -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 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RcKF7-00051j-NT 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: Sun, 18 Dec 2011 17:09:46 -0000 On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: > I don't like the idea of a header only client, unless this is just an > interim action until the full block chain is downloaded in the > background. Development of these types of clients is probably > inevitable, but I believe that this breaks the most fundamental > aspects of Bitcoin's security model. If a client has only headers, it > cannot do full verification, and it is trusting the data from random > anonymous peers. A headers-only client is much better than trusting anyone, since an attacker needs >50% of the network's computational power to trick such clients. For everyone to keep being a full node, hardware costs would need to constantly go down enough for all nodes to be able to handle enough transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive.