path: root/54/26615da6f59b27a966ba01c358567487993370

Return-Path: <henning.kopp@uni-ulm.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3A572CD5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 10 Feb 2016 11:53:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from smtp.uni-ulm.de (smtp.uni-ulm.de [134.60.1.26])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2CA4213B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 10 Feb 2016 11:53:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at uni-ulm.de
Received: from banane.informatik.uni-ulm.de (banane.informatik.uni-ulm.de
	[134.60.77.114]) (authenticated bits=0)
	by mail.uni-ulm.de (8.14.9/8.14.9) with ESMTP id u1ABroRO022322
	(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
	Wed, 10 Feb 2016 12:53:51 +0100 (CET)
Date: Wed, 10 Feb 2016 12:53:45 +0100
From: Henning Kopp <henning.kopp@uni-ulm.de>
To: Jeremy Papp <pappjm@gmail.com>
Message-ID: <20160210115345.GD2336@banane.informatik.uni-ulm.de>
References: <20160209131215.GE2329@banane.informatik.uni-ulm.de>
	<56BA6455.9030803@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56BA6455.9030803@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-DCC-EATSERVER-Metrics: poseidon 1166; Body=2 Fuz1=2 Fuz2=2
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, 
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 10 Feb 2016 12:03:21 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Question regarding Confidential Transactions
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2016 11:53:59 -0000

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.

> Although, since I think the range proof is optional for single output
> transactions (or at least, one output per transaction doesn't require a
> range proof since there's only one possible value that it can be to make the
> whole thing work, and that value must be in range, I'm not entirely sure how

I understand and agree.

> 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.

Best
Henning


On Tue, Feb 09, 2016 at 04:12:37PM -0600, Jeremy Papp via bitcoin-dev wrote:
> 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.
> 
> Although, since I think the range proof is optional for single output
> transactions (or at least, one output per transaction doesn't require a
> range proof since there's only one possible value that it can be to make the
> whole thing work, and that value must be in range, I'm not entirely sure how
> 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.
> 
> Jeremy Papp
> 
> On 2/9/2016 7:12 AM, Henning Kopp via bitcoin-dev wrote:
> >Hi all,
> >
> >I am trying to fully grasp confidential transactions.
> >
> >When a sender creates a confidential transaction and picks the blinding
> >values correctly, anyone can check that the transaction is valid. It
> >remains publically verifiable.
> >But how can the receiver of the transaction check which amount was
> >sent to him?
> >I think he needs to learn the blinding factor to reveal the commit
> >somehow off-chain. Am I correct with this assumption?
> >If yes, how does this work?
> >
> >All the best
> >Henning
> >
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

-- 
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany

Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp