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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Precedence: list

--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&#39;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&#39;t have a=
ny hits and so won&#39;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&#39;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&#39;m worried =
if you think this will be an issue for your clients: I haven&#39;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&#39;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&#39;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&#39;t think it&#39;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&#39;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--