devrandom [ARCHIVE] on Nostr: 📅 Original date posted:2015-03-12 📝 Original message:On 2015-03-11 06:21 PM, ...
📅 Original date posted:2015-03-12
📝 Original message:On 2015-03-11 06:21 PM, Thy Shizzle wrote:
> Hmmmm I don't think it's fair to say that there has been a failure to
> standardise. From what I read earlier among the wallets, mostly it came
> down to if a version was noted and the date. Assuming no date is
> provided, it just means you are scanning the block chain from day 0 for
> transactions right? Hardly a big deal as you will still recover funds right?
Unfortunately there's more incompatibility than just the date issue:
* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own
So actually very few wallets are seed-compatible, even ignoring the date
question.
>
> Version right now is irrelevant as there is only one version of BIP39
> currently, probably this will change as 2048 iterations of HMACSHA512
> will likely need to be up scaled in the future, I thought about adding
> one extra word into the mnemonic to signify version, so if you have a 12
> word mnemonic then you have 12 words + 1 word version. Version 1 has no
> extra word, version 2 uses the first word on the list, version 3 uses
> the second word on the wordlist, so on and so forth. Least that's what I
> was thinking of doing if I ever had to record a version, won't effect
> anything because entropy increases in blocks of 3 words so one extra
> word can simply be thrown on the end.
That's a reasonable solution.
>
> So in summary I feel that date can be handled by assuming day 0, and
> version is not an issue yet but may become one and probably it is a good
> idea to think about standardising a version into BIP39, I have
> provided a seed idea for discussion.
>
> I don't think it is quite the doom and gloom I'm reading :)
>
>
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig. The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key. The oracle
> would have different security thresholds for countersigning the mobile.
>
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
>
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling."
--
devrandom / Miron
Published at
2023-06-07 15:31:35Event JSON
{
"id": "2f0d31d4b1b76ccb410b8c5cb277561005fe4f26ff20a9a17ad62969958116a5",
"pubkey": "ebeb63b9f045163c648f5d84faefa323220f6883ca98091c831d7e9da63b294a",
"created_at": 1686151895,
"kind": 1,
"tags": [
[
"e",
"bf192ab1459041905386f8a0c7782f07de04af2932326a4e49fe0d6ce14ed93c",
"",
"root"
],
[
"e",
"87ec530dfe5ed73e7b369388dea4ef9374e63a9ef46ebb8c2d9d817acd6c9507",
"",
"reply"
],
[
"p",
"40e50b0a7433e03f4ed0f27d1999ac8dde959c1af401052898731f7eae6d5ce2"
]
],
"content": "📅 Original date posted:2015-03-12\n📝 Original message:On 2015-03-11 06:21 PM, Thy Shizzle wrote:\n\u003e Hmmmm I don't think it's fair to say that there has been a failure to\n\u003e standardise. From what I read earlier among the wallets, mostly it came\n\u003e down to if a version was noted and the date. Assuming no date is\n\u003e provided, it just means you are scanning the block chain from day 0 for\n\u003e transactions right? Hardly a big deal as you will still recover funds right?\n\nUnfortunately there's more incompatibility than just the date issue:\n\n* seed: some follow BIP39, and some roll their own\n* HD structure: some follow BIP44, some BIP32 derivation, and some roll\ntheir own\n\nSo actually very few wallets are seed-compatible, even ignoring the date\nquestion.\n\n\u003e \n\u003e Version right now is irrelevant as there is only one version of BIP39\n\u003e currently, probably this will change as 2048 iterations of HMACSHA512\n\u003e will likely need to be up scaled in the future, I thought about adding\n\u003e one extra word into the mnemonic to signify version, so if you have a 12\n\u003e word mnemonic then you have 12 words + 1 word version. Version 1 has no\n\u003e extra word, version 2 uses the first word on the list, version 3 uses\n\u003e the second word on the wordlist, so on and so forth. Least that's what I\n\u003e was thinking of doing if I ever had to record a version, won't effect\n\u003e anything because entropy increases in blocks of 3 words so one extra\n\u003e word can simply be thrown on the end.\n\nThat's a reasonable solution.\n\n\u003e \n\u003e So in summary I feel that date can be handled by assuming day 0, and\n\u003e version is not an issue yet but may become one and probably it is a good\n\u003e idea to think about standardising a version into BIP39, I have\n\u003e provided a seed idea for discussion.\n\u003e \n\u003e I don't think it is quite the doom and gloom I'm reading :)\n\u003e \n\u003e \n\u003e devrandom:\n\u003e \"I'd like to offer that the best practice for the shared wallet use case\n\u003e should be multi-device multi-sig. The mobile has a key, the desktop has\n\u003e a key and a third-party security oracle has a third key. The oracle\n\u003e would have different security thresholds for countersigning the mobile.\n\u003e \n\u003e This way you can have the same overall wallet on all devices, but\n\u003e different security profiles on different keys.\n\u003e \n\u003e That said, I do agree that mnemonic phrases should be portable, and find\n\u003e it unfortunate that the ecosystem is failing to standardize on phrase\n\u003e handling.\"\n\n-- \ndevrandom / Miron",
"sig": "8c40e0435485fd7d8c60c523902c2d0cf0e73396d39a747905a21cb4b86b7c513e2b88d4a9eeb18efb2d44d0049c05aa4b49072cf3a64ce4b57d22d781a9efff"
}