Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTER5-0003iB-TR for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 17:49:51 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.52 as permitted sender) client-ip=209.85.213.52; envelope-from=allen.piscitello@gmail.com; helo=mail-yh0-f52.google.com; Received: from mail-yh0-f52.google.com ([209.85.213.52]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTER4-0005f2-Gf for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 17:49:51 +0000 Received: by mail-yh0-f52.google.com with SMTP id c41so3928418yho.39 for ; Thu, 27 Mar 2014 10:49:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.131.19 with SMTP id l19mr4429736yhi.0.1395942585013; Thu, 27 Mar 2014 10:49:45 -0700 (PDT) Received: by 10.170.88.10 with HTTP; Thu, 27 Mar 2014 10:49:44 -0700 (PDT) In-Reply-To: References: <53344FF8.7030204@gk2.sk> Date: Thu, 27 Mar 2014 12:49:44 -0500 Message-ID: From: Allen Piscitello To: Pieter Wuille Content-Type: multipart/alternative; boundary=20cf3010e96de81a3b04f59a3536 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (allen.piscitello[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WTER4-0005f2-Gf Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] New BIP32 structure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 17:49:52 -0000 --20cf3010e96de81a3b04f59a3536 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --20cf3010e96de81a3b04f59a3536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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. =A0Wallet X supports Doge and Bitcoin. =A0= If both used a shared sequence of keys, say the first two end up Bitcoin, t= hen 10 Doge, then some more Bitcoin. =A0If you took this seed to Wallet Y, = which only supports Bitcoin (either the wallet's support or what is ins= talled on the system it's being used), it will see a gap of 10 addresse= s, and presume no more scanning with a 5 gap limit. =A0The alternative is t= o reuse keys for each coin.

It also seems like a solution might be to only expect intero= perability on a single sequence, and provide backups of each final sequence= to use between different wallet implementations. =A0This allows flexibilit= y in hierarchies depending on needs and support of wallet, but allows shari= ng. =A0The short seed would only be useful for the same wallet, but sharing= between wallets would use the longer keys. =A0That will give predictable b= ehavior for users (although less friendly) and lead to less errors.

-Allen


On Thu, Mar 27, 2014 at 11:28 AM,= Pieter Wuille <pieter.wuille@gmail.com> wrote:
On Thu, Mar 27, 2014 at 5:21= PM, Pavol Rusnak <stick@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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--20cf3010e96de81a3b04f59a3536--