Allen Piscitello [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-27 📝 Original message:The benefit I see is ...
📅 Original date posted:2014-03-27
📝 Original message:The benefit I see is avoiding reuse of keys between coins while not having
each wallet implementation have to know about each coin in order to scan
for transactions. Wallet X supports Doge and Bitcoin. If both used a
shared sequence of keys, say the first two end up Bitcoin, then 10 Doge,
then some more Bitcoin. If you took this seed to Wallet Y, which only
supports Bitcoin (either the wallet's support or what is installed on the
system it's being used), it will see a gap of 10 addresses, and presume no
more scanning with a 5 gap limit. The alternative is to reuse keys for
each coin.
It also seems like a solution might be to only expect interoperability on a
single sequence, and provide backups of each final sequence to use between
different wallet implementations. This allows flexibility in hierarchies
depending on needs and support of wallet, but allows sharing. The short
seed would only be useful for the same wallet, but sharing between wallets
would use the longer keys. That will give predictable behavior for users
(although less friendly) and lead to less errors.
-Allen
On Thu, Mar 27, 2014 at 11:28 AM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> > Cointype in path is for separation purposes, not for identification.
>
> I don't understand what that gains you.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/0e05360a/attachment.html>;
📝 Original message:The benefit I see is avoiding reuse of keys between coins while not having
each wallet implementation have to know about each coin in order to scan
for transactions. Wallet X supports Doge and Bitcoin. If both used a
shared sequence of keys, say the first two end up Bitcoin, then 10 Doge,
then some more Bitcoin. If you took this seed to Wallet Y, which only
supports Bitcoin (either the wallet's support or what is installed on the
system it's being used), it will see a gap of 10 addresses, and presume no
more scanning with a 5 gap limit. The alternative is to reuse keys for
each coin.
It also seems like a solution might be to only expect interoperability on a
single sequence, and provide backups of each final sequence to use between
different wallet implementations. This allows flexibility in hierarchies
depending on needs and support of wallet, but allows sharing. The short
seed would only be useful for the same wallet, but sharing between wallets
would use the longer keys. That will give predictable behavior for users
(although less friendly) and lead to less errors.
-Allen
On Thu, Mar 27, 2014 at 11:28 AM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> > Cointype in path is for separation purposes, not for identification.
>
> I don't understand what that gains you.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/0e05360a/attachment.html>;