summaryrefslogtreecommitdiff
path: root/d1/60147d94d727e1744edebf9a3c9f22105be043
blob: c6b71d7fd3836b1b501364d36e875ceb927e4616 (plain)
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
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
Delivery-date: Wed, 25 Sep 2024 05:45:09 -0700
Received: from mail-yb1-f188.google.com ([209.85.219.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBTEL2C3QMGQEUSPD7GA@googlegroups.com>)
	id 1stROG-0001sM-MT
	for bitcoindev@gnusha.org; Wed, 25 Sep 2024 05:45:09 -0700
Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e2019b73d66sf11118243276.3
        for <bitcoindev@gnusha.org>; Wed, 25 Sep 2024 05:45:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1727268302; x=1727873102; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=GcOYTzk4aljZZcsRS31AuYaQNUuhFHnyeQu1yUMndaA=;
        b=HAvmwQ3PGE2qNX5ERzPkxeQ4j91Fn81+zHTW7WKo/BqKR0P7AqMkXZgUeOIX3NtOlA
         GWDILhHYwUHMi3Q17I0JMsLAvKO8ZH422KKyFFUBrmvTM22Az5ehHMfxauOQP3mLSNIW
         BPHqzIszcK00gUZjO0jEIMDGGwBsLkhI4anhM+Hc3/th/BsGX2CY0aSVnbXqvGkkA7hb
         gbrgTLP2E6WY/ygaqEMEk+XuEzQ+50v59RC90/kFOpxlCl9QdcHGTlAGflDOhiVJfa61
         AVJMg5uKswWu9p5k+wN0rVW1m5GyAAt5InRnJ+MYpkUWJlhuxLV79FtjfQqUEHPmiyPN
         HTXw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1727268302; x=1727873102; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GcOYTzk4aljZZcsRS31AuYaQNUuhFHnyeQu1yUMndaA=;
        b=c5XkitGd+1JnTuwhGj9VLq+VvNW5oFC69/7uI2ZXxSdb1u/g6mQoS4CLgtO/ks4CyQ
         sgqzHzchilW48L/O1nTvzA+4ELsbSNKcyGXdialAP4EDJHwJfDpmOTCmbB+ow8RfwDba
         HNBr6Q94W2m9TlrxpIMNgHlQhVKoa5u3NiKY9ITdbHUuQoFazVm03atDrPIAYesuaoNL
         fFMbBsxfMwiovQqi2H0ZMo1+Utp186CDFDY3zB34NV8ogC9+34fIFYKbz2R8tem4XSHF
         1Pey3rHR/IKMd6cV0ACoszwrBvpgWAsQlVEzCK8GWAKnlnXP9oF6a3lbhE4s7xKU1PHT
         CnBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1727268302; x=1727873102;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=GcOYTzk4aljZZcsRS31AuYaQNUuhFHnyeQu1yUMndaA=;
        b=HLhR6aaTlM1tcScI5b63DTzlVFVWxiiso+auN4J6oi8t5AR3B+HibDPklpV0KfBtug
         O0eWb7NSicbjnEikNF57ZcGQ0pPrHZEIANr7+wSntPV1g/2RX7AkzTkqDMtdQfntoVnV
         f168JxfoGG0X4MTFoVQdNoe7e3Q1mwtyydKAkFceOm4Yi+P3y4LLGiGGZ+DY3d44CBW1
         oTRDoXR37rn9UoB0yFGzmd0/1mIW+GIoY0TBmXPEBS7ZGLIMkYldhPtskcaeuaFpwhhP
         7VkvdD9xgR7EwgEkQirQpKhDUWfun46x2Qffzv0arMRXh9mmMJPeRqYfmwFdgLI1GKx5
         QPYA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVVzJkZCfQyoXLVOwVyJ/glumGVo/FWKICfFCPdTsqN9ELdXb8m8BhF04EIh3GZESF5XI+Tmf8g1pGG@gnusha.org
X-Gm-Message-State: AOJu0YyrCckRXF5mz37g+1Bw0K0EuJk5GDD6hjIaDXObq4nSIApc4Sii
	5vpV3wnoyTwPXSD5sWLjv+AzkDyUeICso9VVXNcyeJZGZdFGijig
X-Google-Smtp-Source: AGHT+IHBmhHhjBNp+4zYRkE6Q+0mXiAiXkNwNsZh52gyQgWrALzw3e3XpEuFrDolUwborAjQrPbhLg==
X-Received: by 2002:a05:6902:1792:b0:e1a:a580:e1d7 with SMTP id 3f1490d57ef6-e24d7fdfce8mr2090380276.22.1727268302010;
        Wed, 25 Sep 2024 05:45:02 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:18c6:b0:e22:6a94:f23d with SMTP id
 3f1490d57ef6-e226a94f4edls1766187276.1.-pod-prod-03-us; Wed, 25 Sep 2024
 05:44:59 -0700 (PDT)
X-Received: by 2002:a05:690c:89:b0:64b:5cc7:bcbc with SMTP id 00721157ae682-6e21da002camr19748167b3.32.1727268299759;
        Wed, 25 Sep 2024 05:44:59 -0700 (PDT)
Received: by 2002:a05:690c:2c88:b0:6d6:77c4:ed15 with SMTP id 00721157ae682-6e21f007b82ms7b3;
        Wed, 25 Sep 2024 05:23:58 -0700 (PDT)
X-Received: by 2002:a05:690c:7604:b0:6dd:fe5e:8828 with SMTP id 00721157ae682-6e21d9e4549mr19939017b3.42.1727267036835;
        Wed, 25 Sep 2024 05:23:56 -0700 (PDT)
Date: Wed, 25 Sep 2024 05:23:56 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <33cd30ab-c5c2-4785-9815-4a2da3c7e267n@googlegroups.com>
In-Reply-To: <b0afc5f2-4dcc-469d-b952-03eeac6e7d1b@gmail.com>
References: <b0afc5f2-4dcc-469d-b952-03eeac6e7d1b@gmail.com>
Subject: [bitcoindev] Re: Shielded CSV: Private and Efficient Client-Side Validation
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_202842_1445898861.1727267036352"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: 0.5 (/)

------=_Part_202842_1445898861.1727267036352
Content-Type: multipart/alternative; 
	boundary="----=_Part_202843_782265829.1727267036352"

------=_Part_202843_782265829.1727267036352
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jonas,

Few remarks from a cursory reading on the abstract, contributions and=20
technical overview sections.

As you're underscoring too in the paper, I think one of the main=20
scalability bottleneck of the
paper is the 64 byte of data to be written in the blockchain, plus a small=
=20
constant overhead,
that 64 byte be it a plaintext of atomic client-side validation=20
transaction, or an aggregation
in some of cryptographically efficient representation such as an=20
accumulator.

(The 64 byte of data or whatever the size must be public in the blockchain,=
=20
otherwise a distributed
publication board of the pay-to-contract commitment in the blockchain must=
=20
be available to make the
reveal of the commitment available to CSV clients in a interactively=20
mininized fashion).

On the nullifier itself, i.e "Thus far, our protocol lacks a mechanism to=
=20
prevent double spending. To
address this issue, we require that all coins spent in a transaction are=20
=E2=80=9Dnullified=E2=80=9D by publishing
a corresponding nullifier on the blockchain". There is a point that Peter=
=20
Todd made me once about
his old tree chain scheme and the probabilistic validation by clients if my=
=20
memory is correct,
where a client does not have to verify the whole of the transactions total,=
=20
where in this proposed
CSV scheme it sounds each nullifier verification participant needs the=20
banwidth cost to read the whole
of the blockchain.

Beyond, about the privacy claim, i.e "coin proofs reveal no information=20
other than the validity
of the coin and its creation time" there could be a way to hide the coin=20
creation time, which
can be a huge factor of deanonymization if you apply cross-layers=20
deanonymization techniques,
by using some range proofs like pedersen commitments where the lower and=20
upper bound of the
range value are logically ordered on sequence of chain blocks time and=20
height (those
maps themselves ordered in a discrete fashion).

Without entering in a debate about perfectly hidding versus perfectly=20
binding cryptographic
properties, which can be very quickly degenerates in a debate about axioms=
=20
and corollary
in mathematics, I think such cryptographic structure could have a=20
consensus-level usage in
the future, e.g if we extend it as dedicated structure in the taproot=20
annex, where the field
is accounted accordingly as witness units.

Best,
Antoine
ots hash: eb285459dacfd0b4b58506f58360fea8b005a66beccc6fdb525ab203341a18c8

Le mardi 24 septembre 2024 =C3=A0 14:34:15 UTC+1, Jonas Nick a =C3=A9crit :

> Hello list,
>
> We (Liam Eagen, Robin Linus, and I) are pleased to announce the release o=
f=20
> the
> Shielded CSV whitepaper, which describes a private and efficient=20
> client-side
> validation (CSV) protocol. Shielded CSV builds upon previous work propose=
d=20
> on
> this mailing list, including contributions by Peter Todd [0], RGB [1],=20
> Taproot
> Assets [2], and zkCoins [3].
>
> The whitepaper is available here:
>
> https://github.com/ShieldedCSV/ShieldedCSV/releases/latest/download/shiel=
dedcsv.pdf
>
> Our work differs from previous approaches in two main aspects:
> 1. Shielded CSV is defined using the "Proof-Carrying Data" abstraction,=
=20
> which
> can be instantiated via recursive zkSNARKs or folding schemes. This=20
> provides
> "full" privacy (hiding of the transaction graph) and ensures that coin=20
> proofs
> and verification time are independent of the transaction graph.
> 2. Instead of using Bitcoin transactions for CSV-payments, a Shielded CSV
> payment only requires posting 64 bytes of data to the blockchain=20
> (regardless
> of the CSV-transaction size) and a small constant overhead, significantly
> reducing on-chain cost.
>
> The Shielded CSV protocol is currently defined using Rust-based=20
> pseudocode. We
> believe that Shielded CSV is both a promising candidate for implementatio=
n=20
> and
> provides an extensible framework for further innovation in the CSV space.=
=20
> We
> welcome feedback and look forward to discussing and expanding upon this=
=20
> work.
>
> [0]=20
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003=
714.html
> [1]=20
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554=
.html
> [2]=20
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020196=
.html
> [3]=20
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021679.h=
tml
>
>
> # Abstract
>
> Cryptocurrencies allow mutually distrusting users to transact monetary=20
> value
> over the internet without relying on a trusted third party.
>
> Bitcoin, the first cryptocurrency, achieved this through a novel protocol=
=20
> used
> to establish consensus about an ordered transaction history. This require=
s=20
> every
> transaction to be broadcasted and verified by the network, incurring
> communication and computational costs. Furthermore, transactions are=20
> visible to
> all nodes of the network, eroding privacy, and are recorded permanently,
> contributing to increasing storage requirements over time. To limit=20
> resource
> usage of the network, Bitcoin currently supports an average of 11=20
> transactions
> per second.
>
> Most cryptocurrencies today still operate in a substantially similar=20
> manner.
> Private cryptocurrencies like Zcash and Monero address the privacy issue =
by
> replacing transactions with proofs of transaction validity. However, this
> enhanced privacy comes at the cost of increased communication, storage, a=
nd
> computational requirements.
>
> Client-Side Validation (CSV) is a paradigm that addresses these issues by
> removing transaction validation from the blockchain consensus rules. This
> approach allows sending the coin along with a validity proof directly to=
=20
> its
> recipient, reducing communication, computation and storage cost. CSV=20
> protocols
> deployed on Bitcoin today~\cite{rgbblackpaper, taprootassets} do not full=
y
> leverage the paradigm's potential, as they still necessitate the overhead=
=20
> of
> publishing ordinary Bitcoin transactions. Moreover, the size of their coi=
n
> proofs is proportional to the coin's transaction history, and provide=20
> limited
> privacy. A recent improvement is the Intmax2~\cite{rybakken2023intmax2} C=
SV
> protocol, which writes significantly less data to the blockchain compared=
=20
> to a
> blockchain transaction and has succinct coin proofs.
>
> In this work, we introduce Shielded CSV, which improves upon=20
> state-of-the-art
> CSV protocols by providing the first construction that offers truly priva=
te
> transactions. It addresses the issues of traditional private cryptocurren=
cy
> designs by requiring only 64 bytes of data per transaction, called a
> \emph{nullifier}, to be written to the blockchain. Moreover, for each=20
> nullifier
> in the blockchain, Shielded CSV users only need to perform a single Schno=
rr
> signature verification, while non-users can simply ignore this data. The=
=20
> size
> and verification cost of coin proofs for Shielded CSV receivers is=20
> independent
> of the transaction history. Thus, one application of Shielded CSV is addi=
ng
> privacy to Bitcoin at a rate of 100 transactions per second, provided=20
> there is
> an adequate bridging mechanism to the blockchain.
>
> We specify Shielded CSV using the Proof Carrying Data (PCD) abstraction.=
=20
> We then
> discuss two implementation strategies that we believe to be practical,=20
> based on
> Folding Schemes and Recursive STARKs, respectively. Finally, we propose=
=20
> future
> extensions, demonstrating the power of the PCD abstraction and the=20
> extensibility
> of Shielded CSV. This highlights the significant potential for further
> improvements to the Shielded CSV framework and protocols built upon it.
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/33cd30ab-c5c2-4785-9815-4a2da3c7e267n%40googlegroups.com.

------=_Part_202843_782265829.1727267036352
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jonas,<br /><br />Few remarks from a cursory reading on the abstract, co=
ntributions and technical overview sections.<br /><br />As you're underscor=
ing too in the paper, I think one of the main scalability bottleneck of the=
<br />paper is the 64 byte of data to be written in the blockchain, plus a =
small constant overhead,<br />that 64 byte be it a plaintext of atomic clie=
nt-side validation transaction, or an aggregation<br />in some of cryptogra=
phically efficient representation such as an accumulator.<br /><br />(The 6=
4 byte of data or whatever the size must be public in the blockchain, other=
wise a distributed<br />publication board of the pay-to-contract commitment=
 in the blockchain must be available to make the<br />reveal of the commitm=
ent available to CSV clients in a interactively mininized fashion).<br /><b=
r />On the nullifier itself, i.e "Thus far, our protocol lacks a mechanism =
to prevent double spending. To<br />address this issue, we require that all=
 coins spent in a transaction are =E2=80=9Dnullified=E2=80=9D by publishing=
<br />a corresponding nullifier on the blockchain". There is a point that P=
eter Todd made me once about<br />his old tree chain scheme and the probabi=
listic validation by clients if my memory is correct,<br />where a client d=
oes not have to verify the whole of the transactions total, where in this p=
roposed<br />CSV scheme it sounds each nullifier verification participant n=
eeds the banwidth cost to read the whole<br />of the blockchain.<br /><br /=
>Beyond, about the privacy claim, i.e "coin proofs reveal no information ot=
her than the validity<br />of the coin and its creation time" there could b=
e a way to hide the coin creation time, which<br />can be a huge factor of =
deanonymization if you apply cross-layers deanonymization techniques,<br />=
by using some range proofs like pedersen commitments where the lower and up=
per bound of the<br />range value are logically ordered on sequence of chai=
n blocks time and height (those<br />maps themselves ordered in a discrete =
fashion).<br /><br />Without entering in a debate about perfectly hidding v=
ersus perfectly binding cryptographic<br />properties, which can be very qu=
ickly degenerates in a debate about axioms and corollary<br />in mathematic=
s, I think such cryptographic structure could have a consensus-level usage =
in<br />the future, e.g if we extend it as dedicated structure in the tapro=
ot annex, where the field<br />is accounted accordingly as witness units.<b=
r /><br />Best,<br />Antoine<br />ots hash: eb285459dacfd0b4b58506f58360fea=
8b005a66beccc6fdb525ab203341a18c8<br /><br /><div class=3D"gmail_quote"><di=
v dir=3D"auto" class=3D"gmail_attr">Le mardi 24 septembre 2024 =C3=A0 14:34=
:15 UTC+1, Jonas Nick a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;">Hello list,
<br>
<br>We (Liam Eagen, Robin Linus, and I) are pleased to announce the release=
 of the
<br>Shielded CSV whitepaper, which describes a private and efficient client=
-side
<br>validation (CSV) protocol. Shielded CSV builds upon previous work propo=
sed on
<br>this mailing list, including contributions by Peter Todd [0], RGB [1], =
Taproot
<br>Assets [2], and zkCoins [3].
<br>
<br>The whitepaper is available here:
<br><a href=3D"https://github.com/ShieldedCSV/ShieldedCSV/releases/latest/d=
ownload/shieldedcsv.pdf" target=3D"_blank" rel=3D"nofollow" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/Shie=
ldedCSV/ShieldedCSV/releases/latest/download/shieldedcsv.pdf&amp;source=3Dg=
mail&amp;ust=3D1727353229769000&amp;usg=3DAOvVaw3hgAaGPKE6okPD-_2nAPT5">htt=
ps://github.com/ShieldedCSV/ShieldedCSV/releases/latest/download/shieldedcs=
v.pdf</a>
<br>
<br>Our work differs from previous approaches in two main aspects:
<br>1. Shielded CSV is defined using the &quot;Proof-Carrying Data&quot; ab=
straction, which
<br>    can be instantiated via recursive zkSNARKs or folding schemes. This=
 provides
<br>    &quot;full&quot; privacy (hiding of the transaction graph) and ensu=
res that coin proofs
<br>    and verification time are independent of the transaction graph.
<br>2. Instead of using Bitcoin transactions for CSV-payments, a Shielded C=
SV
<br>    payment only requires posting 64 bytes of data to the blockchain (r=
egardless
<br>    of the CSV-transaction size) and a small constant overhead, signifi=
cantly
<br>    reducing on-chain cost.
<br>
<br>The Shielded CSV protocol is currently defined using Rust-based pseudoc=
ode. We
<br>believe that Shielded CSV is both a promising candidate for implementat=
ion and
<br>provides an extensible framework for further innovation in the CSV spac=
e. We
<br>welcome feedback and look forward to discussing and expanding upon this=
 work.
<br>
<br>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2013-November/003714.html" target=3D"_blank" rel=3D"nofollow" data-saferedi=
recturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://lists.linuxfo=
undation.org/pipermail/bitcoin-dev/2013-November/003714.html&amp;source=3Dg=
mail&amp;ust=3D1727353229769000&amp;usg=3DAOvVaw27MWp6EclsZFJnAXSUZJUt">htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003714.h=
tml</a>
<br>[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2023-April/021554.html" target=3D"_blank" rel=3D"nofollow" data-saferedirec=
turl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2023-April/021554.html&amp;source=3Dgmail&a=
mp;ust=3D1727353229769000&amp;usg=3DAOvVaw0fCaHYpBXVRtr4j2LGhk06">https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554.html</a>
<br>[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2022-April/020196.html" target=3D"_blank" rel=3D"nofollow" data-saferedirec=
turl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2022-April/020196.html&amp;source=3Dgmail&a=
mp;ust=3D1727353229769000&amp;usg=3DAOvVaw18O_pdNYkj3pVpzHUI_b_A">https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020196.html</a>
<br>[3] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2023-May/021679.html" target=3D"_blank" rel=3D"nofollow" data-saferedirectu=
rl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2023-May/021679.html&amp;source=3Dgmail&amp;u=
st=3D1727353229769000&amp;usg=3DAOvVaw00vhnCBby2m4bFHdQewL50">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021679.html</a>
<br>
<br>
<br># Abstract
<br>
<br>Cryptocurrencies allow mutually distrusting users to transact monetary =
value
<br>over the internet without relying on a trusted third party.
<br>
<br>Bitcoin, the first cryptocurrency, achieved this through a novel protoc=
ol used
<br>to establish consensus about an ordered transaction history. This requi=
res every
<br>transaction to be broadcasted and verified by the network, incurring
<br>communication and computational costs. Furthermore, transactions are vi=
sible to
<br>all nodes of the network, eroding privacy, and are recorded permanently=
,
<br>contributing to increasing storage requirements over time. To limit res=
ource
<br>usage of the network, Bitcoin currently supports an average of 11 trans=
actions
<br>per second.
<br>
<br>Most cryptocurrencies today still operate in a substantially similar ma=
nner.
<br>Private cryptocurrencies like Zcash and Monero address the privacy issu=
e by
<br>replacing transactions with proofs of transaction validity. However, th=
is
<br>enhanced privacy comes at the cost of increased communication, storage,=
 and
<br>computational requirements.
<br>
<br>Client-Side Validation (CSV) is a paradigm that addresses these issues =
by
<br>removing transaction validation from the blockchain consensus rules. Th=
is
<br>approach allows sending the coin along with a validity proof directly t=
o its
<br>recipient, reducing communication, computation and storage cost. CSV pr=
otocols
<br>deployed on Bitcoin today~\cite{rgbblackpaper, taprootassets} do not fu=
lly
<br>leverage the paradigm&#39;s potential, as they still necessitate the ov=
erhead of
<br>publishing ordinary Bitcoin transactions. Moreover, the size of their c=
oin
<br>proofs is proportional to the coin&#39;s transaction history, and provi=
de limited
<br>privacy. A recent improvement is the Intmax2~\cite{rybakken2023intmax2}=
 CSV
<br>protocol, which writes significantly less data to the blockchain compar=
ed to a
<br>blockchain transaction and has succinct coin proofs.
<br>
<br>In this work, we introduce Shielded CSV, which improves upon state-of-t=
he-art
<br>CSV protocols by providing the first construction that offers truly pri=
vate
<br>transactions. It addresses the issues of traditional private cryptocurr=
ency
<br>designs by requiring only 64 bytes of data per transaction, called a
<br>\emph{nullifier}, to be written to the blockchain. Moreover, for each n=
ullifier
<br>in the blockchain, Shielded CSV users only need to perform a single Sch=
norr
<br>signature verification, while non-users can simply ignore this data. Th=
e size
<br>and verification cost of coin proofs for Shielded CSV receivers is inde=
pendent
<br>of the transaction history. Thus, one application of Shielded CSV is ad=
ding
<br>privacy to Bitcoin at a rate of 100 transactions per second, provided t=
here is
<br>an adequate bridging mechanism to the blockchain.
<br>
<br>We specify Shielded CSV using the Proof Carrying Data (PCD) abstraction=
. We then
<br>discuss two implementation strategies that we believe to be practical, =
based on
<br>Folding Schemes and Recursive STARKs, respectively. Finally, we propose=
 future
<br>extensions, demonstrating the power of the PCD abstraction and the exte=
nsibility
<br>of Shielded CSV. This highlights the significant potential for further
<br>improvements to the Shielded CSV framework and protocols built upon it.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/33cd30ab-c5c2-4785-9815-4a2da3c7e267n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/33cd30ab-c5c2-4785-9815-4a2da3c7e267n%40googlegroups.com</a>.=
<br />

------=_Part_202843_782265829.1727267036352--

------=_Part_202842_1445898861.1727267036352--