* [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
@ 2012-12-03 13:49 Amir Taaki
2012-12-03 13:54 ` Pieter Wuille
0 siblings, 1 reply; 4+ messages in thread
From: Amir Taaki @ 2012-12-03 13:49 UTC (permalink / raw)
To: bitcoin-development
Can this be amended? I think it makes much more sense to allow people to input labels not numbers at this level.
General category names for different accounts is much more human than numbers, and you can still use incrementing numbers if you prefer.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
2012-12-03 13:49 [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers Amir Taaki
@ 2012-12-03 13:54 ` Pieter Wuille
2012-12-03 14:48 ` Amir Taaki
0 siblings, 1 reply; 4+ messages in thread
From: Pieter Wuille @ 2012-12-03 13:54 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On Mon, Dec 3, 2012 at 2:49 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> Can this be amended? I think it makes much more sense to allow people to
> input labels not numbers at this level.
>
> General category names for different accounts is much more human than
> numbers, and you can still use incrementing numbers if you prefer.
>
There is no way to iterate over all strings. The intention is that a wallet
application can detect a new account that becomes in use (e.g. during
disaster recovery), so the accounts get assigned incrementing numbers.
I wouldn't mind adding the ability to do "non-standard derivations" using
arbitrary strings, if this recoverability property is not desired.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 1093 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
2012-12-03 13:54 ` Pieter Wuille
@ 2012-12-03 14:48 ` Amir Taaki
2012-12-03 20:44 ` Pieter Wuille
0 siblings, 1 reply; 4+ messages in thread
From: Amir Taaki @ 2012-12-03 14:48 UTC (permalink / raw)
To: bitcoin-development
ok, also what is the reasoning behind serialising points using a compressed format before going into the hash function? I'm looking at the sec1-v2.pdf and the compression format is a little confusing.
I think the octet string for X is 32 bytes (using q = curve.order) and secp256k1 is a prime field so we follow step 2.2.1
________________________________
From: Pieter Wuille <pieter.wuille@gmail•com>
To: Amir Taaki <zgenjix@yahoo•com>
Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
Sent: Monday, December 3, 2012 2:54 PM
Subject: Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
On Mon, Dec 3, 2012 at 2:49 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
Can this be amended? I think it makes much more sense to allow people to input labels not numbers at this level.
>
>General category names for different accounts is much more human than numbers, and you can still use incrementing numbers if you prefer.
>
There is no way to iterate over all strings. The intention is that a wallet application can detect a new account that becomes in use (e.g. during disaster recovery), so the accounts get assigned incrementing numbers.
I wouldn't mind adding the ability to do "non-standard derivations" using arbitrary strings, if this recoverability property is not desired.
--
Pieter
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
2012-12-03 14:48 ` Amir Taaki
@ 2012-12-03 20:44 ` Pieter Wuille
0 siblings, 0 replies; 4+ messages in thread
From: Pieter Wuille @ 2012-12-03 20:44 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
On Mon, Dec 03, 2012 at 06:48:34AM -0800, Amir Taaki wrote:
> ok, also what is the reasoning behind serialising points using a compressed
> format before going into the hash function? I'm looking at the sec1-v2.pdf
> and the compression format is a little confusing.
I don't think there is a compelling reason to encourage uncompressed public
keys anymore on the network. They take more space in the block chain for no
additional value whatsoever. Software may of course continue supporting
uncompressed keys if they wish to provide compatibility, but for a new
standard, I think it makes sense to standardize on just compressed keys.
And since that software thus needs to support the compressed encoding,
there is no reason to use a different encoding inside the derivation scheme
itself.
Regarding the encoding itself, it is not hard: just 0x02 or 0x03 (depending
on whether Y is even or odd) followed by the 32-byte encoding of X. Decoding
is harder, but is never needed in the derivation. Software internally can use
any representation (and it will), which in almost all circumstances stores
both X and Y (and even more). Decoding compressed public keys is somewhat
harder, as Y must be reconstructed (but the algorithm isn't hard) - this is
only necessary when someone wants to import an extended public key though for
watch-only wallets.
--
Pieter
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-12-03 20:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-03 13:49 [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers Amir Taaki
2012-12-03 13:54 ` Pieter Wuille
2012-12-03 14:48 ` Amir Taaki
2012-12-03 20:44 ` Pieter Wuille
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox