Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd2r4-0007ur-CR for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:29:14 +0000 X-ACL-Warn: Received: from mail-ee0-f44.google.com ([74.125.83.44]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd2r3-0001pZ-4t for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:29:14 +0000 Received: by mail-ee0-f44.google.com with SMTP id e49so1112898eek.31 for ; Wed, 23 Apr 2014 12:29:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ju8A6D08Ga7by7AvZq5r312Pgj/9tPow8RfMoo5PZhI=; b=LHlUkDl5GJUQuP/ioiAJoM9l1AjdqYgGqLd0rCIlcr+NqEBaHfldFEdt2PjNACLljT S14cGIgLfKWHynhUdtNY/f62pMzuKKD1g+x9bXwyzbj0jNFOagoaJHfq6ECWo3VeAQwG qPx9siPCswr4i7qqFRw1w4efVmBzbRQv8udOfaXsjLUA4rZ635ahCOvw3TbTFfESrsna RUCJG3olXdERq9ZESiTVUnwoLgZQg2vNfmHZiEJkfu24ECrOe6+7g5sSVPbYuj18ves6 f1FKSJ2jTwQHF4OkFAXmB7XovnepRI8h1yQ69lJIVisAoNXhjiCYOraLEghaPvlVgUAO 1Ifw== X-Gm-Message-State: ALoCoQm20pmexXdjhHbOrzFkysS2CGGI1X+mCCUnPvn3YEyt3npOe64FGUUBdVXF5NmrksCH2ddP X-Received: by 10.15.64.75 with SMTP id n51mr65730770eex.33.1398281346327; Wed, 23 Apr 2014 12:29:06 -0700 (PDT) Received: from tetra.site (nat-0-15.lam.cz. [80.92.242.254]) by mx.google.com with ESMTPSA id q41sm8927585eez.7.2014.04.23.12.29.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 12:29:05 -0700 (PDT) Message-ID: <53581480.5060103@gk2.sk> Date: Wed, 23 Apr 2014 21:29:04 +0200 From: Pavol Rusnak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bitcoin Dev References: <53580A73.9070208@gk2.sk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Wd2r3-0001pZ-4t 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 19:29:14 -0000 On 04/23/2014 09:00 PM, Tier Nolan wrote: > The point is to have a single system that is compatible over a large number > of systems. There is such system and it is called BIP32. On the other hand, in BIP64 we try to put a set of restrictions and rules on top of BIP32. There will always be some special usecases where BIP64 is not a good fit and there's no reason why you cannot use BIP32 in a different manner using a different "purpose" field. Examples: Electrum does not want to use accounts and they start to use scheme m/65'/change/address (where change = 0 or 1). Or Andreas Schildbach wants to have refunds chain so he uses m/66'/chain/address (where chain = 0, 1 or 2). We wanted to find one good solution that fits all, but unfortunately it turned out everyone wants something a little bit different. The point of the whole effort is that you can have ONE SINGLE BACKUP (master node) for all these independent purposes and suddenly claims such as "my wallet is BIP64 and BIP66 compatible" actually mean something as opposed to "BIP32 compatible" which actually means nothing except that the wallet author is capable of using HMAC in context of generating the tree. -- Best Regards / S pozdravom, Pavol Rusnak