From: Gregory Maxwell <greg@xiph.org>
To: shiva sitamraju <shiva@blockonomics.co>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New serialization/encoding format for key material
Date: Wed, 30 May 2018 14:08:08 +0000 [thread overview]
Message-ID: <CAAS2fgQHJk10oUTM1M=x23REaydtAdVSeNVdLr_fMGPgwN4aig@mail.gmail.com> (raw)
In-Reply-To: <CABuOfuhMGFGc1tyjcOmnUk1OrWp2d6ppKc8phLT9pXCj8vs+qg@mail.gmail.com>
On Wed, May 30, 2018 at 6:30 AM, shiva sitamraju via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The idea to add birthdate and gap limit sounds very good and addresses lots
> of problems users are facing.
>
> However, adding birthday to keys breaks two basic properties
>
> - Visually Comparing two keys to find if they are same (Important)
Can you explain exactly what you mean there? I can think of to
plausible meanings (that two valid keys could differ by only a single
symbol, which wouldn't be true due to the checksum and could be made
even stronger if we thought that would be useful or I think you could
also be complaining that the same "key material" could be encoded two
ways which I think is both harmless and unavoidable for anything
versioned).
> - Different wallet software could set different birthday/gap limit. creating
> different xpub/xprv for the same set of mathematically derived individual
> keys. This removes the decoupling between key and wallet metadata
Personally, I think it's a mistake to believe that any key format can
really make private keying material strongly compatible between
wallets. At best you can hope for a mostly compatible kind of recovery
handling.
But the lookahead amount may be pretty integral to the design of the
software, so signaling it may not mean the other side can obey the
signal... but that wouldn't make the signal completely useless.
next prev parent reply other threads:[~2018-05-30 14:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 6:30 [bitcoin-dev] New serialization/encoding format for key material shiva sitamraju
2018-05-30 14:08 ` Gregory Maxwell [this message]
2018-05-30 19:03 ` Jonas Schnelli
2018-06-03 16:51 ` Jonas Schnelli
2018-06-03 19:23 ` Pieter Wuille
2018-06-03 21:30 ` Jonas Schnelli
2018-06-13 2:44 ` Pieter Wuille
2018-06-15 15:54 ` Russell O'Connor
2018-06-23 19:49 ` Pieter Wuille
-- strict thread matches above, loose matches on Subject: below --
2018-05-29 9:13 Jonas Schnelli
2018-06-13 14:58 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgQHJk10oUTM1M=x23REaydtAdVSeNVdLr_fMGPgwN4aig@mail.gmail.com' \
--to=greg@xiph.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=shiva@blockonomics.co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox