slush [ARCHIVE] on Nostr: 📅 Original date posted:2013-10-31 📝 Original message:On Thu, Oct 31, 2013 at ...
📅 Original date posted:2013-10-31
📝 Original message:On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
> Indeed, I want to include a version number in the seed phrase because
> there are
> multiple ways to define the tree structure used with BIP32. It is
> certainly too early
> to make final decisions on that, or to achieve a common standard.
>
Well, as we're the first pioneers of bip32, let's start using it in some
sane way and I'm sure the others will join. Just because they don't want to
incompatible software.
Actually I quite like that you're not wasting bip32 space by using some
dynamic allocatons in higher address space, so I'm happy to follow your
rules and I think we can agree on generic discover algorithm which maybe
won't be optimal, but will find all used addresses and won't need any
additional information directly in mnemonic.
As I wrote in previous post, in worst case I can imagine dropdown list on
import dialog, which will ask user which software has been handling the
seed before, to speedup the scan. But for now I don't see this necessary at
all.
Also, I can imagine that bip32 itself might be superseeded in the future.
>
>
Although I can imagine that as well, I hope that it won't be the case. We
need to unite and integrate instead of making incompatible applications.
One disadvantage of bip32 is that in fact it is too much flexible, so we
even falled into the necessity of defining version of discovery algorithm.
Lets set up best practices how to use it and other will follow instead of
creating zillion cross-incompatible algorithms which won't understand each
to other.
> The other question we might be solving is strenghtening (your proposal).
> I consider
> that this is not a strong requirement for Electrum, because it does not
> let the user
> choose their seed phrase. However, if a few bits of the seed phrase are
>
Hardening and password protection are two unrelated requirements. Again,
there are some scenarios in which use can leak part of the mnemonic to
attacker, so hardening prevent to bruteforce the rest information by
attacker, even if the mnemonic isn't passphrase protected.
I'm especially refering to our algorithm of mnemonic import to Trezor
during disaster recovery (when Trezor is destroyed and user wants to import
the seed to another one), so that leak isn't just a theoretical concept,
but real-word scenario.
> allocated
for metadata, then I guess strenghtening can be part of it. That's
> another good
> reason to have a version number encapsulated in the seed.
>
Actually creating optional features of such algorithm only make things
complicated (and less cross-compatible). Every software still needs to
implement such hardening even if it is optional feature, to be compatible
with other clients. Then I don't see any reason why to have it optional.
Don't forget that the proposal uses only 4 bits of version, which isn't too
much combination for all these optional features ;-).
I too wonder why the transformation needs to be bidirectional in bip39.
>
>
Well, I wrote longer answer in previous email. tl;dr; there's quite easy
way how to make the algorithm bi-directional, so I don't see a necessity to
drop potentially useful feature for no good reason.
I was thinking about your proposal and I realized that both our solutions
solves a bit different problem. Lets summarize features (and forget to
wordlist fights for moment):
bip39:
+ bi-directional
+ passphrase protected
+ shorter mnemonic or shorter wordlist
- predefined wordlist
ThomasV proposal:
+ any software can has its own preferred worlist
? passphrase protected
- one-direction only
- longer mnemonic or longer wordlist
Back to wordlist fights
a) actually I think that the wordlist choice is far less important than it
may look at first glance. Thomas thinks that bip39 wordlist is disaster, me
and many other thinks it is ok, but mainly that it is very subjective.
b) I see the beauty of "custom wordlists" in Thomas proposal, still if it
means the algorithm is uni-direction only, it is very strong disadvantage
to our usecase.
c) I advocated our wordlist mainly because we put a lot of effort into it
and after many weeks of tuning it is already done; not because I think that
one method of picking the words is superior to other. I mean - if Thomas
can offer any other plain-english wordlist which he'll be happy with, I'll
vote for dropping our own wordlist and to use Thomas's version for the deal
that he'll accept our need for bi-directionality and he agrees on the rest
of bip39 ;-).
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131031/22ee437e/attachment.html>;
📝 Original message:On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
> Indeed, I want to include a version number in the seed phrase because
> there are
> multiple ways to define the tree structure used with BIP32. It is
> certainly too early
> to make final decisions on that, or to achieve a common standard.
>
Well, as we're the first pioneers of bip32, let's start using it in some
sane way and I'm sure the others will join. Just because they don't want to
incompatible software.
Actually I quite like that you're not wasting bip32 space by using some
dynamic allocatons in higher address space, so I'm happy to follow your
rules and I think we can agree on generic discover algorithm which maybe
won't be optimal, but will find all used addresses and won't need any
additional information directly in mnemonic.
As I wrote in previous post, in worst case I can imagine dropdown list on
import dialog, which will ask user which software has been handling the
seed before, to speedup the scan. But for now I don't see this necessary at
all.
Also, I can imagine that bip32 itself might be superseeded in the future.
>
>
Although I can imagine that as well, I hope that it won't be the case. We
need to unite and integrate instead of making incompatible applications.
One disadvantage of bip32 is that in fact it is too much flexible, so we
even falled into the necessity of defining version of discovery algorithm.
Lets set up best practices how to use it and other will follow instead of
creating zillion cross-incompatible algorithms which won't understand each
to other.
> The other question we might be solving is strenghtening (your proposal).
> I consider
> that this is not a strong requirement for Electrum, because it does not
> let the user
> choose their seed phrase. However, if a few bits of the seed phrase are
>
Hardening and password protection are two unrelated requirements. Again,
there are some scenarios in which use can leak part of the mnemonic to
attacker, so hardening prevent to bruteforce the rest information by
attacker, even if the mnemonic isn't passphrase protected.
I'm especially refering to our algorithm of mnemonic import to Trezor
during disaster recovery (when Trezor is destroyed and user wants to import
the seed to another one), so that leak isn't just a theoretical concept,
but real-word scenario.
> allocated
for metadata, then I guess strenghtening can be part of it. That's
> another good
> reason to have a version number encapsulated in the seed.
>
Actually creating optional features of such algorithm only make things
complicated (and less cross-compatible). Every software still needs to
implement such hardening even if it is optional feature, to be compatible
with other clients. Then I don't see any reason why to have it optional.
Don't forget that the proposal uses only 4 bits of version, which isn't too
much combination for all these optional features ;-).
I too wonder why the transformation needs to be bidirectional in bip39.
>
>
Well, I wrote longer answer in previous email. tl;dr; there's quite easy
way how to make the algorithm bi-directional, so I don't see a necessity to
drop potentially useful feature for no good reason.
I was thinking about your proposal and I realized that both our solutions
solves a bit different problem. Lets summarize features (and forget to
wordlist fights for moment):
bip39:
+ bi-directional
+ passphrase protected
+ shorter mnemonic or shorter wordlist
- predefined wordlist
ThomasV proposal:
+ any software can has its own preferred worlist
? passphrase protected
- one-direction only
- longer mnemonic or longer wordlist
Back to wordlist fights
a) actually I think that the wordlist choice is far less important than it
may look at first glance. Thomas thinks that bip39 wordlist is disaster, me
and many other thinks it is ok, but mainly that it is very subjective.
b) I see the beauty of "custom wordlists" in Thomas proposal, still if it
means the algorithm is uni-direction only, it is very strong disadvantage
to our usecase.
c) I advocated our wordlist mainly because we put a lot of effort into it
and after many weeks of tuning it is already done; not because I think that
one method of picking the words is superior to other. I mean - if Thomas
can offer any other plain-english wordlist which he'll be happy with, I'll
vote for dropping our own wordlist and to use Thomas's version for the deal
that he'll accept our need for bi-directionality and he agrees on the rest
of bip39 ;-).
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131031/22ee437e/attachment.html>;