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
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
|
Return-Path: <tensiam@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8D64728D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Feb 2019 10:19:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from EUR03-AM5-obe.outbound.protection.outlook.com
(mail-oln040092070099.outbound.protection.outlook.com [40.92.70.99])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30585FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Feb 2019 10:19:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=Ge2XTZqEgEbizjMI0RkHY+KpdSgLSTX3E7lxS95I2pw=;
b=M2BOWez5KJsq2leag36hEU1F2Ko5xXCW6Y824J9D+ubV2GnmMhs2roFP2cI95RL3FDGmEERu1VQuGB82Rn7zhIMTGOJhq7lIh9wKxZ31mkoMOoID0kMPi5ej/zXIWE88DZr9C0bdhnp3KFIX07K9uddr24zkG3Vuu0N8TOKhGEPcq62knoPDQGQunLF4W1wKebmeG0oJKNZl04bwJ4KGSirEfdo2WnXhy7Luc7o3Y+hnLfTawxjj8Ek5oLtCpdHUfOadUO/9OhW659xLCsYgI5me+U/cS3qVvvkusFBPCirBsfpFR56YgTndBhPUPRc5gtRJCwyNlx+R680wCx5/vg==
Received: from AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com
(10.152.16.54) by AM5EUR03HT239.eop-EUR03.prod.protection.outlook.com
(10.152.16.209) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17;
Mon, 11 Feb 2019 10:19:15 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.16.59) by
AM5EUR03FT031.mail.protection.outlook.com (10.152.16.111) with
Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.1580.17 via Frontend Transport; Mon, 11 Feb 2019 10:19:15 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
([fe80::85e1:a698:7b7c:a02c]) by
DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
([fe80::85e1:a698:7b7c:a02c%6]) with mapi id 15.20.1601.023;
Mon, 11 Feb 2019 10:19:15 +0000
From: "Kenshiro []" <tensiam@hotmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
ZmnSCPxj <ZmnSCPxj@protonmail.com>
Thread-Topic: [bitcoin-dev] Implementing Confidential Transactions in
extension blocks
Thread-Index: AQHUv5aqK9doshwpj0CV+ZeZH4q9cqXaBaMAgABbNRg=
Date: Mon, 11 Feb 2019 10:19:15 +0000
Message-ID: <DB6PR10MB1832F0E339FD9B76E87BC64FA6640@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183228F27750132F9A6A3542A6690@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
<U-ugv1xWdp4czsN38WhD6KQUPcYa4VLxNzUusM3YLRu4825eigldn3xTOw6IyoqpyFbymdKxWUGOQdlknr3L7rBOtssEKeYMkW4RKj5Rc1o=@protonmail.com>
In-Reply-To: <U-ugv1xWdp4czsN38WhD6KQUPcYa4VLxNzUusM3YLRu4825eigldn3xTOw6IyoqpyFbymdKxWUGOQdlknr3L7rBOtssEKeYMkW4RKj5Rc1o=@protonmail.com>
Accept-Language: en-US, es-ES
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:E7B62B4448A7C5D76BFD97A8DA28C4EE84E1C9C63954FA187FDF6865F7DF3342;
UpperCasedChecksum:50E378A055AB9291BA7430B5509388E705D7A9F00682C96AB9CA9F919B315B6F;
SizeAsReceived:7262; Count:44
x-tmn: [PZ2UL74uHk/JwJ815c2FhL0U6Vir3NSy]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5EUR03HT239;
6:ID8WyGQDYM72C4bNh5IfTRU+VAMZ99UCmfgT376MX0TL2Sf8G+G9uU6RBV0DD08dWUsDL80b2mfk/9e/ta/Ql/1uY1kxMCgNcUXxz2sK4NU/UCZG8DBWVtwN5kq+sdZb/IVCK3Yg+Y6Jq37iqJcKwT8CZ+p9zBlg64dYF2NqJ+7J7HL8EO/jgcfvTEoN4KuO3CLFG91DFe2bBkxmoGAGSKB5o0t7kNef3LJiyy7NVeNICkEM58GApcxlNil6GFGze6E9RLtx35QxWyYY15KLtubKDQ+pmbbIQ8T5O8AR/UDr0qrTIQ/kSvmQAQqB7q3Dx/UpZM2z2W/VwzObWQZI34ylst7pI9JMqEUyNz78Ht8i9bhBCNNyWGPI2eFRjUnib0KmkDna5oh9UqR1JjNgJvtaKEkVohmzZwgG9/0E7niMUTb1oo9NF4sVAxoUL5a1CCvHyfa+bkwHeU+TrRpYhQ==;
5:lM1+l3MIl5scQ9mU40afC2IcjW58l/l4LvdKhxq0sru5uQtU7quXoOluHkbB39rW/I+BKvYn+WruLgI0RoAvR2fUBLLHs1TmINm+sE75fGuVVDPlpSJSIYocTO6ih61rZ2xun8Sxn5R2fw296JtgbCbW1Pbbd6HyZ2G3Toyn6V7p/atfQzf+UI1ehEtKehhm4YW6WTqYUoPTKqwGkOXIyQ==;
7:Sb86qwyov33oJKvL9hKVuCLo89haBBcNC8Z5lzx0wL5gGhfykbHqzdgXsylGL0DZw/xJ+IPy/qCmnT5mpJGiYukt5hMBrd3d8Z5lRxczvKCaZB6LT1kAWOoIUcsmwFA420pbSLr3RZyfakxxc7hbOQ==
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0;
RULEID:(2390118)(7020095)(20181119070)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045);
SRVR:AM5EUR03HT239;
x-ms-traffictypediagnostic: AM5EUR03HT239:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058);
SRVR:AM5EUR03HT239; BCL:0; PCL:0; RULEID:; SRVR:AM5EUR03HT239;
x-microsoft-antispam-message-info: geeRTyEvkuNX4F9XkaN75wWIuSs+c++Cf0JSgKbhHOmVhDc6U+qGBOC2lK65KfCX
Content-Type: multipart/alternative;
boundary="_000_DB6PR10MB1832F0E339FD9B76E87BC64FA6640DB6PR10MB1832EURP_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9
X-MS-Exchange-CrossTenant-Network-Message-Id: c1118d47-4dc8-45f4-e816-08d6900a5fd7
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2019 10:19:15.0971 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT239
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Tue, 12 Feb 2019 12:46:54 +0000
Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in
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: Mon, 11 Feb 2019 10:19:19 -0000
--_000_DB6PR10MB1832F0E339FD9B76E87BC64FA6640DB6PR10MB1832EURP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Good morning ZmnSCPxj,
Thank you for your answer.
There is a position that fullnodes must be able to get a view of the UTXO s=
et, and extension blocks (which are invisible to pre-extension-block fullno=
des) means that fullnodes no longer have an accurate view of the UTXO set.
I think old nodes don't need to know the CT part of the UTXO set. It would =
be possible to move coins from normal address to CT address and the opposit=
e, it would be written as "anyone-can-spend" transactions in the main block=
so old nodes are fully aware of these transactions. Miners would enforce t=
hat "anyone-can-spend" transactions are true. The full details of the trans=
actions involving CT would be in the extension block. CT to CT transactions=
don't need to be written in the main block. Maybe I'm missing some technic=
al detail here but it looks good for me.
> - Capacity increase: the CT signature is stored in the extension block, s=
o CT transactions increase the maximum number of transactions per block
This is not an unalloyed positive: block size increase, even via extension =
block, translates to greater network capacity usage globally on all fullnod=
es.
Yes, there is an increase in block size and network usage but I think it wo=
uld still be possible for people with regular computers to run a full node,=
an people in developing countries could use light wallets.
Regards
________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Monday, February 11, 2019 5:29
To: Kenshiro \[\]; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in extens=
ion blocks
Good morning Kenshiro,
> - Soft fork: old nodes see CT transactions as "sendtoany" transactions
There is a position that fullnodes must be able to get a view of the UTXO s=
et, and extension blocks (which are invisible to pre-extension-block fullno=
des) means that fullnodes no longer have an accurate view of the UTXO set.
SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, alt=
hough pre-SegWit fullnodes could be convinced that a particular UTXO is any=
one-can-spend even though they are no longer anyone-can-spend.
Under this point-of-view, then, extension block is "not" soft fork.
It is "evil" soft fork since older nodes are forced to upgrade as their int=
ended functionality becomes impossible.
In this point-of-view, it is no better than a hard fork, which at least is =
very noisy about how older fullnode versions will simply stop working.
> - Safe: if there is a software bug in CT it's impossible to create new co=
ins because the coins move from normal block to normal block as public tran=
sactions
I think more relevant here is the issue of a future quantum computing breac=
h of the algorithms used to implement confidentiality.
I believe this is also achievable with a non-extension-block approach by im=
plementing a globally-verified publicly-visible counter of the total amount=
in all confidential transaction outputs.
Then it becomes impossible to move from confidential to public transactions=
with a value more than this counter, thus preventing inflation even if a f=
uture QC breach allows confidential transaction value commitments to be ope=
ned to any value.
(do note that a non-extension-block approach is a definite hardfork)
> - Capacity increase: the CT signature is stored in the extension block, s=
o CT transactions increase the maximum number of transactions per block
This is not an unalloyed positive: block size increase, even via extension =
block, translates to greater network capacity usage globally on all fullnod=
es.
Regards,
ZmnSCPxj
--_000_DB6PR10MB1832F0E339FD9B76E87BC64FA6640DB6PR10MB1832EURP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Good morning ZmnSCPxj,</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Thank you for your answer.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<i>There is a position that fullnodes must be able to get a view of the UTX=
O set, and extension blocks (which are invisible to pre-extension-block ful=
lnodes) means that fullnodes no longer have an accurate view of the UTXO se=
t.</i><br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
I think old nodes don't need to know the CT part of the UTXO set. It would =
be possible to move coins from normal address to CT address and the opposit=
e, it would be written as "anyone-can-spend" transactions in the =
main block so old nodes are fully aware of
these transactions. Miners would enforce that "anyone-can-spend"=
transactions are true. The full details of the transactions involving CT w=
ould be in the extension block. CT to CT transactions don't need to be writ=
ten in the main block. Maybe I'm missing some
technical detail here but it looks good for me.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<span><i>> - Capacity increase: the CT signature is stored in the extens=
ion block, so CT transactions increase the maximum number of transact=
ions per block<br>
</i></span>
<div><i><br>
</i></div>
<span><i>This is not an unalloyed positive: block size increase, even via e=
xtension block, translates to greater network capacity usage globally on al=
l fullnodes.</i></span><br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Yes, there is an increase in block size and network usage but I think it wo=
uld still be possible for people with regular computers to run a full node,=
an people in developing countries could use light wallets.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Regards</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> ZmnSCPxj <ZmnSCPxj=
@protonmail.com><br>
<b>Sent:</b> Monday, February 11, 2019 5:29<br>
<b>To:</b> Kenshiro \[\]; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Implementing Confidential Transactions in=
extension blocks</font>
<div> </div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">Good morning Kenshiro,<br>
<br>
> - Soft fork: old nodes see CT transactions as "sendtoany" tr=
ansactions<br>
<br>
There is a position that fullnodes must be able to get a view of the UTXO s=
et, and extension blocks (which are invisible to pre-extension-block fullno=
des) means that fullnodes no longer have an accurate view of the UTXO set.<=
br>
SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, alt=
hough pre-SegWit fullnodes could be convinced that a particular UTXO is any=
one-can-spend even though they are no longer anyone-can-spend.<br>
<br>
Under this point-of-view, then, extension block is "not" soft for=
k.<br>
It is "evil" soft fork since older nodes are forced to upgrade as=
their intended functionality becomes impossible.<br>
In this point-of-view, it is no better than a hard fork, which at least is =
very noisy about how older fullnode versions will simply stop working.<br>
<br>
> - Safe: if there is a software bug in CT it's impossible to create new=
coins because the coins move from normal block to normal block as public t=
ransactions<br>
<br>
I think more relevant here is the issue of a future quantum computing breac=
h of the algorithms used to implement confidentiality.<br>
<br>
I believe this is also achievable with a non-extension-block approach by im=
plementing a globally-verified publicly-visible counter of the total amount=
in all confidential transaction outputs.<br>
Then it becomes impossible to move from confidential to public transactions=
with a value more than this counter, thus preventing inflation even if a f=
uture QC breach allows confidential transaction value commitments to be ope=
ned to any value.<br>
<br>
(do note that a non-extension-block approach is a definite hardfork)<br>
<br>
> - Capacity increase: the CT signature is stored in the extension block=
, so CT transactions increase the maximum number of transactions per block<=
br>
<br>
This is not an unalloyed positive: block size increase, even via extension =
block, translates to greater network capacity usage globally on all fullnod=
es.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</div>
</span></font></div>
</div>
</body>
</html>
--_000_DB6PR10MB1832F0E339FD9B76E87BC64FA6640DB6PR10MB1832EURP_--
|