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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1RiwlL-0006HF-VR
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Jan 2012 23:30:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=mh.in.england@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1RiwlL-0006Qd-4p
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Jan 2012 23:30:23 +0000
Received: by werm13 with SMTP id m13so1109194wer.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 05 Jan 2012 15:30:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.136.132 with SMTP id w4mr1963540wei.53.1325806217019; Thu,
05 Jan 2012 15:30:17 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.216.187.149 with HTTP; Thu, 5 Jan 2012 15:30:16 -0800 (PST)
In-Reply-To: <jdtm7t$4ed$1@dough.gmane.org>
References: <jdrds3$3tf$1@dough.gmane.org>
<CAAS2fgTOZKM9c=UvfVW1rajnPQVQMNS4mR5KUqq8p0HreG=vuQ@mail.gmail.com>
<jdtm7t$4ed$1@dough.gmane.org>
Date: Fri, 6 Jan 2012 00:30:16 +0100
X-Google-Sender-Auth: M2twNlYBtPZdu8lvx0VEQvHMvdg
Message-ID: <CANEZrP1ZfSJGaRimJhJ-jCuarSMmJGi5+=vxngDgc6kOKTR8JA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Elden Tyrell <tyrell.elden@gmail.com>
Content-Type: multipart/alternative; boundary=0016e6d58faf9b431b04b5d05095
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1RiwlL-0006Qd-4p
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] does "stubbing" off Merkle trees reduce
initial download bandwidth?
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: Thu, 05 Jan 2012 23:30:24 -0000
--0016e6d58faf9b431b04b5d05095
Content-Type: text/plain; charset=UTF-8
This thread is discussing two unrelated things.
Your first email asked about transaction pruning ("stubbing"). You're
correct. This doesn't do anything for initial chain download bandwidth or
time. In fact it makes it slower because you have the overhead of deleting
the old transactions. It exists purely to save disk space.
Christians reply is about simplified payment verification (SPV) mode. It is
unrelated to transaction pruning. SPV clients can download only the chain
headers with no bodies all the way from the genesis block until the
creation time of their youngest key. This does reduce initial setup time
and in fact is now implemented in BitCoinJ, but it's still linear in the
length of Bitcoins life, so that's ultimately unsustainable. You need a
regular series of checkpoints signed by a trusted developer and a circular
block store to have truly bounded overheads. The merkle tree is still
useful because it allows for SPV clients to receive only the transactions
of interest yet have nearly the same assurances that downloading full
blocks would give - remote nodes can now hide transactions from you (dos)
but not invent new ones.
SPV clients do not use "number of blocks on top" as a way to decide
validity. They look for the best chain they can find, same as a regular
node does. As Satoshis paper says, if an SPV node has access to the P2P
network and is also talking to you, you can defraud it for as long as you
can dominate the networks hash power (51% attack) because you can create a
harder chain than everyone else can. However your invalid blocks won't be
accepted by the rest of the network regardless of how many there are or how
much work they represent, so as soon as you stop dominating the network the
correct chain will catch up and replace yours, resulting in the fraud being
detected and shown to the SPV user.
--0016e6d58faf9b431b04b5d05095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This thread is discussing two unrelated things.<br><br>Your first email ask=
ed about transaction pruning ("stubbing"). You're correct. Th=
is doesn't do anything for initial chain download bandwidth or time. In=
fact it makes it slower because you have the overhead of deleting the old =
transactions. It exists purely to save disk space.<br>
<br>Christians reply is about simplified payment verification (SPV) mode. I=
t is unrelated to transaction pruning. SPV clients can download only the ch=
ain headers with no bodies all the way from the genesis block until the cre=
ation time of their youngest key. This does reduce initial setup time and i=
n fact is now implemented in BitCoinJ, but it's still linear in the len=
gth of Bitcoins life, so that's ultimately unsustainable. You need a re=
gular series of checkpoints signed by a trusted developer and a circular bl=
ock store to have truly bounded overheads. The merkle tree is still useful =
because it allows for SPV clients to receive only the transactions of inter=
est yet have nearly the same assurances that downloading full blocks would =
give - remote nodes can now hide transactions from you (dos) but not invent=
new ones.<br>
<br>SPV clients do not use "number of blocks on top" as a way to =
decide validity. They look for the best chain they can find, same as a regu=
lar node does. As Satoshis paper says, if an SPV node has access to the P2P=
network and is also talking to you, you can defraud it for as long as you =
can dominate the networks hash power (51% attack) because you can create a =
harder chain than everyone else can. However your invalid blocks won't =
be accepted by the rest of the network regardless of how many there are or =
how much work they represent, so as soon as you stop dominating the network=
the correct chain will catch up and replace yours, resulting in the fraud =
being detected and shown to the SPV user.<br>
--0016e6d58faf9b431b04b5d05095--
|
