Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXVNn-0006CK-TR for bitcoin-development@lists.sourceforge.net; Tue, 08 Apr 2014 12:44:07 +0000 X-ACL-Warn: Received: from mail-ve0-f174.google.com ([209.85.128.174]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WXVNm-00033A-Kt for bitcoin-development@lists.sourceforge.net; Tue, 08 Apr 2014 12:44:07 +0000 Received: by mail-ve0-f174.google.com with SMTP id oz11so683747veb.5 for ; Tue, 08 Apr 2014 05:44:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:cc:content-type; bh=z2JG9eC7W6yoWuo91/Q0ivRGiZ4PR6uMEMLRX8oQCx0=; b=ReD8Pm0hEFuXcI1Y+usTHJumSFO8SL404jsNcLNroqdBsoCl3oSaJPxIfXLMPoO2js AeLLdKv+Bhb+jvYmuPIzmyjL43GKHjDzj+j7LNu1E0At66B9aj801yRrhLAAx9VQQzAk kTaK4+zYGzV1/mF2jizqpU5n+uarIo8eoaEW8UiFFbSbYub6tw5f1X6VS9Off2HSeBUy hJNWZcAqv8adJZU5bgnaP6hAcYc5QxVhUkqDknPTgSa9fcKTwdpYDXahZXX4nUUkf5Ys NUeIFRU1K730WGrVH81ekKIGGjtITXyvdDmNQxUMU38bCDR35ijIGm3jw53yMumHaNbt 5HAA== X-Gm-Message-State: ALoCoQk6n2/shp3WbaE4MZ84Mfw3yvS+H9S1xY6ItcCgaUc8zFSvgQn+GSEA5oaMFOoT8yZdasBh X-Received: by 10.52.119.197 with SMTP id kw5mr2576005vdb.5.1396961040929; Tue, 08 Apr 2014 05:44:00 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.58.234.100 with HTTP; Tue, 8 Apr 2014 05:43:30 -0700 (PDT) In-Reply-To: References: <53344FF8.7030204@gk2.sk> From: slush Date: Tue, 8 Apr 2014 14:43:30 +0200 X-Google-Sender-Auth: RaRKMznteZOqVZjphwUwmlLy4Ps Message-ID: Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e013a0f8a9c286704f687564a X-Spam-Score: 2.2 (++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WXVNm-00033A-Kt 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: Tue, 08 Apr 2014 12:44:08 -0000 --089e013a0f8a9c286704f687564a Content-Type: text/plain; charset=ISO-8859-1 After some off-list discussion about details with wallet developers, it seems that structure m/'/'// fulfill requirements of all wallet developers around, including myTrezor, Electrum, Multibit, Wallet32 and other software is willing to adapt once anything will be standardized (i.e. they don't care). Because I think that everybody told their comments to the topic already and because it seems that there's quite wide agreement on that, I would like to close the discussion and finally implement these paths into our software. Cheers, Marek On Fri, Mar 28, 2014 at 3:59 PM, slush wrote: > I agree that 'version' field of bip32 is not necessary and xpriv/xpub > should be enough for all cases; there's actually no need to use different > BIP32 roots for different altcoins. > > I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by > having the "cointype" distinction in the bip32 path itself, I'm sure that I > don't reuse the same pubkey across blockchains which may be a privacy issue > otherwise. > > Marek > > > On Thu, Mar 27, 2014 at 5:28 PM, 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 >> > > --089e013a0f8a9c286704f687564a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
After some off-list discussion about details with wallet d= evelopers, it seems that structure

m/<cointype>= 9;/<account>'/<change>/<n>=A0

fulfill requirements of all wallet developers around, including myTrezor, E= lectrum, Multibit, Wallet32 and other software is willing to adapt once any= thing will be standardized (i.e. they don't care).

Because I think that everybody told their comments to the topic alread= y and because it seems that there's quite wide agreement on that, I wou= ld like to close the discussion and finally implement these paths into our = software.

Cheers,
Marek


On Fri, Mar 28, 2014 at 3:59 PM, = slush <slush@centrum.cz> wrote:
I agree that 'version&#= 39; field of bip32 is not necessary and xpriv/xpub should be enough for all= cases; there's actually no need to use different BIP32 roots for diffe= rent altcoins.

I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by= having the "cointype" distinction in the bip32 path itself, I= 9;m sure that I don't reuse the same pubkey across blockchains which ma= y be a privacy issue otherwise.

Marek


On Thu, Mar= 27, 2014 at 5:28 PM, Pieter Wuille <pieter.wuille@gmail.com>= wrote:
I don't understand what that gains you.

--
Pieter


--089e013a0f8a9c286704f687564a--