1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Return-Path: <ekaggata@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5399F1061
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Feb 2016 16:55:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com
[209.85.215.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A00D3184
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Feb 2016 16:55:34 +0000 (UTC)
Received: by mail-lf0-f43.google.com with SMTP id l143so68204963lfe.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Feb 2016 08:55:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=DAnbiObUjOe6u8mhEtBzO0M/2H9wIjz0S8iWMlPDRhU=;
b=ADlZRjbPupWvAt5QUyv9jF5ZsocAjC1wnmFDvbqBansBYWSYrNtz6JRBGzOFILlLCy
L3Iey2pF4t22o7feaPJj+OzddmM7I3t+cZhUwHxUvWM964GnQptZI3Ych6ES5wkVTk7q
9L03YMV9cKAnREFKBPJ85XVPSPVSKabmiaRJPOxfI10zXIE9CGjd2/GfP3LhT4raikdz
5oItL/wYQ8onjcC9Im8c1lziSdM26tYsIht6Slhi9IEfxLGzl7/D1NbeQBtZBDYnmLp1
eXr5NRZdch1OxjbCCWdEqWW/4IZCM9w2F+/G5SJPDm4gZTxDggm/GFORTlTEJeaUs0kV
7sOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=DAnbiObUjOe6u8mhEtBzO0M/2H9wIjz0S8iWMlPDRhU=;
b=OF9d0+cF8Qx28GuOfHhm0lCwOgwuy2/7rnlUsSFM5Ftswo/2dA/eLaaBLHsZdHEPxt
zQKdKRHiJDghhfCOnQQf6UpTCjB+yoklidN1eQHwKa5/X9Ka0ENSyzWqjtLS6X4k1xrg
8p8O9bnmJ6aAW2cVV23/UMlmip/RACEf9MIjWf0ansKrPMMRv4Sjm/sLELmxBuQtjp1P
+9O5fHYPeZ47H4WPJrC7Sk95+L5STxydVY4erWzqtVtN4/MAQwMQIHJuCei5FkZta8/+
FMeWNyRLomelPoeul2JDGkTmzHmAdUJqLKHN1kEBYBIDq2NCf7q7uBpZzb1yzvkzbL8O
hhIw==
X-Gm-Message-State: AG10YOTVSWNrG9yKmiOEXj9xTz86Wd3XOZRI1oBeTgDw+n4C/Gy1Sw5fi3/jkvcipwKD7Q==
X-Received: by 10.25.1.65 with SMTP id 62mr3222213lfb.89.1455382533017;
Sat, 13 Feb 2016 08:55:33 -0800 (PST)
Received: from [192.168.0.101] ([62.205.214.125])
by smtp.googlemail.com with ESMTPSA id
zk9sm2541098lbb.3.2016.02.13.08.55.32
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 13 Feb 2016 08:55:32 -0800 (PST)
Message-ID: <56BF6003.6040803@gmail.com>
Date: Sat, 13 Feb 2016 18:55:31 +0200
From: Adam Gibson <ekaggata@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <20160209131215.GE2329@banane.informatik.uni-ulm.de> <56BA6455.9030803@gmail.com> <20160210115345.GD2336@banane.informatik.uni-ulm.de>
<56BB67BD.1060901@gmail.com>
In-Reply-To: <56BB67BD.1060901@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW 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: Sat, 13 Feb 2016 17:08:30 +0000
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: Sat, 13 Feb 2016 16:55:37 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In case it helps:
The elements alpha sidechain uses a different address format, which
includes an ECDH pubkey used for creating an ECDH shared secret.
That shared secret is used to seed a RFC6979 prng, which allows both
sides to generate the blinding factors used in the rangeproof.
So the situation is: both sides can generate the blinding factors, but
also the fake signatures used in the rangeproof (the basic idea there
is to have N signatures in a ring, but only one of them real; the rest
are forged and can be (must be) entirely random numbers. I say 'basic'
because the Borromean sig design is to link together several rings,
not just one). This allows the sender to embed the amount into one of
those fake signatures (usually the last one) using xor, with certain
formatting details.
It would be possible to not bother to embed the amount in this way;
the receiver, knowing the stream of fake/real signatures (again -
because he knows the seed for the prng), could simply observe which
ones are real and therefore know the digits of the amount. But if he
did it this way, it would not be possible to embed any other data into
the range proof (such as: auditing related information) using xor as
above.
I did some detailed explanation/investigation of this in sections 3.3
and 3.4 of
https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf
; with apologies for any errors, it was just an investigation I did
last summer.
On 02/10/2016 06:39 PM, Jeremy Papp via bitcoin-dev wrote:
> 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 _______________________________________________
> bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWv1/8AAoJELOuCfHpoxl6dV8H/AvlEUebgKBAZdSdIEDKm0m0
pSXNWH62v327YdJ2wFqPCB2zG9HKXP76XhCGx39PEEvBmAFAoD6URAWPk8o03kTo
aJZUeRB7wLqIALuUub/0JzAJwcxZtTIhYu3ygfyZZuvpomG8yXlERwfjB+BcCXnm
D7TJ2qOyq3X3uaneb/OnUEvDxOrl9zAp9q7CUnFQB2xagCRnHyGNcrWaH43RmpHl
Eima6eonQUR4AAcIUu0CKSRjgM6q46bMbXTFt9I4XeqQxsMB5Gfe9Ggk15TNRoUm
ENVaJnPL4qlJqODSrO9R4xrurVCcp7HVeR9B5aztFQszVNxhMoZtFlyn5U3J0gY=
=+I00
-----END PGP SIGNATURE-----
|
