For SPV wallets it's more complicated. There must always be a large
lookahead window for latency reasons. We can't query the entire database
because we don't know how far ahead the user is. So we have to assume there
might be a lot of transaction traffic and create a large window, to reduce
the chances that we run out whilst syncing and have to abort/restart the
sync after resetting the Bloom filter.

If you have a full db index then you can calculate some addresses, query,
if they all get hits, calculate some more, requery, etc. It's a bit simpler.


On Thu, Mar 27, 2014 at 2:58 PM, Jim <jim618@fastmail.co.uk> wrote:

> Good to hear the bip32 wallet structure is _so_ close to being
> standardised.
> For MultiBit HD, we have put in support for 12/18/24 words but have the UI
> 'suggest' to use 12.
> You can see this on the wallet creation wizard Gary recently blogged about:
> https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html
>
> There's a little combo for the seed length, with 12 as the default.
>
>
> @Thomas. You mention gaps. We are creating new addresses on the UI in a
> panel marked 'Request' where the user also types in a QR code label and a
> note to themselves. This gets stored away as a first class
> 'PaymentRequest'. The UI 'suggests' that each address is used once. There
> will be some gaps (where the payment request is never paid) but we aren't
> bulk creating addresses. I am hoping this shouldn't cause Electrum a
> problem.
>
> We are also storing a timestamp (the number of days since the genesis
> block) to help wallet restore but that is SPV specific.
>
>
> On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:
> >
> >
> > Le 27/03/2014 13:49, Mike Hearn a écrit :
> IP32 allows for a range of entropy sizes and it so happens that
> > > they picked 256 bits instead of 128 bits.
> > >
> > > I'd have thought that there is a right answer for this. 2^128 should
> not
> > > be brute forceable, and longer sizes have a cost in terms of making the
> > > seeds harder to write down on paper. So should this be a degree of
> freedom?
> > >
> >
> >
> > Here is what I understand:
> >
> > 2^128 iterations is not brute forcable today, and will not be for the
> > foreseeable future.
> >
> > An EC pubkey of length n can be forced in approximately 2^(n/2)
> > iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which
> > are 256 bits, would require 2^128 iterations. This is why unused
> > addresses (160 bits hash) are better protected than already used ones.
> >
> > However, people tend to believe that a public key of size n requires 2^n
> > iterations. This belief might have been spread by this popular image:
> > https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> http://bitcoin-solutions.co.uk
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>