📅 Original date posted:2014-04-23
📝 Original message:On Tue, Apr 8, 2014 at 5:41 PM, slush <slush at centrum.cz> wrote:
> I've discussed the solution of "Litecoin seed" in BIP32 HMAC with Litecoin
> devs already, and after long discussion we've concluded that it is generally
> bad idea.
>
> When changing "Bitcoin seed" constant to something different, same *entropy*
> will produce different *master node*. That's actually the opposite what's
> requested, because xprv serialization format stores *node*, not *entropy*.
> By changing HMAC constant, you still won't be able to store one node and
> derive wallets for multiple coins at same time.
Storing the seed is superior to storing the master node already
(whether coin specific or not), as it is smaller.
All this changes is making the seed the "super master" which allows
generating the coin-specific masters (which get an actual useful
function: revealing your entire-tree, but only one coin's subset of
it).
>> * Every encoded node (including master nodes) has a chain-specific
>> serialization magic.
>>
>> This is in practice almost the same as your suggestion, except that
>> the m/cointype' in m/cointype'/account'/change/n is replaced by
>> different masters. The only disadvantage I see is that you do not have
>> a way to encode the "super master" that is the parent of all
>> chain-specific masters. You can - and with the same security
>> properties - encode the seed, though.
>>
>
> Actually I don't understand why there's such disagreement about "cointype"
> level here, what it breaks? I see it as the cleanest solution so far. It is
> forward and backward compatible, does need any special extension to bip32
> (to be strict, bip32 says "Bitcoin seed", so client using "Litecoin seed"
> cannot be "bip32 compatible").
Fair enough, it would break strictly BIP32. Then again, BIP32 is a
*Bitcoin* improvement proposal, and not something that necessarily
applies to other coins (they can adopt it of course, I don't care).
What I dislike is that this removes the ability of using the magic in
the serialization to prevent importing a chain from the wrong coin.
The standard could just say that instead of "Bitcoin seed", you'd use
"Coin seed: " + magic, so you don't need an extra mapping from
cointype to seed strings.
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:17:52
in reply to nevent1q…eqp7
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:17:52Event JSON
{
"id": "81f1fa5d4b3d4afbfe4f3f59df114713d4f03f887adeaea9661dd7035becbf55",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686151072,
"kind": 1,
"tags": [
[
"e",
"3d6a81230db6ab232d8356d3ea7e609f18aff1b8f11502ea70755e81b0de88f9",
"",
"root"
],
[
"e",
"148d8a5e837efc589ebdb33892db6670b516307b332e397c04e15b479f31e2aa",
"",
"reply"
],
[
"p",
"eb7ca795057ca7cabde6f541c741e661d013414934e5934c2e04c6677625c99a"
]
],
"content": "📅 Original date posted:2014-04-23\n📝 Original message:On Tue, Apr 8, 2014 at 5:41 PM, slush \u003cslush at centrum.cz\u003e wrote:\n\u003e I've discussed the solution of \"Litecoin seed\" in BIP32 HMAC with Litecoin\n\u003e devs already, and after long discussion we've concluded that it is generally\n\u003e bad idea.\n\u003e\n\u003e When changing \"Bitcoin seed\" constant to something different, same *entropy*\n\u003e will produce different *master node*. That's actually the opposite what's\n\u003e requested, because xprv serialization format stores *node*, not *entropy*.\n\u003e By changing HMAC constant, you still won't be able to store one node and\n\u003e derive wallets for multiple coins at same time.\n\nStoring the seed is superior to storing the master node already\n(whether coin specific or not), as it is smaller.\n\nAll this changes is making the seed the \"super master\" which allows\ngenerating the coin-specific masters (which get an actual useful\nfunction: revealing your entire-tree, but only one coin's subset of\nit).\n\n\u003e\u003e * Every encoded node (including master nodes) has a chain-specific\n\u003e\u003e serialization magic.\n\u003e\u003e\n\u003e\u003e This is in practice almost the same as your suggestion, except that\n\u003e\u003e the m/cointype' in m/cointype'/account'/change/n is replaced by\n\u003e\u003e different masters. The only disadvantage I see is that you do not have\n\u003e\u003e a way to encode the \"super master\" that is the parent of all\n\u003e\u003e chain-specific masters. You can - and with the same security\n\u003e\u003e properties - encode the seed, though.\n\u003e\u003e\n\u003e\n\u003e Actually I don't understand why there's such disagreement about \"cointype\"\n\u003e level here, what it breaks? I see it as the cleanest solution so far. It is\n\u003e forward and backward compatible, does need any special extension to bip32\n\u003e (to be strict, bip32 says \"Bitcoin seed\", so client using \"Litecoin seed\"\n\u003e cannot be \"bip32 compatible\").\n\nFair enough, it would break strictly BIP32. Then again, BIP32 is a\n*Bitcoin* improvement proposal, and not something that necessarily\napplies to other coins (they can adopt it of course, I don't care).\n\nWhat I dislike is that this removes the ability of using the magic in\nthe serialization to prevent importing a chain from the wrong coin.\nThe standard could just say that instead of \"Bitcoin seed\", you'd use\n\"Coin seed: \" + magic, so you don't need an extra mapping from\ncointype to seed strings.\n\n-- \nPieter",
"sig": "d92574ad23749686321a294731c48f1d1bf634445a4b1cfece2298a55c297f0a5d8116bbe175cf58845adff6d6b1f94aab4be735298104eee6a1184525f3d99d"
}