From mboxrd@z Thu Jan 1 00:00:00 1970 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 1UpQOH-000251-9x for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 21:58:09 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co designates 50.117.27.232 as permitted sender) client-ip=50.117.27.232; envelope-from=jeremy@taplink.co; helo=mail.taplink.co; Received: from mail.taplink.co ([50.117.27.232]) by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1UpQOG-00021h-Ej for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 21:58:09 +0000 Received: from LAPTOPAIR ([192.168.168.158]) by mail.taplink.co ; Wed, 19 Jun 2013 14:58:33 -0700 Message-ID: <53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR> From: "Jeremy Spilman" To: "Bitcoin Dev" References: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR> <51C21035.9080407@gmail.com> In-Reply-To: <51C21035.9080407@gmail.com> Date: Wed, 19 Jun 2013 14:58:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 oclient: 192.168.168.158#jeremy@taplink.co#465 X-Spam-Score: -2.7 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.2 STOX_REPLY_TYPE STOX_REPLY_TYPE -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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: 1UpQOG-00021h-Ej Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol 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, 19 Jun 2013 21:58:09 -0000 Hi Alan, > “BIP 32 does not prescribe a way to use multiple chains like you described > with the convenient type-2 derivation (though we could create a variant > that does)” What do you think is missing from BIP32 for this? A wallet creates a child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, and then generally expects transactions to come in starting at /0 and incrementing monotonically. Also, I'm not sure I follow your point about the 128kB hardware wallet -- it's a signing device, so assuming it's even validating output amounts, at worst it cares about the number of inputs to the outputs being spent, but in many cases you're just handing it a sighash and the BIP32 "path" (/1/54/27/0) to generate the right private key for signing. The hardware wallet is not actually listening on the P2P network and detecting payments, so it's unaffected by dedicating child-nodes to each contact. Consider the benefits of gaining critical mass of support for a technique which [I think] can be used in all cases, and increases security and privacy for everyone. I think there are huge benefits to leaving the age of 'single address generation' behind us... Thanks, --Jeremy