From: Mike Hearn <mike@plan99•net>
To: Jim <jim618@fastmail•co.uk>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Date: Thu, 27 Mar 2014 15:20:32 +0100 [thread overview]
Message-ID: <CANEZrP22Ta7LEgjNLjufs5skA1RaSB+mivqcMHj0iJBNNjZL3Q@mail.gmail.com> (raw)
In-Reply-To: <1395928699.5369.99593201.1CFF9238@webmail.messagingengine.com>
[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4851 bytes --]
next prev parent reply other threads:[~2014-03-27 14:20 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 20:49 Mike Hearn
2014-03-26 23:37 ` Andreas Schildbach
2014-03-27 1:01 ` Alan Reiner
2014-03-27 6:15 ` Mike Belshe
2014-03-27 10:57 ` Thomas Voegtlin
2014-03-27 11:39 ` Mike Hearn
2014-03-27 13:30 ` Thomas Voegtlin
2014-03-27 13:38 ` Mike Hearn
2014-03-27 1:13 ` Allen Piscitello
2014-03-27 5:34 ` Troy Benjegerdes
2014-03-27 7:09 ` Tamas Blummer
2014-03-27 9:42 ` Mike Hearn
2014-03-27 11:35 ` Pavol Rusnak
2014-03-27 15:43 ` Jeff Garzik
2014-03-27 15:57 ` Allen Piscitello
2014-03-27 16:06 ` Pavol Rusnak
2014-03-27 16:13 ` Allen Piscitello
2014-03-27 16:07 ` Tamas Blummer
2014-03-27 16:14 ` Pieter Wuille
2014-03-27 16:21 ` Pavol Rusnak
2014-03-27 16:28 ` Pieter Wuille
2014-03-27 17:49 ` Allen Piscitello
2014-03-28 14:59 ` slush
2014-04-08 12:43 ` slush
2014-04-08 13:18 ` Pieter Wuille
2014-04-08 13:40 ` slush
2014-04-08 13:43 ` slush
2014-04-08 13:53 ` Pieter Wuille
2014-04-08 13:59 ` Thomas Voegtlin
2014-04-08 14:00 ` Tamas Blummer
2014-04-08 14:35 ` Pavol Rusnak
2014-04-08 15:41 ` slush
2014-04-23 17:42 ` Pieter Wuille
2014-04-23 18:01 ` slush
2014-04-23 18:18 ` slush
2014-04-23 18:39 ` Tier Nolan
2014-04-23 18:46 ` Pavol Rusnak
2014-04-23 19:00 ` Tier Nolan
2014-04-23 19:06 ` slush
2014-04-23 19:36 ` Tamas Blummer
2014-04-23 19:46 ` slush
2014-04-23 19:07 ` Tamas Blummer
2014-04-23 19:29 ` Pavol Rusnak
2014-04-23 19:44 ` Luke-Jr
2014-04-23 19:49 ` Pavol Rusnak
2014-04-23 19:55 ` Luke-Jr
2014-04-23 19:57 ` slush
2014-04-23 20:01 ` Luke-Jr
2014-04-23 20:04 ` Pavol Rusnak
2014-04-23 20:09 ` Luke-Jr
2014-04-23 20:16 ` Pavol Rusnak
2014-04-23 20:32 ` Luke-Jr
2014-04-23 20:35 ` Pavol Rusnak
2014-04-23 20:41 ` Luke-Jr
2014-04-23 20:43 ` Pavol Rusnak
2014-04-23 20:54 ` Pieter Wuille
2014-04-23 21:06 ` Pavol Rusnak
2014-04-23 21:18 ` Luke-Jr
2014-04-23 21:22 ` Gregory Maxwell
2014-04-23 21:33 ` Pavol Rusnak
2014-04-23 21:42 ` Pieter Wuille
2014-04-23 21:44 ` Pavol Rusnak
2014-04-23 21:48 ` Gregory Maxwell
2014-04-23 21:53 ` Luke-Jr
2014-04-23 21:24 ` Pavol Rusnak
2014-04-23 21:07 ` slush
2014-04-23 20:59 ` Luke-Jr
2014-04-23 20:17 ` Tamas Blummer
2014-04-23 20:12 ` Pieter Wuille
2014-04-23 20:08 ` Pieter Wuille
2014-04-23 20:01 ` Tamas Blummer
2014-04-23 20:02 ` Luke-Jr
2014-04-23 20:04 ` Tamas Blummer
2014-04-24 6:54 ` Thomas Voegtlin
2014-04-24 7:10 ` Pieter Wuille
2014-04-24 7:21 ` Gregory Maxwell
2014-04-24 8:15 ` Thomas Voegtlin
2014-04-24 7:42 ` Thomas Voegtlin
2014-04-24 8:09 ` Mike Hearn
2014-04-23 18:48 ` Tamas Blummer
2014-04-08 14:49 ` Andreas Schildbach
2014-04-08 15:46 ` slush
2014-04-08 15:58 ` Andreas Schildbach
2014-04-08 16:24 ` slush
2014-03-27 11:20 ` Thomas Voegtlin
[not found] ` <CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
2014-03-27 12:06 ` Thomas Voegtlin
2014-03-27 12:28 ` Mike Hearn
2014-03-27 12:49 ` Mike Hearn
2014-03-27 13:12 ` Thomas Kerin
2014-03-27 13:19 ` Mike Hearn
2014-03-27 13:49 ` Thomas Voegtlin
2014-03-27 13:58 ` Jim
2014-03-27 14:20 ` Mike Hearn [this message]
2014-03-27 15:17 ` Troy Benjegerdes
2014-03-27 13:07 ` Matias Alejo Garcia
2014-03-27 13:44 ` Pavol Rusnak
2014-03-27 13:53 ` Thomas Voegtlin
2014-03-27 14:03 ` Pavol Rusnak
[not found] ` <CAJna-HitjJbL9TnfxTY=+TvfaeNvZM6aPWmNYmHUCwmw6V8PUg@mail.gmail.com>
2014-03-27 15:04 ` Thomas Voegtlin
2014-03-27 11:36 ` Pavol Rusnak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP22Ta7LEgjNLjufs5skA1RaSB+mivqcMHj0iJBNNjZL3Q@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jim618@fastmail$(echo .)co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox