1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
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 <theymos@mm.st>) 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 <bitcoin-development@lists.sourceforge.net>;
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" <theymos@mm.st>
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: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com><82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com><CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com><CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com><CABsx9T06-GA5+KNdr_XzP_M4Av8nEsnMXL29tk078wooZg=RZw@mail.gmail.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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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.
|
