diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2024-09-25 05:23:56 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-09-25 05:45:09 -0700 |
| commit | ce72170c337f3e2b15b824e378f1b18090c78d4f (patch) | |
| tree | 71aedb1356c8ce59432778d5d3935a0691cacdd9 | |
| parent | 90dd6efba6e4949b1ac34df86a3528f55d7d2efa (diff) | |
| download | pi-bitcoindev-ce72170c337f3e2b15b824e378f1b18090c78d4f.tar.gz pi-bitcoindev-ce72170c337f3e2b15b824e378f1b18090c78d4f.zip | |
[bitcoindev] Re: Shielded CSV: Private and Efficient Client-Side Validation
| -rw-r--r-- | d1/60147d94d727e1744edebf9a3c9f22105be043 | 545 |
1 files changed, 545 insertions, 0 deletions
diff --git a/d1/60147d94d727e1744edebf9a3c9f22105be043 b/d1/60147d94d727e1744edebf9a3c9f22105be043 new file mode 100644 index 000000000..c6b71d7fd --- /dev/null +++ b/d1/60147d94d727e1744edebf9a3c9f22105be043 @@ -0,0 +1,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&q=3Dhttps://github.com/Shie= +ldedCSV/ShieldedCSV/releases/latest/download/shieldedcsv.pdf&source=3Dg= +mail&ust=3D1727353229769000&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 "Proof-Carrying Data" ab= +straction, which +<br> can be instantiated via recursive zkSNARKs or folding schemes. This= + provides +<br> "full" 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&q=3Dhttps://lists.linuxfo= +undation.org/pipermail/bitcoin-dev/2013-November/003714.html&source=3Dg= +mail&ust=3D1727353229769000&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&q=3Dhttps://lists.linuxfound= +ation.org/pipermail/bitcoin-dev/2023-April/021554.html&source=3Dgmail&a= +mp;ust=3D1727353229769000&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&q=3Dhttps://lists.linuxfound= +ation.org/pipermail/bitcoin-dev/2022-April/020196.html&source=3Dgmail&a= +mp;ust=3D1727353229769000&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&q=3Dhttps://lists.linuxfoundat= +ion.org/pipermail/bitcoin-dev/2023-May/021679.html&source=3Dgmail&u= +st=3D1727353229769000&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'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'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" 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-- + |