📅 Original date posted:2014-03-27
📝 Original message: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 at 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 at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> http://bitcoin-solutions.co.uk
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/0df83769/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:16:23
in reply to nevent1q…u950
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:16:23Event JSON
{
"id": "5d1049debc5d8207731a4eae8428dfdef9c21b1d03a32d36ddda441d1e718bff",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686150983,
"kind": 1,
"tags": [
[
"e",
"d9ddea79394f356d989e65ab112610cc90e9929cf3c160da3cfe266aeba22200",
"",
"root"
],
[
"e",
"4599fb03e29fd4d3e8777193c30b26b4f9812c4392f7bada5c66f72b3eb77a24",
"",
"reply"
],
[
"p",
"e9799fb8f78387b0c1fd27d4d15afa550d214db447d801dae134d0d1703271ec"
]
],
"content": "📅 Original date posted:2014-03-27\n📝 Original message:For SPV wallets it's more complicated. There must always be a large\nlookahead window for latency reasons. We can't query the entire database\nbecause we don't know how far ahead the user is. So we have to assume there\nmight be a lot of transaction traffic and create a large window, to reduce\nthe chances that we run out whilst syncing and have to abort/restart the\nsync after resetting the Bloom filter.\n\nIf you have a full db index then you can calculate some addresses, query,\nif they all get hits, calculate some more, requery, etc. It's a bit simpler.\n\n\nOn Thu, Mar 27, 2014 at 2:58 PM, Jim \u003cjim618 at fastmail.co.uk\u003e wrote:\n\n\u003e Good to hear the bip32 wallet structure is _so_ close to being\n\u003e standardised.\n\u003e For MultiBit HD, we have put in support for 12/18/24 words but have the UI\n\u003e 'suggest' to use 12.\n\u003e You can see this on the wallet creation wizard Gary recently blogged about:\n\u003e https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html\n\u003e\n\u003e There's a little combo for the seed length, with 12 as the default.\n\u003e\n\u003e\n\u003e @Thomas. You mention gaps. We are creating new addresses on the UI in a\n\u003e panel marked 'Request' where the user also types in a QR code label and a\n\u003e note to themselves. This gets stored away as a first class\n\u003e 'PaymentRequest'. The UI 'suggests' that each address is used once. There\n\u003e will be some gaps (where the payment request is never paid) but we aren't\n\u003e bulk creating addresses. I am hoping this shouldn't cause Electrum a\n\u003e problem.\n\u003e\n\u003e We are also storing a timestamp (the number of days since the genesis\n\u003e block) to help wallet restore but that is SPV specific.\n\u003e\n\u003e\n\u003e On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Le 27/03/2014 13:49, Mike Hearn a écrit :\n\u003e IP32 allows for a range of entropy sizes and it so happens that\n\u003e \u003e \u003e they picked 256 bits instead of 128 bits.\n\u003e \u003e \u003e\n\u003e \u003e \u003e I'd have thought that there is a right answer for this. 2^128 should\n\u003e not\n\u003e \u003e \u003e be brute forceable, and longer sizes have a cost in terms of making the\n\u003e \u003e \u003e seeds harder to write down on paper. So should this be a degree of\n\u003e freedom?\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Here is what I understand:\n\u003e \u003e\n\u003e \u003e 2^128 iterations is not brute forcable today, and will not be for the\n\u003e \u003e foreseeable future.\n\u003e \u003e\n\u003e \u003e An EC pubkey of length n can be forced in approximately 2^(n/2)\n\u003e \u003e iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which\n\u003e \u003e are 256 bits, would require 2^128 iterations. This is why unused\n\u003e \u003e addresses (160 bits hash) are better protected than already used ones.\n\u003e \u003e\n\u003e \u003e However, people tend to believe that a public key of size n requires 2^n\n\u003e \u003e iterations. This belief might have been spread by this popular image:\n\u003e \u003e https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e --\n\u003e http://bitcoin-solutions.co.uk\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/0df83769/attachment.html\u003e",
"sig": "72e41e47b46e2920929d563f4e003414270f119757377403d469295b8f73669dc5d109bafc9788590881f797ed66c0694b1305c913cb1c198b61c438eb3e4492"
}