📅 Original date posted:2013-10-26
📝 Original message:Let's first try to agree on what we are solving.
It seems that Thomas wants - in addition to the cryptographic data -
to encode the tree structure, or at least version information about
what features are used in it, inside the seed.
I'm not sure whether we're ready to standardize on something like that
yet, not having established best practices regarding different wallet
structures. I do think we first need to see what possibilities and
developments are possible related to it.
In addition, information about the wallet structure is strictly less
secret than the key data - it is even less confidential than address
book data, transaction annotations, labels and comments and
bookkeeping information. It could be backed up anywhere and everywhere
without any repercussions, as far as I can see. I understand that in
the case of Electrum, there is a strong reason to want this
encapsulated together with the seed, but it's not really a requirement
for most wallets.
(if really needed, any key derivation scheme that starts from random
strings can be augmented with metadata by enforcing property-bits on a
hash of the string (so not of the output), as this data doesn't need
protection from brute-forcing).
Regarding other requirements, I wonder why we want the transformation
to be bidirectional? If it is just about generating master seeds, one
direction should be enough, and allows far nicer properties w.r.t.
security. If we do settle on a standard for 'brainwallets', I would
strongly prefer if it had at least some strengthening built-in, to
decrease the impact of worst-case situations.
If the reason is backward-compatibility, I think that any client that
supports seeds already can just keep supporting whatever they
supported before. Only if it matches both encoding schemes (as
mentioned before) there is a potential collision (and in that case,
the user could just be asked).
--
Pieter
On Sat, Oct 26, 2013 at 10:47 PM, slush <slush at centrum.cz> wrote:
> Hi Thomas,
>
> can you more elaborate on that "version" bits? What is exact meaning of it?
> I still think this is more an implementation problem. What stops Electrum to
> do the same algorithm for searching branches as it is now for used
> addresses?
>
> These "version bits" need to be covered by the specification as well,
> because if any client will use them differently (or won't use them at all),
> it will break cross-compatibility between clients, which was another goal of
> bip39.
>
> Marek
>
>
>
>
> On Sat, Oct 26, 2013 at 5:24 PM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
>>
>> here is a simple implementation, with some ideas on how to format the
>> metadata:
>> https://en.bitcoin.it/wiki/Talk:BIP_0039
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:08:01
in reply to nevent1q…rctp
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:08:01Event JSON
{
"id": "9fc3894435ada2292116d1b2c6a1b311eac99ebcbe1f5b4253c15b43b69695bc",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686150481,
"kind": 1,
"tags": [
[
"e",
"7e718d510a3d5e22e518f7bf94409c5e05c663f2a1066298ced00d73c104e803",
"",
"root"
],
[
"e",
"37a5fb467fdf2538b3e593da586b57f4c9562818b80c694e4da75212cd332780",
"",
"reply"
],
[
"p",
"eb7ca795057ca7cabde6f541c741e661d013414934e5934c2e04c6677625c99a"
]
],
"content": "📅 Original date posted:2013-10-26\n📝 Original message:Let's first try to agree on what we are solving.\n\nIt seems that Thomas wants - in addition to the cryptographic data -\nto encode the tree structure, or at least version information about\nwhat features are used in it, inside the seed.\n\nI'm not sure whether we're ready to standardize on something like that\nyet, not having established best practices regarding different wallet\nstructures. I do think we first need to see what possibilities and\ndevelopments are possible related to it.\n\nIn addition, information about the wallet structure is strictly less\nsecret than the key data - it is even less confidential than address\nbook data, transaction annotations, labels and comments and\nbookkeeping information. It could be backed up anywhere and everywhere\nwithout any repercussions, as far as I can see. I understand that in\nthe case of Electrum, there is a strong reason to want this\nencapsulated together with the seed, but it's not really a requirement\nfor most wallets.\n(if really needed, any key derivation scheme that starts from random\nstrings can be augmented with metadata by enforcing property-bits on a\nhash of the string (so not of the output), as this data doesn't need\nprotection from brute-forcing).\n\nRegarding other requirements, I wonder why we want the transformation\nto be bidirectional? If it is just about generating master seeds, one\ndirection should be enough, and allows far nicer properties w.r.t.\nsecurity. If we do settle on a standard for 'brainwallets', I would\nstrongly prefer if it had at least some strengthening built-in, to\ndecrease the impact of worst-case situations.\nIf the reason is backward-compatibility, I think that any client that\nsupports seeds already can just keep supporting whatever they\nsupported before. Only if it matches both encoding schemes (as\nmentioned before) there is a potential collision (and in that case,\nthe user could just be asked).\n\n-- \nPieter\n\n\nOn Sat, Oct 26, 2013 at 10:47 PM, slush \u003cslush at centrum.cz\u003e wrote:\n\u003e Hi Thomas,\n\u003e\n\u003e can you more elaborate on that \"version\" bits? What is exact meaning of it?\n\u003e I still think this is more an implementation problem. What stops Electrum to\n\u003e do the same algorithm for searching branches as it is now for used\n\u003e addresses?\n\u003e\n\u003e These \"version bits\" need to be covered by the specification as well,\n\u003e because if any client will use them differently (or won't use them at all),\n\u003e it will break cross-compatibility between clients, which was another goal of\n\u003e bip39.\n\u003e\n\u003e Marek\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Sat, Oct 26, 2013 at 5:24 PM, Thomas Voegtlin \u003cthomasv1 at gmx.de\u003e wrote:\n\u003e\u003e\n\u003e\u003e here is a simple implementation, with some ideas on how to format the\n\u003e\u003e metadata:\n\u003e\u003e https://en.bitcoin.it/wiki/Talk:BIP_0039\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e October Webinars: Code for Performance\n\u003e\u003e Free Intel webinars can help you accelerate application performance.\n\u003e\u003e Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most\n\u003e\u003e from\n\u003e\u003e the latest Intel processors and coprocessors. See abstracts and register \u003e\n\u003e\u003e\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=60135991\u0026iu=/4140/ostg.clktrk\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 ------------------------------------------------------------------------------\n\u003e October Webinars: Code for Performance\n\u003e Free Intel webinars can help you accelerate application performance.\n\u003e Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most\n\u003e from\n\u003e the latest Intel processors and coprocessors. See abstracts and register \u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=60135991\u0026iu=/4140/ostg.clktrk\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",
"sig": "85a9ae14334c0cdd73c449a50fb4e26d8aa132adff41b63eab435c4e1625cdeeb87115380feb2e3a189f031785a11047e0ab581251837043058492dc2e84de57"
}