From: Jeremy Papp <pappjm@gmail•com>
To: Henning Kopp <henning.kopp@uni-ulm•de>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Question regarding Confidential Transactions
Date: Wed, 10 Feb 2016 10:39:25 -0600 [thread overview]
Message-ID: <56BB67BD.1060901@gmail.com> (raw)
In-Reply-To: <20160210115345.GD2336@banane.informatik.uni-ulm.de>
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
next prev parent reply other threads:[~2016-02-10 16:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-09 13:12 Henning Kopp
2016-02-09 22:12 ` Jeremy Papp
2016-02-10 11:53 ` Henning Kopp
2016-02-10 16:39 ` Jeremy Papp [this message]
2016-02-13 16:55 ` Adam Gibson
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=56BB67BD.1060901@gmail.com \
--to=pappjm@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=henning.kopp@uni-ulm$(echo .)de \
/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