public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jeremy Spilman" <jeremy@taplink.co>
To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
Date: Thu, 20 Jun 2013 02:10:26 -0700	[thread overview]
Message-ID: <66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR> (raw)
In-Reply-To: <20130620074830.GA21724@crunch>

> 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






  reply	other threads:[~2013-06-20  9:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-18  3:48 [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol 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 [this message]
2013-06-20 16:09           ` Alan Reiner
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=66577F722D29461D8651DF1D0684AAE1@LAPTOPAIR \
    --to=jeremy@taplink.co \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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