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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YOrbr-0008Dt-PM
for bitcoin-development@lists.sourceforge.net;
Fri, 20 Feb 2015 17:43:27 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.179 as permitted sender)
client-ip=209.85.212.179; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f179.google.com;
Received: from mail-wi0-f179.google.com ([209.85.212.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YOrbq-0008Q4-Nw
for bitcoin-development@lists.sourceforge.net;
Fri, 20 Feb 2015 17:43:27 +0000
Received: by mail-wi0-f179.google.com with SMTP id hi2so4550755wib.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 20 Feb 2015 09:43:20 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.78.4 with SMTP id x4mr26794054wiw.86.1424454200650; Fri,
20 Feb 2015 09:43:20 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Fri, 20 Feb 2015 09:43:20 -0800 (PST)
In-Reply-To: <CALqxMTFNdtUup5MB2Dc_AmQ827sM-t5yx7WQubbfOEd_bO_Ong@mail.gmail.com>
References: <CALqxMTE2doZjbsUxd-e09+euiG6bt_J=_BwKY_Ni3MNK6BiW1Q@mail.gmail.com>
<CANEZrP32M-hSU-a1DA5aTQXsx-6425sTeKW-m-cSUuXCYf+zuQ@mail.gmail.com>
<CALqxMTFNdtUup5MB2Dc_AmQ827sM-t5yx7WQubbfOEd_bO_Ong@mail.gmail.com>
Date: Fri, 20 Feb 2015 18:43:20 +0100
X-Google-Sender-Auth: rLpeAZdiiOzjobZ-YENKdJc3L5M
Message-ID: <CANEZrP0cOY5Wt_mvBSdGGmi4NfZi04SQ7d6GLpnRxmqvXNArGA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=f46d043bdf5ea0ef9f050f8896f4
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: 1YOrbq-0008Q4-Nw
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] bloom filtering, privacy
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: Fri, 20 Feb 2015 17:43:27 -0000
--f46d043bdf5ea0ef9f050f8896f4
Content-Type: text/plain; charset=UTF-8
Ah, I see, I didn't catch that this scheme relies on UTXO commitments
(presumably with Mark's PATRICIA tree system?).
If you're doing a binary search over block contents then does that imply
multiple protocol round trips per synced block? I'm still having trouble
visualising how this works. Perhaps you could write down an example run for
me.
How does it interact with the need to download chains rather than
individual transactions, and do so without round-tripping to the remote
node for each block? Bloom filtering currently pulls down blocks in batches
without much client/server interaction and that is useful for performance.
Like I said, I'd rather just junk the whole notion of chain scanning and
get to a point where clients are only syncing headers. If nodes were
calculating a script->(outpoint, merkle branch) map in LevelDB and allowing
range queries over it, then you could quickly pull down relevant UTXOs
along with the paths that indicated they did at one point exist. Nodes can
still withhold evidence that those outputs were spent, but the same is true
today and in practice this doesn't seem to be an issue.
The primary advantage of that approach is it does not require a change to
the consensus rules. But there are lots of unanswered questions about how
it interacts with HD lookahead and so on.
--f46d043bdf5ea0ef9f050f8896f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Ah, I see, I didn't catch that this scheme relies on UTXO commitments =
(presumably with Mark's PATRICIA tree system?).</div><div><br></div><di=
v>If you're doing a binary search over block contents then does that im=
ply multiple protocol round trips per synced block? I'm still having tr=
ouble visualising how this works. Perhaps you could write down an example r=
un for me.<br></div><div><br></div><div>How does it interact with the need =
to download chains rather than individual transactions, and do so without r=
ound-tripping to the remote node for each block? Bloom filtering currently =
pulls down blocks in batches without much client/server interaction and tha=
t is useful for performance.</div><div><br></div><div>Like I said, I'd =
rather just junk the whole notion of chain scanning and get to a point wher=
e clients are only syncing headers. If nodes were calculating a script->=
(outpoint, merkle branch) map in LevelDB and allowing range queries over it=
, then you could quickly pull down relevant UTXOs along with the paths that=
indicated they did at one point exist. Nodes can still withhold evidence t=
hat those outputs were spent, but the same is true today and in practice th=
is doesn't seem to be an issue.</div><div><br></div><div>The primary ad=
vantage of that approach is it does not require a change to the consensus r=
ules. But there are lots of unanswered questions about how it interacts wit=
h HD lookahead and so on.</div><div><br></div></div></div></div>
--f46d043bdf5ea0ef9f050f8896f4--
|
