From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Upasx-0002TV-R2 for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 09:10:31 +0000 Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1Upasv-0005Ol-TA for bitcoin-development@lists.sourceforge.net; Thu, 20 Jun 2013 09:10:31 +0000 Received: from LAPTOPAIR ([192.168.168.158]) by mail.taplink.co ; Thu, 20 Jun 2013 02:10:54 -0700 Message-ID: <66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR> From: "Jeremy Spilman" To: "Bitcoin Dev" References: <51BFD886.8000701@gmail.com> <20130619142510.GA17239@crunch> <51C1C288.4000305@gmail.com> <20130619152815.GA14729@netbook.cypherspace.org> <20130620074830.GA21724@crunch> In-Reply-To: <20130620074830.GA21724@crunch> Date: Thu, 20 Jun 2013 02:10:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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: 1Upasv-0005Ol-TA 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: Thu, 20 Jun 2013 09:10:32 -0000 > which could involve proving something to a third party that has not seen > the communication between payer and payee. OK - I think I follow now. So a third-party who does not see any of the communication between the payer and payee only knows the HASH160. Let's say the payee denies receipt of the funds.... It's easy to prove what public key it was sent to (it's the preimage), but you can't prove the parent of that public key. You can provide any number of ParentPubKey * Multiplier that could have been used, so the 3rd party is unconvinced by a "matching" ParentPubKey * Multiplier. However, if you calculated the destination using: PubKeyParent * HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a PubKeyParent and Multiplier (or Addend) that produces the destination address, you've proven the payment is in fact spendable by PubKeyParent, and they can't deny receipt. Very cool. Sorry for "echoing" this back, it took me a little while to work it out, so I thought I'd write it down. Hope I got it right... If you give {PubKey, ChainCode} you do get this feature. If you give {ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to having plausible deniability. If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you could give HMAC(cpar, i) instead of Addend, and then you would get this feature; a way to 'skip down' a level in the wallet hierarchy, keep the 'chain of custody' so to speak back to the ParentPubKey intact, without having to disclose the ChainCode. Meh... Thanks, --Jeremy