diff options
| author | Alan Reiner <etotheipi@gmail.com> | 2013-06-20 12:09:10 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-20 16:09:23 +0000 |
| commit | 723fee909b313fb2e74eac4036b2123a4a98b820 (patch) | |
| tree | cdae0869096b66a4cc46823b673256571d9dcc99 | |
| parent | 2abec48be85aff4c15869f3c9d3af7f9edcc80f4 (diff) | |
| download | pi-bitcoindev-723fee909b313fb2e74eac4036b2123a4a98b820.tar.gz pi-bitcoindev-723fee909b313fb2e74eac4036b2123a4a98b820.zip | |
Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
| -rw-r--r-- | 8f/a2a9344335c807079d8b3971221fea1b3043b5 | 215 |
1 files changed, 215 insertions, 0 deletions
diff --git a/8f/a2a9344335c807079d8b3971221fea1b3043b5 b/8f/a2a9344335c807079d8b3971221fea1b3043b5 new file mode 100644 index 000000000..664840bf7 --- /dev/null +++ b/8f/a2a9344335c807079d8b3971221fea1b3043b5 @@ -0,0 +1,215 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <etotheipi@gmail.com>) id 1UphQI-00008m-V1 + for bitcoin-development@lists.sourceforge.net; + Thu, 20 Jun 2013 16:09:23 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.216.41 as permitted sender) + client-ip=209.85.216.41; envelope-from=etotheipi@gmail.com; + helo=mail-qa0-f41.google.com; +Received: from mail-qa0-f41.google.com ([209.85.216.41]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1UphQD-0006a5-3N + for bitcoin-development@lists.sourceforge.net; + Thu, 20 Jun 2013 16:09:22 +0000 +Received: by mail-qa0-f41.google.com with SMTP id f14so1222932qak.14 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 20 Jun 2013 09:09:11 -0700 (PDT) +X-Received: by 10.49.71.70 with SMTP id s6mr1124799qeu.66.1371744551577; + Thu, 20 Jun 2013 09:09:11 -0700 (PDT) +Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. + [76.111.96.126]) + by mx.google.com with ESMTPSA id j5sm1560691qan.7.2013.06.20.09.09.10 + for <bitcoin-development@lists.sourceforge.net> + (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); + Thu, 20 Jun 2013 09:09:10 -0700 (PDT) +Message-ID: <51C32926.10904@gmail.com> +Date: Thu, 20 Jun 2013 12:09:10 -0400 +From: Alan Reiner <etotheipi@gmail.com> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:17.0) Gecko/20130510 Thunderbird/17.0.6 +MIME-Version: 1.0 +To: bitcoin-development@lists.sourceforge.net +References: <51BFD886.8000701@gmail.com> <20130619142510.GA17239@crunch> + <51C1C288.4000305@gmail.com> + <20130619152815.GA14729@netbook.cypherspace.org> + <20130620074830.GA21724@crunch> + <66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR> +In-Reply-To: <66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR> +X-Enigmail-Version: 1.5.1 +Content-Type: multipart/alternative; + boundary="------------060104010105000204080005" +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 + (etotheipi[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: 1UphQD-0006a5-3N +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 20 Jun 2013 16:09:23 -0000 + +This is a multi-part message in MIME format. +--------------060104010105000204080005 +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: 7bit + + +On 06/20/2013 05:10 AM, Jeremy Spilman wrote: +>> 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... +> +> + +I agree, if we used Timo's suggestion, that seems to clean up the +remaining uncertainties with this recommendation. I'm not convinced +those uncertainties matter in this situation, where there is no question +about the parent public key. That is the part of the process that was +already verified, per my previous examples. But certainly, for this to +be more versatile it would need that. + +If I modify my request to match Timo's recommendation, then it loses the +benefit of being a simple, non-disruptive extension of BIP 32. I'm not +fond of deviating from BIP 32, as it kind of defeats one of the benefits +of BIP 32: standardization. And I'm not inclined to make an +Armory-specific wallet variant. + +But I can't tell if the benefits are lost on you, or you just don't +think they are worth it (or I'm overstating them). I'm strongly opposed +to bring extra wallets/chains into this equation /*just*/ to get a +benefit that can be had with a simple alternative encoding. This isn't +a question of which is better, it's a matter of recognizing that both +forms have usefulness and should both be supported. + +-Alan + +--------------060104010105000204080005 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: 7bit + +<html> + <head> + <meta content="text/html; charset=ISO-8859-1" + http-equiv="Content-Type"> + </head> + <body text="#000000" bgcolor="#FFFFFF"> + <br> + <div class="moz-cite-prefix">On 06/20/2013 05:10 AM, Jeremy Spilman + wrote:<br> + </div> + <blockquote cite="mid:66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR" + type="cite"> + <blockquote type="cite"> + <pre wrap="">which could involve proving something to a third party that has not seen +the communication between payer and payee. +</pre> + </blockquote> + <pre wrap=""> +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... + + +</pre> + </blockquote> + <br> + I agree, if we used Timo's suggestion, that seems to clean up the + remaining uncertainties with this recommendation. I'm not + convinced those uncertainties matter in this situation, where there + is no question about the parent public key. That is the part of the + process that was already verified, per my previous examples. But + certainly, for this to be more versatile it would need that. <br> + <br> + If I modify my request to match Timo's recommendation, then it loses + the benefit of being a simple, non-disruptive extension of BIP 32. + I'm not fond of deviating from BIP 32, as it kind of defeats one of + the benefits of BIP 32: standardization. And I'm not inclined to + make an Armory-specific wallet variant.<br> + <br> + But I can't tell if the benefits are lost on you, or you just don't + think they are worth it (or I'm overstating them). I'm strongly + opposed to bring extra wallets/chains into this equation <i>*just*</i> + to get a benefit that can be had with a simple alternative + encoding. This isn't a question of which is better, it's a matter + of recognizing that both forms have usefulness and should both be + supported. <br> + <br> + -Alan<br> + </body> +</html> + +--------------060104010105000204080005-- + + |