Delivery-date: Wed, 25 Sep 2024 05:45:09 -0700
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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--