Date: Sat, 8 Mar 2014 09:41:01 -0800
From: Adam Back <adam@cypherspace.org>
To: Joel Kaartinen <joel.kaartinen@gmail.com>
Message-ID: <20140308174101.GA21902@netbook.cypherspace.org>
References: <CA+su7OUMgeWgkMFAmmMEpW3eN=cvU47MKt51idDrmCWEiCb+VQ@mail.gmail.com>
	<531AD080.40501@gmail.com>
	<CA+su7OWx9jrgUJrOH=tg1968vr1G1w7yXjgaRSyYJ0zRBjwpqg@mail.gmail.com>
	<531AF2EA.50904@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <531AF2EA.50904@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Is this a safe thing to be doing with ECC
 addition? (Oracle protocol)
Precedence: list

Also the other limitation for ECDSA is that there is no known protocol to
create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without
either a sending its private key to b or viceversa (or both to a third
party).

With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a (secure)
direct multiparty signature quite difficult.

ps probably only 1 party needs to hash their key

P=aG      
            H(P) ->

		<- Q=bG

	   P ->

Adam

On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote:
>   If both parties insist on seeing a hash of the other party's public key
>   before they'll show their own public key, they can be sure that the
>   public key is not chosen based on the public key they themselves
>   presented.