📅 Original date posted:2014-04-23
📝 Original message:On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>
> Storing the seed is superior to storing the master node already
> (whether coin specific or not), as it is smaller.
>
>
...Except that you're loosing flexibility (serialization, deserialization)
which gives you BIP32 node.
I see "bip32 seed" as some transitional, internal state from raw entropy to
bip32 master node and this seed should not be handled by the end user in
any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
mnemonic format) can be used very widely and have no downsides against
using raw "bip32 seed".
>
> 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).
>
>
I also don't care too much about altcoins, but people want them so me, as
infrastructure developer, need to think about it. And I don't see any
reason for breaking compatibility between Bitcoin and other altcoins. I
would be happier if there will be another sentence than "Bitcoin seed", but
honestly, who cares. It is just some magic string for hashing the raw
seed...
> 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 truth is that even existing software which handle bip32 don't care
about 'version' at all. I think that "xpub/xprv" distinction is the only
useful feature of version, so user se if it stores public or private
information.
But using prefixes which doesn't enforce anything is even more dangerous.
If somebody exports node "dogeblablabla", it creates false exceptations
that there's only dogecoin stored.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/8d56414d/attachment.html>;
slush [ARCHIVE] /
npub1ad…gl2p6
2023-06-07 15:17:52
in reply to nevent1q…9yl3
Author Public Key
npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6Published at
2023-06-07 15:17:52Event JSON
{
"id": "ea02c04187b7971c1c25d604bdf522b15f797a0dcd8b9d4d2402fdf091248095",
"pubkey": "eb7ca795057ca7cabde6f541c741e661d013414934e5934c2e04c6677625c99a",
"created_at": 1686151072,
"kind": 1,
"tags": [
[
"e",
"3d6a81230db6ab232d8356d3ea7e609f18aff1b8f11502ea70755e81b0de88f9",
"",
"root"
],
[
"e",
"81f1fa5d4b3d4afbfe4f3f59df114713d4f03f887adeaea9661dd7035becbf55",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2014-04-23\n📝 Original message:On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\u003e\n\u003e Storing the seed is superior to storing the master node already\n\u003e (whether coin specific or not), as it is smaller.\n\u003e\n\u003e\n...Except that you're loosing flexibility (serialization, deserialization)\nwhich gives you BIP32 node.\n\nI see \"bip32 seed\" as some transitional, internal state from raw entropy to\nbip32 master node and this seed should not be handled by the end user in\nany form. In the oposite, well-serialized bip32 node (in xpriv, or even in\nmnemonic format) can be used very widely and have no downsides against\nusing raw \"bip32 seed\".\n\n\n\u003e\n\u003e Fair enough, it would break strictly BIP32. Then again, BIP32 is a\n\u003e *Bitcoin* improvement proposal, and not something that necessarily\n\u003e applies to other coins (they can adopt it of course, I don't care).\n\u003e\n\u003e\nI also don't care too much about altcoins, but people want them so me, as\ninfrastructure developer, need to think about it. And I don't see any\nreason for breaking compatibility between Bitcoin and other altcoins. I\nwould be happier if there will be another sentence than \"Bitcoin seed\", but\nhonestly, who cares. It is just some magic string for hashing the raw\nseed...\n\n\n\u003e What I dislike is that this removes the ability of using the magic in\n\u003e the serialization to prevent importing a chain from the wrong coin.\n\u003e\n\nThe truth is that even existing software which handle bip32 don't care\nabout 'version' at all. I think that \"xpub/xprv\" distinction is the only\nuseful feature of version, so user se if it stores public or private\ninformation.\n\nBut using prefixes which doesn't enforce anything is even more dangerous.\nIf somebody exports node \"dogeblablabla\", it creates false exceptations\nthat there's only dogecoin stored.\n\n Marek\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/8d56414d/attachment.html\u003e",
"sig": "3b543c71cf0bca30fb114e20e3432f88765793516b1c91ae3a82eac48187ebb94ff2430f55c6aa3385a4ca12e4a679803ebf4948ec5f9007b46c1def1d367c2b"
}