public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Timo Hanke <timo.hanke@web•de>
To: Alan Reiner <etotheipi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
Date: Wed, 19 Jun 2013 22:03:07 +0200	[thread overview]
Message-ID: <20130619200307.GB20405@crunch> (raw)
In-Reply-To: <51C1C288.4000305@gmail.com>

On Wed, Jun 19, 2013 at 10:39:04AM -0400, Alan Reiner wrote:
> On 06/19/2013 10:25 AM, Timo Hanke wrote:
> > Since you mention to use this in conjunction with the payment protocol,
> > note the following subtlety. Suppose the payer has to paid this address
> > called "destination": 
> >>    Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
> >> checksum)
> > Also suppose the payee has spent the output, i.e. the pubkey
> > corresponding to "destination", which is PubKeyParent * Multiplier[i],
> > is publicly known. Then anybody can (in retrospect) create arbitrary
> > many pairs {PublicKeyParent, Multiplier} (in particular different
> > PublicKeyParent) that lead to the same "destination".
> >
> > Depending on what you have in mind that the transaction should "prove"
> > regarding its actual receiver or regarding the receiver's PubKeyParent,
> > this could be an unwanted feature (or it could be just fine). If it is
> > unwanted then I suggest replacing
> > PubKeyParent * Multiplier[i] by 
> > PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
> > which eliminates from the destination all ambiguity about PubKeyParent.
> >
> > This modification would not be directly compatible with BIP32 anymore
> > (unfortunately), but seems to be better suited for use in conjunction
> > with a payment protocol. 
> >
> > Timo
> 
> It's an interesting observation, but it looks like the most-obvious
> attack vector is discrete log problem:  spoofing a relationship between
> a target public key and one that you control.   For instance, if you see
> {PubA, Mult} produces PubB and you have PubC already in your control
> that you want to "prove" [maliciously] is related to PubB, then you have
> to find the multiplier, M that solves:  M*PubC = PubB.  That's a
> discrete logarithm problem.

Correct, for a given PubC in advance you can't create such a "malicious"
relation to PubB. You can only "reversely" construct new PubC from given
PubB.

> I'm not as familiar as you are, with the available operations on
> elliptic curves, but it sounds like you can produce essentially-random
> pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
> the private key associated with those public keys.  

Depends on who is "you". The arbitrary person who produces {PubX, Mult}
won't have the private key, but the person who knows the private key for
PubA will have it (assuming that PubB was computed from {PubA, Mult} in
the first place).

In the end, it all depends on your application. What proves enough for
one party doing repeated transactions with another may not suffice for a
third party doing auditing. On the other hand, ambiguity about PubA may
just as well be a wanted feature for deniability reasons.

Timo

-- 
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8



  parent reply	other threads:[~2013-06-19 20:03 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
2013-06-19 20:03     ` Timo Hanke [this message]
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=20130619200307.GB20405@crunch \
    --to=timo.hanke@web$(echo .)de \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=etotheipi@gmail$(echo .)com \
    /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