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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1SgKO2-0004HH-IO
for bitcoin-development@lists.sourceforge.net;
Sun, 17 Jun 2012 18:39:46 +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-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SgKO1-0004QY-Md
for bitcoin-development@lists.sourceforge.net;
Sun, 17 Jun 2012 18:39:46 +0000
Received: by qcso7 with SMTP id o7so2580192qcs.34
for <bitcoin-development@lists.sourceforge.net>;
Sun, 17 Jun 2012 11:39:40 -0700 (PDT)
Received: by 10.224.179.78 with SMTP id bp14mr22000075qab.37.1339958380194;
Sun, 17 Jun 2012 11:39:40 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id gy5sm36320021qab.3.2012.06.17.11.39.39
(version=SSLv3 cipher=OTHER); Sun, 17 Jun 2012 11:39:39 -0700 (PDT)
Message-ID: <4FDE2460.5080301@gmail.com>
Date: Sun, 17 Jun 2012 14:39:28 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative;
boundary="------------010001080507030909020409"
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: 1SgKO1-0004QY-Md
Subject: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free
lite nodes
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, 17 Jun 2012 18:39:46 -0000
This is a multi-part message in MIME format.
--------------010001080507030909020409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
All,
With the flurry of discussion about blockchain compression, I thought it
was time to put forward my final, most-advanced idea, into a single,
well-thought-out, *illustrated*, forum post. Please check it out:
https://bitcointalk.org/index.php?topic=88208.0
This is a huge undertaking, but it has some pretty huge benefits. And
it's actually feasible because it can be implemented without disrupting
the main network. I'm sure there's lots of issues with it, but I'm
putting it out there to see how it might be improved and actually executed.
----
*Summary:
*/Use a special tree data structure to organize all unspent-TxOuts on
the network, and use the root of this tree to communicate its
"signature" between nodes. The leaves of this tree actually correspond
to addresses/scripts, and the data at the leaf is actually a root of the
unspent-TxOut list for that address/script. To maintain security of the
tree signatures, it will be included in the header of an alternate
blockchain, which will be secured by merged mining.
This provides the same compression as the simpler unspent-TxOut merkle
tree, but also gives nodes a way to download just the unspent-TxOut list
for each address in their wallet, and verify that list directly against
the blockheaders. Therefore, even lightweight nodes can get full
address information, from any untrusted peer, and with only a tiny
amount of downloaded data (a few kB). /*
*----
Alright, tear it up!
-Alan
--------------010001080507030909020409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
All,<br>
<br>
With the flurry of discussion about blockchain compression, I
thought it was time to put forward my final, most-advanced idea,
into a single, well-thought-out, <b>illustrated</b>, forum
post. Please check it out:
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="https://bitcointalk.org/index.php?topic=88208.0">https://bitcointalk.org/index.php?topic=88208.0</a><br>
<br>
This is a huge undertaking, but it has some pretty huge benefits.
And it's actually feasible because it can be implemented without
disrupting the main network. I'm sure there's lots of issues with
it, but I'm putting it out there to see how it might be improved and
actually executed. <br>
<br>
----
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<br>
<b>Summary:<br>
<br>
</b><i>Use a special tree data structure to organize all
unspent-TxOuts on the network, and use the root of this tree to
communicate its "signature" between nodes. The leaves of this
tree actually correspond to addresses/scripts, and the data at the
leaf is actually a root of the unspent-TxOut list for that
address/script. To maintain security of the tree signatures, it
will be included in the header of an alternate blockchain, which
will be secured by merged mining. <br>
<br>
This provides the same compression as the simpler unspent-TxOut
merkle tree, but also gives nodes a way to download just the
unspent-TxOut list for each address in their wallet, and verify
that list directly against the blockheaders. Therefore, even
lightweight nodes can get full address information, from any
untrusted peer, and with only a tiny amount of downloaded data (a
few kB). </i><b><br>
</b>----<br>
<br>
Alright, tear it up!<br>
-Alan<br>
<br>
</body>
</html>
--------------010001080507030909020409--
|
