Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd3Sz-0002A4-5O for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:08:25 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.180 as permitted sender) client-ip=209.85.213.180; envelope-from=pieter.wuille@gmail.com; helo=mail-ig0-f180.google.com; Received: from mail-ig0-f180.google.com ([209.85.213.180]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd3Sy-0007s4-81 for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:08:25 +0000 Received: by mail-ig0-f180.google.com with SMTP id c1so32219igq.13 for ; Wed, 23 Apr 2014 13:08:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.66.227 with SMTP id i3mr5083702igt.19.1398283698790; Wed, 23 Apr 2014 13:08:18 -0700 (PDT) Received: by 10.50.127.243 with HTTP; Wed, 23 Apr 2014 13:08:18 -0700 (PDT) Received: by 10.50.127.243 with HTTP; Wed, 23 Apr 2014 13:08:18 -0700 (PDT) In-Reply-To: <201404232001.06679.luke@dashjr.org> References: <201404231955.09287.luke@dashjr.org> <201404232001.06679.luke@dashjr.org> Date: Wed, 23 Apr 2014 22:08:18 +0200 Message-ID: From: Pieter Wuille To: Luke Dash-Jr Content-Type: multipart/alternative; boundary=047d7bdc157a29688e04f7bb4b4e 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 (pieter.wuille[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: 1Wd3Sy-0007s4-81 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: Wed, 23 Apr 2014 20:08:25 -0000 --047d7bdc157a29688e04f7bb4b4e Content-Type: text/plain; charset=ISO-8859-1 That's the point. BIP64 specifies such a structure, and you have to scan all that it defines. If you want to write wallet software that does not have the complexity to deal with just one account, it is not BIP64 compliant. It could try to define its own purpose system, with a hierarchy without accounts in it. I'm not sure this is a very interesting use case, but I like how strict it is. Construction of related chains for multisig addresses is perhaps a better example of a different purpose structure. On 23 Apr 2014 22:03, "Luke-Jr" wrote: > On Wednesday, April 23, 2014 7:57:46 PM slush wrote: > > On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr wrote: > > > Any wallet should import all the coins just fine, it just wouldn't > *use* > > > any > > > account other than 0. Remember addresses are used to receive bitcoins; > > > once the UTXOs are in the wallet, they are no longer associated with > the > > > address or > > > any other details of how they were received. > > > > Wallet don't see UTXO until it scans all branches/accounts on HD node > > import. > > Yes, it should scan all possible (under the BIP-defined structure) branches > regardless of which features it supports. > > Luke > > > ------------------------------------------------------------------------------ > 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 > --047d7bdc157a29688e04f7bb4b4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

That's the point. BIP64 specifies such a structure, and = you have to scan all that it defines.

If you want to write wallet software that does not have the = complexity to deal with just one account, it is not BIP64 compliant. It cou= ld try to define its own purpose system, with a hierarchy without accounts = in it. I'm not sure this is a very interesting use case, but I like how= strict it is. Construction of related chains for multisig addresses is per= haps a better example of a different purpose structure.

On 23 Apr 2014 22:03, "Luke-Jr" <luke@dashjr.org> wrote:
On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
> On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr <luke@dashjr.org> wrote:
> > Any wallet should import all the coins just fine, it just wouldn&= #39;t *use*
> > any
> > account other than 0. Remember addresses are used to receive bitc= oins;
> > once the UTXOs are in the wallet, they are no longer associated w= ith the
> > address or
> > any other details of how they were received.
>
> Wallet don't see UTXO until it scans all branches/accounts on HD n= ode
> import.

Yes, it should scan all possible (under the BIP-defined structure) branches=
regardless of which features it supports.

Luke

---------------------------------------------------------------------------= ---
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
--047d7bdc157a29688e04f7bb4b4e--