From: Jonas Schnelli <dev@jonasschnelli•ch>
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 21:03:46 +0200 [thread overview]
Message-ID: <FE65454B-B30A-4CEF-B568-B2746BD2BC0B@jonasschnelli.ch> (raw)
In-Reply-To: <CABuOfuhMGFGc1tyjcOmnUk1OrWp2d6ppKc8phLT9pXCj8vs+qg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
Hi
> - 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
What would be the downside of encoding the same key with different metadata (resulting in different "visual strings“)?
If you import it into the same software, it would be trivial to detect it. If you import it into another software, it probably doesn’t matter.
Visual comparing is eventually a broken concept (agree with Greg) and I doubt that this property is important, and IMHO basic metadata seems more important then this - very likely irrelevant - visual property.
Also, I think a recovery based on a sole xpriv (or + limited amount of meta-data as described in this proposal) is a disaster recovery (or forensic recovery).
Long term, I would wish, if wallet-metadata including transaction based user metadata would be backed up - after encrypted with a key that can be derived from the seed - in a way, where you need the seed to recover that backup thus it can be stored in cheap, insecure spaces.
>
> In fact, same could be argued to add birthday to WIF private key format to let wallet discover funds faster.
>
The proposal I made can be seen as a replacement for WIF (it can replace WIF and xpriv/xpub) since it can encode a single private key into 275bits (still pretty short Bech32 string).
/jonas
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-05-30 19:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 6:30 shiva sitamraju
2018-05-30 14:08 ` Gregory Maxwell
2018-05-30 19:03 ` Jonas Schnelli [this message]
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=FE65454B-B30A-4CEF-B568-B2746BD2BC0B@jonasschnelli.ch \
--to=dev@jonasschnelli$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=shiva@blockonomics$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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