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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1ShpST-0001y6-OK
for bitcoin-development@lists.sourceforge.net;
Thu, 21 Jun 2012 22:02:33 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
helo=mail-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1ShpST-0000Lb-2E
for bitcoin-development@lists.sourceforge.net;
Thu, 21 Jun 2012 22:02:33 +0000
Received: by qcso7 with SMTP id o7so643171qcs.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 21 Jun 2012 15:02:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.135.74 with SMTP id m10mr9111439qct.41.1340316147605; Thu,
21 Jun 2012 15:02:27 -0700 (PDT)
Received: by 10.229.192.201 with HTTP; Thu, 21 Jun 2012 15:02:27 -0700 (PDT)
In-Reply-To: <CAErK2CgH1k2oosn2a7HyvDxvasw1pHh6jPVWG0JUORMVHettOQ@mail.gmail.com>
References: <CAF7tpEyEWCbcB+jSpWOMyeZUBjQ=FbVEC8kLt3j2Yzv3YJOgiA@mail.gmail.com>
<4FE0B7EB.6000100@gmail.com>
<CACh7GpEehHFEJGRTtijgM7UAa2jeEWRKrQo5dym8F_YgXAEhFA@mail.gmail.com>
<4FE0C538.3090001@gmail.com>
<CAErK2CgH1k2oosn2a7HyvDxvasw1pHh6jPVWG0JUORMVHettOQ@mail.gmail.com>
Date: Thu, 21 Jun 2012 18:02:27 -0400
Message-ID: <CAAS2fgTBH4bo5UebOcjHgJL+mf_020SobR=WME_haufnmv-j2g@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Koss <mike@coinlab.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-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.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1ShpST-0000Lb-2E
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Ultimate Blockchain Compression w/
trust-free lite node
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, 21 Jun 2012 22:02:33 -0000
On Thu, Jun 21, 2012 at 5:42 PM, Mike Koss <mike@coinlab.com> wrote:
> Are we just talking about pruning the spent transactions from an old block?
No.
We're talking about commitments to the state of _unspent_ transactions
which would allow ~memoryless nodes to engage in full validation
without having to trust anything with the help of some untrusted
non-memoryless peers. Also, talking about being able to securely
initialize new pruned nodes (not memoryless but reduced memory)
without exposing them to the old history of the chain. In both cases
this is possible without substantially degrading the full node
security model (rule violations prior to where they begin are only
undetectable with a conspiracy of the entire network).
But it requires a new data structure for managing these trees of
unspent transactions in a secure, scalable, and DOS resistant manner.
Fortunately there are lots of possibilities here.
> Does it really make sense to adopt a more complex data-structure than the merkle tree for inclusing in the bticoin protocol?
Yes. Though this is obviously not an ultra short term thing.
|
