From: Alan Reiner <etotheipi@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
Date: Thu, 20 Jun 2013 12:09:10 -0400 [thread overview]
Message-ID: <51C32926.10904@gmail.com> (raw)
In-Reply-To: <66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR>
[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3376 bytes --]
next prev parent reply other threads:[~2013-06-20 16:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 3:48 Alan Reiner
2013-06-19 12:19 ` Melvin Carvalho
2013-06-19 13:37 ` Alan Reiner
2013-06-19 13:54 ` Pieter Wuille
2013-06-19 14:25 ` Timo Hanke
2013-06-19 14:39 ` Alan Reiner
2013-06-19 15:28 ` Adam Back
2013-06-19 18:36 ` Adam Back
2013-06-19 19:00 ` Alan Reiner
2013-06-20 7:48 ` Timo Hanke
2013-06-20 9:10 ` Jeremy Spilman
2013-06-20 16:09 ` Alan Reiner [this message]
2013-06-19 20:03 ` Timo Hanke
2013-06-19 19:29 Jeremy Spilman
2013-06-19 20:10 ` Alan Reiner
2013-06-19 21:58 ` Jeremy Spilman
2013-06-19 22:47 ` Alan Reiner
2013-06-20 3:54 ` Jeremy Spilman
2013-06-20 7:32 ` Mike Hearn
2013-06-26 15:29 ` Alan Reiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C32926.10904@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox