To: Henning Kopp <henning.kopp@uni-ulm.de>
References: <20160209131215.GE2329@banane.informatik.uni-ulm.de>
	<56BA6455.9030803@gmail.com>
	<20160210115345.GD2336@banane.informatik.uni-ulm.de>
From: Jeremy Papp <pappjm@gmail.com>
Message-ID: <56BB67BD.1060901@gmail.com>
Date: Wed, 10 Feb 2016 10:39:25 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20160210115345.GD2336@banane.informatik.uni-ulm.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Question regarding Confidential Transactions
Precedence: list

On 2/10/2016 5:53 AM, Henning Kopp wrote:
> Hi Jeremy,
>
>> My understanding of the paper is that the blinding factor would be included
>> in the extra data which is incorporated into the ring signatures used in the
>> range proof.
> Yep, that is a possibility. The blinding factor could be encrypted
> with the public key of the receiver. Thus it is only visible for the
> receiver who can then check that the correct amount has been sent.
ECC doesn't work like RSA; you can't encrypt directly with a public 
key.  That's why you generate a shared secret between sender and 
receiver.  See also, ECDH. (Basically, if (m, M = m*G) is your 
private/public key pair, and (n, N = n*G) is your recipient's private 
public key pair, you can both generate shared secret S = m*N = n*M = 
m*n*G without revealing your private keys to each other, and without 
revealing the secret to anyone else as long as they don't know either 
private key. You then use S as the basis for the key to some symmetric 
algorithm.)
>> you'd transmit it then, though in any case, since using it will pretty much
>> require segwit, adding extraneous data isn't much of a problem.  In both
>> cases, I imagine the blinding factor would be protected from outside
>> examination via some form of shared secret generation... Although that would
>> require the sender to know the recipient's unhashed public key; I don't know
>> of any shared secret schemes that will work on hashed keys.
> Here you lost me.
> Why do we need to create a shared secret? Is this shared secret used
> as the blinding factor?
> Also I think the sender knows the unhashed public key of the receiver.
> The only reason not to include it in the transaction script is that an
> external observer is unable to see the receiver directly in the
> blockchain.
Normal Bitcoin transactions are made to the hash of a public key because 
once the public key is known, it becomes easier to break it if we ever 
develop quantum computers. That's why it's recommended that you only 
spend from a particular address once (if possible) since its only in 
spending that you are required to reveal your public key.   Since you 
can't do a shared secret with a public key hash, AFAIK, you'd have to 
know the public key of your recipient to be able to do ECDH.

Jeremy Papp