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
169
170
171
172
173
174
175
176
177
178
179
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1WT8ed-0007cF-GH
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 11:39:27 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.169 as permitted sender)
client-ip=209.85.214.169; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f169.google.com;
Received: from mail-ob0-f169.google.com ([209.85.214.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WT8ec-0002dr-Gh
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 11:39:27 +0000
Received: by mail-ob0-f169.google.com with SMTP id va2so4143796obc.28
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Mar 2014 04:39:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.128.138 with SMTP id no10mr1077460obb.32.1395920361183;
Thu, 27 Mar 2014 04:39:21 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 27 Mar 2014 04:39:21 -0700 (PDT)
In-Reply-To: <53340426.4040208@gmx.de>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<lgvobr$q44$1@ger.gmane.org> <53340426.4040208@gmx.de>
Date: Thu, 27 Mar 2014 12:39:21 +0100
X-Google-Sender-Auth: jgeINzGtWxHee7jIC_KiaBSuwNY
Message-ID: <CANEZrP1v7ZCmhhoHmuXXXvKwAV1_0a02Vkf9z4nQGNfAbZBM=A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Thomas Voegtlin <thomasv1@gmx.de>
Content-Type: multipart/alternative; boundary=089e0153852e435e4804f5950964
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: 1WT8ec-0002dr-Gh
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
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, 27 Mar 2014 11:39:27 -0000
--089e0153852e435e4804f5950964
Content-Type: text/plain; charset=UTF-8
>
> One issue that I have is bandwidth: Electrum (and mycelium) cannot
> watch as many addresses as they want, because this will create too
> much traffic on the servers. (especially when servers send utxo merkle
> proofs for each address, which is not the case yet, but is planned)
>
This is surprising and the first time I've heard about this. Surely your
constraint is CPU or disk seeks? Addresses are small, I find it hard to
believe that clients uploading them is a big drain, and mostly addresses
that are in the lookahead region won't have any hits and so won't result in
any downloads?
This constraint is not so important for bloom-filter clients.
Bloom filters are a neat way to encode addresses and keys but they don't
magically let clients save bandwidth. A smaller filter results in less
upload bandwidth but more download (from the wallets perspective). So I'm
worried if you think this will be an issue for your clients: I haven't
investigated bandwidth usage deeply yet, perhaps I should.
FWIW the current bitcoinj HDW alpha preview pre-gens 100 addresses on both
receive and change branches. But I'm not sure what the right setting is.
We also have to consider latency. The simplest implementation from a
wallets POV is to step through each transaction in the block chain one at a
time, and each time you see an address that is yours, calculate the next
ones in the chain. But that would be fantastically slow, so we must instead
pre-generate a larger lookahead region and request more data in one batch.
Then you have to recover if that batch ends up using all the pre-genned
addresses. It's just painful.
> My opinion, as far as Electrum is concerned, is that merchant accounts
> should behave differently from regular user accounts: While merchants
> need to generate an unlimited number of receiving addresses, it is also
> acceptable for them to have a slightly more complex wallet recovery
> procedure
>
Maybe. I dislike any distinction between users and merchants though. I
don't think it's really safe to assume merchants are more sophisticated
than end users.
> but also because we want fully automated synchronization between different
> instances of a wallet, using only no other source of information than
> the blockchain.
>
I think such synchronization won't be possible as we keep adding features,
because the block chain cannot sync all the relevant data. For instance
Electrum already has a label sync feature. Other wallets need to compete
with that, somehow, so we need to build a way to do cross-device wallet
sync with non-chain data.
--089e0153852e435e4804f5950964
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">One issue that I have is bandwidth: Electrum (an=
d mycelium) cannot<br>
watch as many addresses as they want, because this will create too<br>
much traffic on the servers. (especially when servers send utxo merkle<br>
proofs for each address, which is not the case yet, but is planned)<br></bl=
ockquote><div><br></div><div>This is surprising and the first time I've=
heard about this. Surely your constraint is CPU or disk seeks? Addresses a=
re small, I find it hard to believe that clients uploading them is a big dr=
ain, and mostly addresses that are in the lookahead region won't have a=
ny hits and so won't result in any downloads?</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">This constraint is not so imp=
ortant for bloom-filter clients. </blockquote><div><br></div><div>Bloom fil=
ters are a neat way to encode addresses and keys but they don't magical=
ly let clients save bandwidth. A smaller filter results in less upload band=
width but more download (from the wallets perspective). So I'm worried =
if you think this will be an issue for your clients: I haven't investig=
ated bandwidth usage deeply yet, perhaps I should.</div>
<div><br></div><div>FWIW the current bitcoinj HDW alpha preview pre-gens 10=
0 addresses on both receive and change branches. But I'm not sure what =
the right setting is.</div><div><br></div><div>We also have to consider lat=
ency. The simplest implementation from a wallets POV is to step through eac=
h transaction in the block chain one at a time, and each time you see an ad=
dress that is yours, calculate the next ones in the chain. But that would b=
e fantastically slow, so we must instead pre-generate a larger lookahead re=
gion and request more data in one batch. Then you have to recover if that b=
atch ends up using all the pre-genned addresses. It's just painful.</di=
v>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">My opinion, as far as Elect=
rum is concerned, is that merchant accounts<br>
should behave differently from regular user accounts: While merchants<br>
need to generate an unlimited number of receiving addresses, it is also<br>
acceptable for them to have a slightly more complex wallet recovery<br>
procedure<br></blockquote><div><br></div><div>Maybe. I dislike any distinct=
ion between users and merchants though. I don't think it's really s=
afe to assume merchants are more sophisticated than end users.</div><div>
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">but also because we want fully a=
utomated synchronization between different<br>
instances of a wallet, using only no other source of information than<br>
the blockchain.<br></blockquote><div><br></div><div>I think such synchroniz=
ation won't be possible as we keep adding features, because the block c=
hain cannot sync all the relevant data. For instance Electrum already has a=
label sync feature. Other wallets need to compete with that, somehow, so w=
e need to build a way to do cross-device wallet sync with non-chain data.</=
div>
</div></div></div>
--089e0153852e435e4804f5950964--
|
