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