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)
- 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
In fact, same could be argued to add birthday to WIF private key format to
let wallet discover funds faster.
Is it possible to have a serialization so that in the encoding, the key
part is still visually the same ?
On Tue, May 29, 2018 at 5:30 PM, <
bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>1. New serialization/encoding format for key material
> (Jonas Schnelli)
>
>
> --
>
> Message: 1
> Date: Tue, 29 May 2018 11:13:37 +0200
> From: Jonas Schnelli
> To: Bitcoin Protocol Discussion
>
> Subject: [bitcoin-dev] New serialization/encoding format for key
> material
> Message-ID: <03557e21-8cfc-4822-8494-f4a78e238...@jonasschnelli.ch>
> Content-Type: text/plain; charset="utf-8"
>
> Hi
>
> Extended public and private keys are defined in BIP32 [1].
>
> Encoded extended private keys should not be confused with a wallet ?seed?
> (proposals like BIP39) while they can also partially serve the purpose to
> ?seed? a wallet (there may be an overlap in the use-case).
>
> Recovering a wallet by its extended private master key (xpriv; may or may
> not
> be at depth 0) is a complex task with risks of failing to recover all
> available
> funds.
>
> It may be reasonable to consider that recovering a wallet purely based on
> the
> existence of an extended private master key is a forensic funds recovery
> process and should probably be the last resort in case of a backup-recovery
> situation. A simple example here is, that it was/is possible to have used
> an
> xpriv (referring to extended private master key) in production that is/was
> used
> to derive BIP45 based P2SH multisig addresses (1of1, used by Bitpays BWS
> for
> while), later used for bare BIP45ish multisig 1of1 as well as for P2PKH
> after
> BIP44 & vanilla BIP32 P2WPKH (m/0?/k?).
> I?m not aware of any wallet that would recover 100% of those funds,
> leading to
> the risk that forwarding the unspents and destroying the extended master
> key
> may result in coins forever lost.
>
> The case above may be an edge case, but I?m generally under the assumption
> that
> recovering funds based on the sole existence of an xpriv (or seed) without
> further
> metadata is a fragile concept.
>
> Second, the missing birthday-metadata tend to lead to non-optimal
> blockchain
> scans (eventually increased p2p traffic). Recovering funds can take hours.
>
> Additionally, the BIP44 gap limit seems to be a weak construct. The
> current gap
> limit in BIP44 is set to 20 [2] which basically means, handing out more
> then 20
> incoming payment requests (addresses) results in taking the risks that
> funds
> may be destroyed (or at least not detected) during a recovery.
> The Gap limit value may also depend on the use case, but the current
> proposals
> do not allow to set an arbitrary value. High load merchants very likely
> need a
> different gap limit value then individuals create a transaction once a
> year.
>
> During creation time of an xpriv/xpub, it is impossible to know if the
> created
> xpriv will be used for an unforeseen derivation scheme. Future proposals
> may
> want to limit an extended key to a single derivation scheme.
>
>
> This is an early draft in order to allow discussion that may lead to a
> possible
> proposal.
> This proposals could also make BIP 178 obsolete since it can be replace the
> WIF[3] standard.
>
>
> Thanks for feedback
> /jonas
>
>
>
>
>
> Titel
> ##
> Bech32 encoded key material including metadata
>
> Abstract
>
> An error tolerant encoding format for key material up to 520bits with a
> minimal
> amount of metadata.
>
> Motivation
> ##
> (See above; intro text)
>
>
> Specification
> #
>
> ## Serialization format
>
> 1 bit version bit
> 15 bits (bit 1 to 16) key-birthday (0-32767)
> (12 bit gap limit)
> 3 or 5 bits script type
> 256 or 512 or
