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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ctpacia@gmail.com>) id 1YPEwQ-0007l3-DW
for bitcoin-development@lists.sourceforge.net;
Sat, 21 Feb 2015 18:38:14 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.47 as permitted sender)
client-ip=209.85.218.47; envelope-from=ctpacia@gmail.com;
helo=mail-oi0-f47.google.com;
Received: from mail-oi0-f47.google.com ([209.85.218.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPEwN-0005bx-9X
for bitcoin-development@lists.sourceforge.net;
Sat, 21 Feb 2015 18:38:14 +0000
Received: by mail-oi0-f47.google.com with SMTP id i138so7684390oig.6
for <bitcoin-development@lists.sourceforge.net>;
Sat, 21 Feb 2015 10:38:05 -0800 (PST)
X-Received: by 10.202.197.204 with SMTP id v195mr2248170oif.54.1424543885485;
Sat, 21 Feb 2015 10:38:05 -0800 (PST)
MIME-Version: 1.0
References: <CALqxMTE2doZjbsUxd-e09+euiG6bt_J=_BwKY_Ni3MNK6BiW1Q@mail.gmail.com>
<CANEZrP32M-hSU-a1DA5aTQXsx-6425sTeKW-m-cSUuXCYf+zuQ@mail.gmail.com>
<CAAS2fgSEqYNiGFk0pZ-hT_0zR7_Nh1OUvyfFd-DE=a-cdzgWwQ@mail.gmail.com>
<CANEZrP21+0kLCX2sanFYFKEQj4iGgMmmA5sc3k_y+mpx9WC09A@mail.gmail.com>
<54E8AC69.4000102@gmail.com>
<CANEZrP2iPRA_mSXqdzXBxiNZ=aJEEfTaG5DL5Bg0zPGPhkkhPw@mail.gmail.com>
From: Chris Pacia <ctpacia@gmail.com>
Date: Sat, 21 Feb 2015 18:38:05 +0000
Message-ID: <CAB+qUq74MahJo4t=k8Fim2GLeAv=U9RS3Nsxf-FeS=LqytOJtQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a1134e2d842ed51050f9d78df
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
(ctpacia[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: 1YPEwN-0005bx-9X
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: Sat, 21 Feb 2015 18:38:14 -0000
--001a1134e2d842ed51050f9d78df
Content-Type: text/plain; charset=UTF-8
Yeah that overhead is pretty high. I wasn't thinking about 10 years out.
On Sat, Feb 21, 2015, 11:47 AM Mike Hearn <mike@plan99.net> wrote:
> Adam seems to be making sense to me. Only querying a single node when an
>> address in my wallet matches the block filter seems to be pretty efficient.
>>
>
> No, I think it's less efficient (for the client).
>
> Quick sums: blocks with 1500 transactions in them are common today. But
> Bitcoin is growing. Let's imagine a system 10x larger than today. Doesn't
> seem implausible to reach that in the next 5-10 years, so 15,000
> transactions. Each transaction has multiple elements we might want to match
> (addresses, keys, etc).
>
> Let's say the average tx contains 5 unique keys/elements. That's the base
> case of {1 input, 2 outputs} without address reuse, plus fudged up a bit
> for multi-sends then down a bit again for address reuse.
>
> 15,000*5=75,000 unique elements per block. With an FP rate of 0.1% we get:
>
> http://hur.st/bloomfilter?n=75000&p=0.001
>
> 131.63KB per block extra overhead.
>
> 144 blocks in a day, so that's 18mb of data per day's worth of sync to
> pull down over the network. If you don't start your wallet for a week
> that's 126 megabytes of data just to get started.
>
> Affordable, yes (in the west). Fast enough to be competitive? Doubtful. I
> don't believe that even in five years mobiles will be pulling down and
> processing that much data within a few seconds, not even in developed
> countries.
>
> But like I said, I don't see why it matters. Anyone who is watching the
> wire close to you learns which transactions are yours, still, so it doesn't
> stop intelligence agencies. Anyone who is running a node learns which
> transactions in the requested block were yours and thus can follow the tx
> chain to learn which other transactions might be yours too, no different to
> today. If you connect to a single node and say "give me the transactions
> sending money to key A in block N", it doesn't matter if you then don't
> request block N+6 from the same peer - they know you will request it
> eventually anyway, just by virtue of the fact that one of the transactions
> they gave you was spent in that block.
>
>
>
--001a1134e2d842ed51050f9d78df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Yeah that overhead is pretty high. I wasn't thinking abo=
ut 10 years out.</p>
<br><div class=3D"gmail_quote">On Sat, Feb 21, 2015, 11:47 AM=C2=A0Mike Hea=
rn <<a href=3D"mailto:mike@plan99.net">mike@plan99.net</a>> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF">Adam seems to be making sense to me. Only querying a single no=
de
when an address in my wallet matches the block filter seems to be
pretty efficient.</div></blockquote><div><br></div></div></div></div><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>N=
o, I think it's less efficient (for the client).</div><div><br></div><d=
iv>Quick sums: =C2=A0blocks with 1500 transactions in them are common today=
. But Bitcoin is growing. Let's imagine a system 10x larger than today.=
Doesn't seem implausible to reach that in the next 5-10 years, so 15,0=
00 transactions. Each transaction has multiple elements we might want to ma=
tch (addresses, keys, etc).=C2=A0</div><div><br></div><div>Let's say th=
e average tx contains 5 unique keys/elements. That's the base case of {=
1 input, 2 outputs} without address reuse, plus fudged up a bit for multi-s=
ends then down a bit again for address reuse.<br></div><div><br></div><div>=
15,000*5=3D75,000 unique elements per block. With an FP rate of 0.1% we get=
:</div><div><br></div><div><a href=3D"http://hur.st/bloomfilter?n=3D75000&a=
mp;p=3D0.001" target=3D"_blank">http://hur.st/bloomfilter?n=3D75000&p=
=3D0.001</a><br></div><div><br></div><div>131.63KB per block extra overhead=
.<br></div><div><br></div><div>144 blocks in a day, so that's 18mb of d=
ata per day's worth of sync to pull down over the network. If you don&#=
39;t start your wallet for a week that's 126 megabytes of data just=C2=
=A0to get started.</div><div><br></div><div>Affordable, yes (in the west). =
Fast enough to be competitive? Doubtful. I don't believe that even in f=
ive years mobiles will be pulling down and processing that much data within=
a few seconds, not even in developed countries.</div><div><br></div><div>B=
ut like I said, I don't see why it matters. Anyone who is watching the =
wire close to you learns which transactions are yours, still, so it doesn&#=
39;t stop intelligence agencies. Anyone who is running a node learns which =
transactions in the requested block were yours and thus can follow the tx c=
hain to learn which other transactions might be yours too, no different to =
today. If you connect to a single node and say "give me the transactio=
ns sending money to key A in block N", it doesn't matter if you th=
en don't request block N+6 from the same peer - they know you will requ=
est it eventually anyway, just by virtue of the fact that one of the transa=
ctions they gave you was spent in that block.</div><div><br></div><div><br>=
</div></div></div></div>
</blockquote></div>
--001a1134e2d842ed51050f9d78df--
|
