From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <33cd30ab-c5c2-4785-9815-4a2da3c7e267n@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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,

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

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

(The 6= 4 byte of data or whatever the size must be public in the blockchain, other= wise a distributed
publication board of the pay-to-contract commitment= in the blockchain must be available to make the
reveal of the commitm= ent available to CSV clients in a interactively mininized fashion).
On the nullifier itself, i.e "Thus far, our protocol lacks a mechanism = to prevent double spending. To
address this issue, we require that all= coins spent in a transaction are =E2=80=9Dnullified=E2=80=9D by publishing=
a corresponding nullifier on the blockchain". There is a point that P= eter Todd made me once about
his old tree chain scheme and the probabi= listic validation by clients if my memory is correct,
where a client d= oes not have to verify the whole of the transactions total, where in this p= roposed
CSV scheme it sounds each nullifier verification participant n= eeds the banwidth cost to read the whole
of the blockchain.

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

Without entering in a debate about perfectly hidding v= ersus perfectly binding cryptographic
properties, which can be very qu= ickly degenerates in a debate about axioms and corollary
in mathematic= s, I think such cryptographic structure could have a consensus-level usage = in
the future, e.g if we extend it as dedicated structure in the tapro= ot annex, where the field
is accounted accordingly as witness units.
Best,
Antoine
ots hash: eb285459dacfd0b4b58506f58360fea= 8b005a66beccc6fdb525ab203341a18c8

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

We (Liam Eagen, Robin Linus, and I) are pleased to announce the release= of the
Shielded CSV whitepaper, which describes a private and efficient client= -side
validation (CSV) protocol. Shielded CSV builds upon previous work propo= sed on
this mailing list, including contributions by Peter Todd [0], RGB [1], = Taproot
Assets [2], and zkCoins [3].

The whitepaper is available here:
htt= ps://github.com/ShieldedCSV/ShieldedCSV/releases/latest/download/shieldedcs= v.pdf

Our work differs from previous approaches in two main aspects:
1. Shielded CSV is defined using the "Proof-Carrying Data" ab= straction, which
can be instantiated via recursive zkSNARKs or folding schemes. This= provides
"full" privacy (hiding of the transaction graph) and ensu= res that coin proofs
and verification time are independent of the transaction graph.
2. Instead of using Bitcoin transactions for CSV-payments, a Shielded C= SV
payment only requires posting 64 bytes of data to the blockchain (r= egardless
of the CSV-transaction size) and a small constant overhead, signifi= cantly
reducing on-chain cost.

The Shielded CSV protocol is currently defined using Rust-based pseudoc= ode. We
believe that Shielded CSV is both a promising candidate for implementat= ion and
provides an extensible framework for further innovation in the CSV spac= e. We
welcome feedback and look forward to discussing and expanding upon this= work.

[0] htt= ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003714.h= tml
[1] https://l= ists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554.html
[2] https://l= ists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020196.html
[3] https://lists= .linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021679.html


# Abstract

Cryptocurrencies allow mutually distrusting users to transact monetary = value
over the internet without relying on a trusted third party.

Bitcoin, the first cryptocurrency, achieved this through a novel protoc= ol used
to establish consensus about an ordered transaction history. This requi= res every
transaction to be broadcasted and verified by the network, incurring
communication and computational costs. Furthermore, transactions are vi= sible to
all nodes of the network, eroding privacy, and are recorded permanently= ,
contributing to increasing storage requirements over time. To limit res= ource
usage of the network, Bitcoin currently supports an average of 11 trans= actions
per second.

Most cryptocurrencies today still operate in a substantially similar ma= nner.
Private cryptocurrencies like Zcash and Monero address the privacy issu= e by
replacing transactions with proofs of transaction validity. However, th= is
enhanced privacy comes at the cost of increased communication, storage,= and
computational requirements.

Client-Side Validation (CSV) is a paradigm that addresses these issues = by
removing transaction validation from the blockchain consensus rules. Th= is
approach allows sending the coin along with a validity proof directly t= o its
recipient, reducing communication, computation and storage cost. CSV pr= otocols
deployed on Bitcoin today~\cite{rgbblackpaper, taprootassets} do not fu= lly
leverage the paradigm's potential, as they still necessitate the ov= erhead of
publishing ordinary Bitcoin transactions. Moreover, the size of their c= oin
proofs is proportional to the coin's transaction history, and provi= de limited
privacy. A recent improvement is the Intmax2~\cite{rybakken2023intmax2}= CSV
protocol, which writes significantly less data to the blockchain compar= ed to a
blockchain transaction and has succinct coin proofs.

In this work, we introduce Shielded CSV, which improves upon state-of-t= he-art
CSV protocols by providing the first construction that offers truly pri= vate
transactions. It addresses the issues of traditional private cryptocurr= ency
designs by requiring only 64 bytes of data per transaction, called a
\emph{nullifier}, to be written to the blockchain. Moreover, for each n= ullifier
in the blockchain, Shielded CSV users only need to perform a single Sch= norr
signature verification, while non-users can simply ignore this data. Th= e size
and verification cost of coin proofs for Shielded CSV receivers is inde= pendent
of the transaction history. Thus, one application of Shielded CSV is ad= ding
privacy to Bitcoin at a rate of 100 transactions per second, provided t= here is
an adequate bridging mechanism to the blockchain.

We specify Shielded CSV using the Proof Carrying Data (PCD) abstraction= . We then
discuss two implementation strategies that we believe to be practical, = based on
Folding Schemes and Recursive STARKs, respectively. Finally, we propose= future
extensions, demonstrating the power of the PCD abstraction and the exte= nsibility
of Shielded CSV. This highlights the significant potential for further
improvements to the Shielded CSV framework and protocols built upon it.

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