📅 Original date posted:2012-12-05
📝 Original message:I've implemented an alternative to the BIP 32 proposal. I wanted a system
based on a hierarchical string representation (rather than hierarchy of
integers as BIP 32 proposes). For example I name keys like this:
[hd1.75491111].store.1. 1D7GM5dkUtxvGeWgn7SYtanBuyj1MD1EZy
[hd1.75491111].store.2. 1QAqDbzpNKViGSjVe1XmnGbmZtvz5hM7t1
[hd1.75491111].store.3. 14XkSN92QLGeorYPpoVbG87DQhowEx3mFn
[hd1.75491111].store.4. 1JLcGdod6Wm33rMZuZZUmAEE6osLhM4QMn
First draft of proposal:
https://gist.github.com/4211704
I envision using this in services, so I've not done any work to recommend
how the keys would be represented directly in the client (I just map from a
seed value and
a hierarchy string in order to deterministic ally derive ECDSA public and
private keys).
I'm happy to release my source code for this (Python). But I'd first like
to get feedback about any security concerns with my scheme (I note that I
don't introduce the enlarged
key space that BIP 32 does with its "chain code" - I'm wondering if that
represents a weakness of my scheme vs. BIP 32).
On Mon, Dec 3, 2012 at 12:44 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel
> projects.
> http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf>; - What you need
to know about Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121204/9a5e0265/attachment.html>;
Mike Koss [ARCHIVE] /
npub1ds…r0vwj
2023-06-07 10:46:48
in reply to nevent1q…3wzc
Author Public Key
npub1ds6uhns4wgqe6guczwe5t05ccx9hgzjsw2xxuuv3mmugfjsc5pvqer0vwjPublished at
2023-06-07 10:46:48Event JSON
{
"id": "4f9b6728b2770cdeca2d97cb14d90611b1dfeede2cdd51806c96cf73e2b0fbf3",
"pubkey": "6c35cbce1572019d239813b345be98c18b740a50728c6e7191def884ca18a058",
"created_at": 1686134808,
"kind": 1,
"tags": [
[
"e",
"b257447194c9651ebae383b5fac583c1f69d5d0a5d9af934aa36885ff6ff0a91",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2012-12-05\n📝 Original message:I've implemented an alternative to the BIP 32 proposal. I wanted a system\nbased on a hierarchical string representation (rather than hierarchy of\nintegers as BIP 32 proposes). For example I name keys like this:\n\n[hd1.75491111].store.1. 1D7GM5dkUtxvGeWgn7SYtanBuyj1MD1EZy\n[hd1.75491111].store.2. 1QAqDbzpNKViGSjVe1XmnGbmZtvz5hM7t1\n[hd1.75491111].store.3. 14XkSN92QLGeorYPpoVbG87DQhowEx3mFn\n[hd1.75491111].store.4. 1JLcGdod6Wm33rMZuZZUmAEE6osLhM4QMn\n\nFirst draft of proposal:\n\nhttps://gist.github.com/4211704\n\n\nI envision using this in services, so I've not done any work to recommend\nhow the keys would be represented directly in the client (I just map from a\nseed value and\na hierarchy string in order to deterministic ally derive ECDSA public and\nprivate keys).\n\nI'm happy to release my source code for this (Python). But I'd first like\nto get feedback about any security concerns with my scheme (I note that I\ndon't introduce the enlarged\nkey space that BIP 32 does with its \"chain code\" - I'm wondering if that\nrepresents a weakness of my scheme vs. BIP 32).\n\nOn Mon, Dec 3, 2012 at 12:44 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\n\u003e On Mon, Dec 03, 2012 at 06:48:34AM -0800, Amir Taaki wrote:\n\u003e \u003e ok, also what is the reasoning behind serialising points using a\n\u003e compressed\n\u003e \u003e format before going into the hash function? I'm looking at the\n\u003e sec1-v2.pdf\n\u003e \u003e and the compression format is a little confusing.\n\u003e\n\u003e I don't think there is a compelling reason to encourage uncompressed public\n\u003e keys anymore on the network. They take more space in the block chain for no\n\u003e additional value whatsoever. Software may of course continue supporting\n\u003e uncompressed keys if they wish to provide compatibility, but for a new\n\u003e standard, I think it makes sense to standardize on just compressed keys.\n\u003e And since that software thus needs to support the compressed encoding,\n\u003e there is no reason to use a different encoding inside the derivation scheme\n\u003e itself.\n\u003e\n\u003e Regarding the encoding itself, it is not hard: just 0x02 or 0x03 (depending\n\u003e on whether Y is even or odd) followed by the 32-byte encoding of X.\n\u003e Decoding\n\u003e is harder, but is never needed in the derivation. Software internally can\n\u003e use\n\u003e any representation (and it will), which in almost all circumstances stores\n\u003e both X and Y (and even more). Decoding compressed public keys is somewhat\n\u003e harder, as Y must be reconstructed (but the algorithm isn't hard) - this is\n\u003e only necessary when someone wants to import an extended public key though\n\u003e for\n\u003e watch-only wallets.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Keep yourself connected to Go Parallel:\n\u003e BUILD Helping you discover the best ways to construct your parallel\n\u003e projects.\n\u003e http://goparallel.sourceforge.net\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\n\n\n-- \nMike Koss\nCTO, CoinLab\n(425) 246-7701 (m)\n\nA Bitcoin Primer \u003chttp://coinlab.com/a-bitcoin-primer.pdf\u003e - What you need\nto know about Bitcoins.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121204/9a5e0265/attachment.html\u003e",
"sig": "655682c79d2e07d38f043d5a4c9ea0997cb46f4e0173982487dda9b947854b92148c35a4ea5707c1cc33be41bf0f2dcf71511880428cb5d5ec026851fbf97573"
}