summaryrefslogtreecommitdiff
path: root/8c/6f6394ff4d0eee200d861876419fc47de6e2aa
blob: c061af9ec83b1f67e87c06f4f80c8fe5b5ef4fb5 (plain)
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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1RcL7G-00075q-GR
	for bitcoin-development@lists.sourceforge.net;
	Sun, 18 Dec 2011 18:05:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.175 as permitted sender)
	client-ip=209.85.216.175; envelope-from=etotheipi@gmail.com;
	helo=mail-qy0-f175.google.com; 
Received: from mail-qy0-f175.google.com ([209.85.216.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RcL7F-0003ZE-Ch
	for bitcoin-development@lists.sourceforge.net;
	Sun, 18 Dec 2011 18:05:42 +0000
Received: by qcqw6 with SMTP id w6so3050693qcq.34
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 18 Dec 2011 10:05:36 -0800 (PST)
Received: by 10.224.95.197 with SMTP id e5mr21365667qan.0.1324231535961;
	Sun, 18 Dec 2011 10:05:35 -0800 (PST)
Received: from [192.168.1.85] (c-76-111-108-35.hsd1.md.comcast.net.
	[76.111.108.35])
	by mx.google.com with ESMTPS id m20sm475103qaj.14.2011.12.18.10.05.34
	(version=SSLv3 cipher=OTHER); Sun, 18 Dec 2011 10:05:35 -0800 (PST)
Message-ID: <4EEE2B91.1050908@gmail.com>
Date: Sun, 18 Dec 2011 13:06:09 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>
	<1324228179.7053.140661013136581@webmail.messagingengine.com>
In-Reply-To: <1324228179.7053.140661013136581@webmail.messagingengine.com>
Content-Type: multipart/alternative;
	boundary="------------050105040806020201000201"
X-Spam-Score: -0.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
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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: 1RcL7F-0003ZE-Ch
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 18:05:42 -0000

This is a multi-part message in MIME format.
--------------050105040806020201000201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The whole point of having headers built at a constant size and 
generation rate is to minimize the amount of data needed to "understand" 
of the blockchain while simultaneously maximizing integrity/security in 
the presence of untrusted nodes.  Barring the 50%-attack, you only need 
a couple honest nodes out of 50 to stay safe (as long as you're waiting 
for your 6 confirmations).   In fact, I would argue that a full node 
(Satoshi client), has the same level of security as a headers-only 
client... because they both base *all* their verification decisions on 
computations that end with comparing hashes to the longest-chain headers.

In the case that an attacker figures out how to isolate your node 
entirely and start feeing you poisoned blocks, then you are vulnerable 
with any kind of node, full or lightweight.  I don't see where the 
reduced security is.

The only issue I see is that a truly light-weight, headers-only node 
will be having to download an entire block to get one transaction it 
needs.  This would be significantly alleviated if nodes can start 
requesting merkle-trees directly, even without merkle-branch-pruning.   
If a node can ask for a tx and the tx-hash-list of the block that 
incorporated that tx,  he can easily verify his tx against his 
no-need-to-trust-anyone headers, and doesn't have to download MBs for 
every one.

As for blockchain pruning... I think it's absolutely critical to find a 
way to do this, /for all nodes/.  I am swayed by Dan Kaminsky's 
scalability warnings, and my instinct tells me that leaving full 
verification to a select few deep-pockets nodes in the future opens up 
all sorts of centralization/power-corporation issues that is contrary to 
the Bitcoin concept.  It is in everyone's best interest to make it as 
easy as possible for /anyone/ to act as a full node (if possible).  As 
such, I believe that the current system of minimizing TxOut size is the 
right one.  TxIns take up 0 bytes space in the long-run when taking into 
account any blockchain pruning/snapshot idea (except for nLocktime/seq 
transactions where the TxIn might have to be saved).

-Alan





On 12/18/2011 12:09 PM, theymos wrote:
> 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.
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--------------050105040806020201000201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    The whole point of having headers built at a constant size and
    generation rate is to minimize the amount of data needed to
    "understand" of the blockchain while simultaneously maximizing
    integrity/security in the presence of untrusted nodes.&nbsp; Barring the
    50%-attack, you only need a couple honest nodes out of 50 to stay
    safe (as long as you're waiting for your 6 confirmations).&nbsp;&nbsp; In
    fact, I would argue that a full node (Satoshi client), has the same
    level of security as a headers-only client... because they both base
    <b>all</b> their verification decisions on computations that end
    with comparing hashes to the longest-chain headers.<br>
    <br>
    In the case that an attacker figures out how to isolate your node
    entirely and start feeing you poisoned blocks, then you are
    vulnerable with any kind of node, full or lightweight.&nbsp; I don't see
    where the reduced security is.&nbsp; <br>
    <br>
    The only issue I see is that a truly light-weight, headers-only node
    will be having to download an entire block to get one transaction it
    needs.&nbsp; This would be significantly alleviated if nodes can start
    requesting merkle-trees directly, even without
    merkle-branch-pruning. &nbsp; If a node can ask for a tx and the
    tx-hash-list of the block that incorporated that tx,&nbsp; he can easily
    verify his tx against his no-need-to-trust-anyone headers, and
    doesn't have to download MBs for every one.&nbsp; <br>
    <br>
    As for blockchain pruning... I think it's absolutely critical to
    find a way to do this, <i>for all nodes</i>.&nbsp; I am swayed by Dan
    Kaminsky's scalability warnings, and my instinct tells me that
    leaving full verification to a select few deep-pockets nodes in the
    future opens up all sorts of centralization/power-corporation issues
    that is contrary to the Bitcoin concept.&nbsp; It is in everyone's best
    interest to make it as easy as possible for <i>anyone</i> to act as
    a full node (if possible).&nbsp; As such, I believe that the current
    system of minimizing TxOut size is the right one.&nbsp; TxIns take up 0
    bytes space in the long-run when taking into account any blockchain
    pruning/snapshot idea (except for nLocktime/seq transactions where
    the TxIn might have to be saved).&nbsp; <br>
    <br>
    -Alan<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    On 12/18/2011 12:09 PM, theymos wrote:
    <blockquote
      cite="mid:1324228179.7053.140661013136581@webmail.messagingengine.com"
      type="cite">
      <pre wrap="">On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
A headers-only client is much better than trusting anyone, since an
attacker needs &gt;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.

------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/ms-windowsazure">http://p.sf.net/sfu/ms-windowsazure</a>
_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------050105040806020201000201--