Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd25D-00006y-HP for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:39:47 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.42 as permitted sender) client-ip=209.85.216.42; envelope-from=tier.nolan@gmail.com; helo=mail-qa0-f42.google.com; Received: from mail-qa0-f42.google.com ([209.85.216.42]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd25C-0007sD-BB for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:39:47 +0000 Received: by mail-qa0-f42.google.com with SMTP id k15so1254643qaq.15 for ; Wed, 23 Apr 2014 11:39:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.163.73 with SMTP id z9mr23730174qax.90.1398278380857; Wed, 23 Apr 2014 11:39:40 -0700 (PDT) Received: by 10.140.25.86 with HTTP; Wed, 23 Apr 2014 11:39:40 -0700 (PDT) In-Reply-To: References: <53344FF8.7030204@gk2.sk> Date: Wed, 23 Apr 2014 19:39:40 +0100 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0158b030302fa904f7ba0e7b 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 (tier.nolan[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: 1Wd25C-0007sD-BB 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: Wed, 23 Apr 2014 18:39:47 -0000 --089e0158b030302fa904f7ba0e7b Content-Type: text/plain; charset=UTF-8 Different users could have different gap limit requirements. 20 seems very low as the default. A merchant could easily send 20 addresses in a row to customers and none of them bother to actually buy anything. Setting the gap limit to high is just a small extra cost in that case. Bip-32 serialization doesn't have a way of adding meta data though. On Wed, Apr 23, 2014 at 7:18 PM, slush wrote: > For those who don't follow github pull requests regularly; there's pull > request for BIP64 defining HD wallet structure as discussed in this thread: > > https://github.com/bitcoin/bips/pull/52 > > > > On Wed, Apr 23, 2014 at 8:01 PM, slush wrote: > >> >> >> >> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille wrote: >>> >>> Storing the seed is superior to storing the master node already >>> (whether coin specific or not), as it is smaller. >>> >>> >> ...Except that you're loosing flexibility (serialization, >> deserialization) which gives you BIP32 node. >> >> I see "bip32 seed" as some transitional, internal state from raw entropy >> to bip32 master node and this seed should not be handled by the end user in >> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in >> mnemonic format) can be used very widely and have no downsides against >> using raw "bip32 seed". >> >> >>> >>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a >>> *Bitcoin* improvement proposal, and not something that necessarily >>> applies to other coins (they can adopt it of course, I don't care). >>> >>> >> I also don't care too much about altcoins, but people want them so me, as >> infrastructure developer, need to think about it. And I don't see any >> reason for breaking compatibility between Bitcoin and other altcoins. I >> would be happier if there will be another sentence than "Bitcoin seed", but >> honestly, who cares. It is just some magic string for hashing the raw >> seed... >> >> >>> What I dislike is that this removes the ability of using the magic in >>> the serialization to prevent importing a chain from the wrong coin. >>> >> >> The truth is that even existing software which handle bip32 don't care >> about 'version' at all. I think that "xpub/xprv" distinction is the only >> useful feature of version, so user se if it stores public or private >> information. >> >> But using prefixes which doesn't enforce anything is even more dangerous. >> If somebody exports node "dogeblablabla", it creates false exceptations >> that there's only dogecoin stored. >> >> Marek >> > > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e0158b030302fa904f7ba0e7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Different users could have different gap limit requir= ements.=C2=A0 20 seems very low as the default.

A merchant could eas= ily send 20 addresses in a row to customers and none of them bother to actu= ally buy anything.

Setting the gap limit to high is just a small extra cost in = that case.

Bip-32 serialization doesn't have a = way of adding meta data though.


On Wed, Apr 23, 2014 at 7:18 PM, slush <slush@centrum.cz> wro= te:
For those who don't follow github pull requests regula= rly; there's pull request for BIP64 defining HD wallet structure as dis= cussed in this thread:




On Wed, Apr 23, 2014 = at 8:01 PM, slush <slush@centrum.cz> wrote:



On Wed, Apr 23, 2014 at 7:42 PM= , Pieter Wuille <pieter.wuille@gmail.com> wrote: Storing the seed is superior to storing the master node already
(whether coin specific or not), as it is smaller.


...Except that you're loosin= g flexibility (serialization, deserialization) which gives you BIP32 node.<= /div>

I see "bip32 seed" as some transitional,= internal state from raw entropy to bip32 master node and this seed should = not be handled by the end user in any form. In the oposite, well-serialized= bip32 node (in xpriv, or even in mnemonic format) can be used very widely = and have no downsides against using raw "bip32 seed".
=C2=A0

Fair enough, it would break strictly BIP32. Then again, BIP32 is a *Bitcoin* improvement proposal, and not something that necessarily
applies to other coins (they can adopt it of course, I don't care).


I also don't care too much a= bout altcoins, but people want them so me, as infrastructure developer, nee= d to think about it. And I don't see any reason for breaking compatibil= ity between Bitcoin and other altcoins. I would be happier if there will be= another sentence than "Bitcoin seed", but honestly, who cares. I= t is just some magic string for hashing the raw seed...
=C2=A0
What I dislike is that this removes the ability of using the magic in
the serialization to prevent importing a chain from the wrong coin.

The truth is that even existing software= which handle bip32 don't care about 'version' at all. I think = that "xpub/xprv" distinction is the only useful feature of versio= n, so user se if it stores public or private information.

But using prefixes which doesn't enforce anything i= s even more dangerous. If somebody exports node "dogeblablabla", = it creates false exceptations that there's only dogecoin stored.

=C2=A0Marek


-----------------------------------------------------------= -------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.n= et/sfu/ExoPlatform
_______________________________________________ Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e0158b030302fa904f7ba0e7b--