MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CABuOfuhMGFGc1tyjcOmnUk1OrWp2d6ppKc8phLT9pXCj8vs+qg@mail.gmail.com>
References: <CABuOfuhMGFGc1tyjcOmnUk1OrWp2d6ppKc8phLT9pXCj8vs+qg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 30 May 2018 14:08:08 +0000
Message-ID: <CAAS2fgQHJk10oUTM1M=x23REaydtAdVSeNVdLr_fMGPgwN4aig@mail.gmail.com>
To: shiva sitamraju <shiva@blockonomics.co>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] New serialization/encoding format for key material
Precedence: list

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.