Jonas Schnelli [ARCHIVE] on Nostr: đź“… Original date posted:2018-05-30 đź“ť Original message:Hi > - Visually Comparing ...
đź“… Original date posted:2018-05-30
đź“ť Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180530/ff430ac7/attachment.sig>;
đź“ť Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180530/ff430ac7/attachment.sig>;