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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
|
Return-Path: <adam.back@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E43BE955
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 01:43:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com
[209.85.220.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CECB7175
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Apr 2017 01:43:47 +0000 (UTC)
Received: by mail-qk0-f178.google.com with SMTP id d131so37799266qkc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Apr 2017 18:43:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:reply-to:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=eV10JI7g2ohUxcXCKEDyGwO1FdmbogDKdfQm8azR3kE=;
b=EHKVs2gQPX6pAzikxDsXg+NnTlrOwOeJmT1w4fWLwruoGFg9e9EnnxqoFX6a0bfy/o
FdU5cOCWkVORUQ2Xa5OcJ2FUAV9bsSvd8UxXTyNIa9yN6m7o48PWDi2vyJQd0mmHTojz
/I6KGHmW7xUG1o+LZqnvYTGVqswU01PueLkTphewQAcy15BKD7ZitetJxm0ivapXtUYD
kyoOiIXRYARMY0Vp6T/TbWPbEh43kdN9FX/zauvPfA5rNelK8h2Xn5u4EJ0C8Wg1fgaP
VmRRDMM7LN6231sTpGJpPyJX+e1Xht8gwO9D02qmOmOJMvceHdY3HJHsNw5SgOCwSFfB
Iv0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
:from:date:message-id:subject:to:cc;
bh=eV10JI7g2ohUxcXCKEDyGwO1FdmbogDKdfQm8azR3kE=;
b=HJTZBdi12atkv3+VJSGzo13Ha5cTpuwi6feeEJxT4GgNg2wmHsXsakURUvQHXhnyU8
Qt7/9br4zzRqt5H23g4cG9SBiuj3WztKsX75zrKeH4NsMCgvZRlCQJOUZyPXvl5bQmsO
r5OPrzWsS67F2w8CvglAp/jaXnRZhwiyHJL/FaJmC84WIrBWi8/Sn6gYNbrfnEndstTX
xRhzsTtCw+rPinjCzQeA7dc1X1txzuktx3t2JdOROzX7Mi2I/0BK5CKVMTzDvPwKTCMF
UPuQ08pIUKlYQi01n3xiC87wZEy2J6A1Xq06IB0fPg3Ysfd0SmX+WOIJxbvIiFh2Z8Vs
d+PA==
X-Gm-Message-State: AN3rC/4ChFuh03SJIlCNBlrj1logMvy8Y/EXVxrW8XZR8zdT7LjF3zN3
GUCMyaBFE+8c8xU81VR65IcrqCnw6A==
X-Received: by 10.55.73.6 with SMTP id w6mr483663qka.153.1492047826988; Wed,
12 Apr 2017 18:43:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.141.13 with HTTP; Wed, 12 Apr 2017 18:43:46 -0700 (PDT)
Received: by 10.12.141.13 with HTTP; Wed, 12 Apr 2017 18:43:46 -0700 (PDT)
Reply-To: adam@cypherspace.org
In-Reply-To: <6DF303E6-E379-45FD-947B-BB5F938177E5@gmail.com>
References: <6DF303E6-E379-45FD-947B-BB5F938177E5@gmail.com>
From: Adam Back <adam.back@gmail.com>
Date: Wed, 12 Apr 2017 18:43:46 -0700
Message-ID: <CALqxMTGPfwxy56PJew0qHbdsy82UAgzwduciOVK18GfBDoSKQQ@mail.gmail.com>
To: Oleg Andreev <oleganza@gmail.com>
Content-Type: multipart/alternative; boundary=001a114a922cb7322f054d027494
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Deploying CT in Bitcoin without extension blocks?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Thu, 13 Apr 2017 01:43:49 -0000
--001a114a922cb7322f054d027494
Content-Type: text/plain; charset=UTF-8
See this soft-fork proposal from Felix Weiss
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html
Adam
On Apr 12, 2017 5:43 PM, "Oleg Andreev via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> (This is a sketch, not a fully-formed proposal, just to kick off the
> discussion.)
>
> Confidential Transactions (by GMaxwell & Poelstra) require a new
> accounting model,
> new representation of numbers (EC points as Pedersen commitments) and
> range proofs
> per number. Setting aside performance and bandwidth concerns (3-4Kb per
> output,
> 50x more signature checks), how would we deploy that feature on Bitcoin
> network
> in the most compatible manner?
>
> I'll try to present a sketch of the proposal. I apologize if this
> discussion already
> happened somewhere, although I couldn't find anything on this subject,
> apart from Elements
> sidechain proposal, of course.
>
> At first glance we could create a new extblock and transaction format, add
> a protocol to
> "convert" money into and from such extblock, and commit to that extblock
> from the
> outer block's coinbase transaction. Unfortunately, this opens gates to a
> flood of
> debates such as what should be the block size limit in such block, should
> we
> take opportunity to fix over 9000 of pet-peeve issues with existing
> transactions
> and blocks, should we adjust inflation schedule, insert additional PoW,
> what would
> Satoshi say etc. Federated sidechain suffers from the same issues, plus
> adds
> concerns regarding governance, although it would be more decoupled, which
> is useful.
>
> I tried to look at a possibility to make the change as compatible as
> possible,
> sticking confidential values right into the existing transaction structure
> and
> see how that would look like. As a nice bonus, confidential transactions
> would have
> to fit into the hard-coded 1 Mb limit, preserving the drama around it :-P
>
> We start with a segwit-enabled script versioning and introduce 2 new
> script versions:
> version A has an actual program concatenated with the commitment, while
> version B
> has only the commitment and allows mimblewimble usage (no signatures,
> non-interactive
> cut-through etc). Legacy cleartext amount can nicely act as "min value" to
> minimize
> the range proof size, and range proofs themselves are provided separately
> in the
> segregated witness payload.
>
> Then, we soft fork additional rules:
>
> 1. In non-coinbase tx, sum of commitments on inputs must balance with sum
> of commitments
> on the outputs plus the cleartext mining fee in the witness.
> 2. Range proof can be confidential, based on borromean ring signature.
> 3. Range proof can be non-confidential, consisting of an amount and raw
> blinding factor.
> 4. Tx witness can have an excess value (cf. MW) and cleartext amount for a
> miner's fee.
> 5. In coinbase tx, total plaintext reward + commitments must balance with
> subsidy,
> legacy fees and new fees in the witness.
> 6. Extra fees in the witness must be signed with the excess value's key.
>
> The confidential transactions use the same UTXO set, can be co-authored
> with plaintext inputs/outputs
> using legacy software and maybe even improve scalability by compressing
> on-chain transactions
> using mimblewimble cut-through.
>
> The rules above could have been made more complicated with export/import
> logic to allow users
> converting their coins to and from confidential ones, but that would
> require
> more complex support from miners to respect and merge outputs representing
> "plaintext value bank",
> mutate export transactions, which in turn requires introduction of a
> non-malleable TxID
> that excludes miner-adjustable export/import outputs.
>
> The rules above have a nice side effect that miners, being the minters of
> confidential coins,
> can sell them at a premium, which creates an incentive for them to
> actually support
> that feature and work on improving performance of rangeproof validation
> (e.g. in GPUs).
>
> Would love to hear comments and criticism of that approach.
>
> Thanks!
> Oleg.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a114a922cb7322f054d027494
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">See this soft-fork proposal from Felix Weiss=C2=A0<div di=
r=3D"auto"><br></div><div dir=3D"auto"><a href=3D"https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2016-January/012194.html">https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html</a><div dir=
=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">Adam</div></div></d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Apr 1=
2, 2017 5:43 PM, "Oleg Andreev via bitcoin-dev" <<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">(This is a sketch, not a fully-formed proposal, just to kick off the disc=
ussion.)<br>
<br>
Confidential Transactions (by GMaxwell & Poelstra) require a new accoun=
ting model,<br>
new representation of numbers (EC points as Pedersen commitments) and range=
proofs<br>
per number. Setting aside performance and bandwidth concerns (3-4Kb per out=
put,<br>
50x more signature checks), how would we deploy that feature on Bitcoin net=
work<br>
in the most compatible manner?<br>
<br>
I'll try to present a sketch of the proposal. I apologize if this discu=
ssion already<br>
happened somewhere, although I couldn't find anything on this subject, =
apart from Elements<br>
sidechain proposal, of course.<br>
<br>
At first glance we could create a new extblock and transaction format, add =
a protocol to<br>
"convert" money into and from such extblock, and commit to that e=
xtblock from the<br>
outer block's coinbase transaction. Unfortunately, this opens gates to =
a flood of<br>
debates such as what should be the block size limit in such block, should w=
e<br>
take opportunity to fix over 9000 of pet-peeve issues with existing transac=
tions<br>
and blocks, should we adjust inflation schedule, insert additional PoW, wha=
t would<br>
Satoshi say etc. Federated sidechain suffers from the same issues, plus add=
s<br>
concerns regarding governance, although it would be more decoupled, which i=
s useful.<br>
<br>
I tried to look at a possibility to make the change as compatible as possib=
le,<br>
sticking confidential values right into the existing transaction structure =
and<br>
see how that would look like. As a nice bonus, confidential transactions wo=
uld have<br>
to fit into the hard-coded 1 Mb limit, preserving the drama around it :-P<b=
r>
<br>
We start with a segwit-enabled script versioning and introduce 2 new script=
versions:<br>
version A has an actual program concatenated with the commitment, while ver=
sion B<br>
has only the commitment and allows mimblewimble usage (no signatures, non-i=
nteractive<br>
cut-through etc). Legacy cleartext amount can nicely act as "min value=
" to minimize<br>
the range proof size, and range proofs themselves are provided separately i=
n the<br>
segregated witness payload.<br>
<br>
Then, we soft fork additional rules:<br>
<br>
1. In non-coinbase tx, sum of commitments on inputs must balance with sum o=
f commitments<br>
=C2=A0 =C2=A0on the outputs plus the cleartext mining fee in the witness.<b=
r>
2. Range proof can be confidential, based on borromean ring signature.<br>
3. Range proof can be non-confidential, consisting of an amount and raw bli=
nding factor.<br>
4. Tx witness can have an excess value (cf. MW) and cleartext amount for a =
miner's fee.<br>
5. In coinbase tx, total plaintext reward + commitments must balance with s=
ubsidy,<br>
=C2=A0 =C2=A0legacy fees and new fees in the witness.<br>
6. Extra fees in the witness must be signed with the excess value's key=
.<br>
<br>
The confidential transactions use the same UTXO set, can be co-authored wit=
h plaintext inputs/outputs<br>
using legacy software and maybe even improve scalability by compressing on-=
chain transactions<br>
using mimblewimble cut-through.<br>
<br>
The rules above could have been made more complicated with export/import lo=
gic to allow users<br>
converting their coins to and from confidential ones, but that would requir=
e<br>
more complex support from miners to respect and merge outputs representing =
"plaintext value bank",<br>
mutate export transactions, which in turn requires introduction of a non-ma=
lleable TxID<br>
that excludes miner-adjustable export/import outputs.<br>
<br>
The rules above have a nice side effect that miners, being the minters of c=
onfidential coins,<br>
can sell them at a premium, which creates an incentive for them to actually=
support<br>
that feature and work on improving performance of rangeproof validation (e.=
g. in GPUs).<br>
<br>
Would love to hear comments and criticism of that approach.<br>
<br>
Thanks!<br>
Oleg.<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>
--001a114a922cb7322f054d027494--
|