Delivery-date: Thu, 26 Sep 2024 08:07:48 -0700
Sender: bitcoindev@googlegroups.com
Date: Thu, 26 Sep 2024 08:02:24 -0700 (PDT)
From: Weikeng Chen <weikeng.chen@l2iterative.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <27a7ee92-8c2b-45ca-9e1c-257a32eb3252n@googlegroups.com>
In-Reply-To: <14b8d064-1097-4cc5-a0f4-56bbd4f9417b@gmail.com>
References: <b0afc5f2-4dcc-469d-b952-03eeac6e7d1b@gmail.com>
 <33cd30ab-c5c2-4785-9815-4a2da3c7e267n@googlegroups.com>
 <14b8d064-1097-4cc5-a0f4-56bbd4f9417b@gmail.com>
Subject: Re: [bitcoindev] Re: Shielded CSV: Private and Efficient Client-Side Validation
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_55330_171915413.1727362944033"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_55330_171915413.1727362944033
Content-Type: multipart/alternative; 
	boundary="----=_Part_55331_185842420.1727362944033"

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


I think the main challenge for the protocol is bridging, as the paper=20
mentions in Page 4, because without which it might appear that we are just=
=20
using Bitcoin for data availability.

BitVM can help with it, but if we have some upgrades that provide the=20
necessary programmability (e.g., a full-fledged SNARK verification opcode)=
=20
then this protocol can be deployed on Bitcoin in no time, and Bitcoin can=
=20
finally have strong privacy.


On Thursday, September 26, 2024 at 5:43:23=E2=80=AFPM UTC+3 Jonas Nick wrot=
e:

> Hi Antoine,
>
> Thank you for your comments. They are touching on some of the key aspects=
=20
> of the
> protocol.
>
> > in this proposed CSV scheme it sounds each nullifier verification=20
> participant
> > needs the banwidth cost to read the whole of the blockchain.
>
> You're correct. Shielded CSV nodes need to have access to the current bes=
t
> blockchain, similar to regular Bitcoin nodes. Shielded CSV nodes scan for
> 64-byte nullifiers, verify their half-aggregate signatures and place them=
=20
> in a
> data structure we call "nullifier accumulator".
>
> There's potential for a light client scheme, where users don't validate=
=20
> blocks,
> but infer the best blockchain via proof-of-work (similar to SPV) and=20
> obtain the
> corresponding nullifier accumulator value from somewhere. In addition, th=
ey
> receive a succinct proof that the blockchain is valid and the nullifier
> accumulator value is correct.
>
> This model allows the light client to receive transactions. However, to=
=20
> create
> transactions, they need to prove inclusion in the nullifier accumulator,=
=20
> which
> requires knowledge of the nullifiers in the blockchain. There are some=20
> ideas for
> how to do this in a relatively light fashion, but nothing concrete yet.=
=20
> It's
> certainly an interesting area for further exploration.
>
> > there could be a way to hide the coin creation time
>
> A coin (the data sent to the recipient) contains the exact location of th=
e
> nullifier that created the coin. This is indeed a noteworthy issue and we
> discuss the implications in section 6.3 of the paper. In particular,=20
> revealing
> the nullifier location implies that outputs of the same transaction are
> linkable. We therefore suggest that regular wallets should just create a=
=20
> single
> output.
>
> A fundamental limitation of the Shielded CSV model appears to be that the=
=20
> sender
> must reveal an upper bound on when the coin has been created ("This coin =
is
> older than the block at height..."). Otherwise, the receiver would not=20
> know how
> long to wait until the coin has sufficient confirmations.
>
> In fact, a previous version of the Shielded CSV protocol did exactly that=
.=20
> But
> we moved away from that because it was incompatible with our ideas to=20
> support
> pruning the wallet state (i.e., removing old transaction history), which=
=20
> is an
> important aspect in holistic privacy.
>
> We came up with a version of the protocol that supported prunable wallet=
=20
> state
> and only leaked the block in which the coin was created and not the exact
> nullifier. However, this version has two drawbacks:
> 1. The state the wallet needs to keep for the unpruned transaction histor=
y=20
> is
> larger: 256 bits per received coin (one hash) instead of about 60 bits (t=
he
> blockchain location).
> 2. The privacy improvement is fuzzy and difficult to understand. In the=
=20
> extreme
> case, such as when there's only one nullifier in the block, there's no
> improvement over the current Shielded CSV version.
>
> But I agree, if possible without significant drawbacks, this privacy leak=
=20
> should
> be mitigated.
>

--=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/27a7ee92-8c2b-45ca-9e1c-257a32eb3252n%40googlegroups.com.

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

<br />I think the main challenge for the protocol is bridging, as the paper=
 mentions in Page 4, because without which it might appear that we are just=
 using Bitcoin for data availability.<div><br /></div><div>BitVM can help w=
ith it, but if we have some upgrades that provide the necessary programmabi=
lity (e.g., a full-fledged SNARK verification opcode) then this protocol ca=
n be deployed on Bitcoin in no time, and Bitcoin can finally have strong pr=
ivacy.</div><div><div><br /></div><div><br /></div></div><div class=3D"gmai=
l_quote"><div dir=3D"auto" class=3D"gmail_attr">On Thursday, September 26, =
2024 at 5:43:23=E2=80=AFPM UTC+3 Jonas Nick wrote:<br/></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rg=
b(204, 204, 204); padding-left: 1ex;">Hi Antoine,
<br>
<br>Thank you for your comments. They are touching on some of the key aspec=
ts of the
<br>protocol.
<br>
<br> &gt; in this proposed CSV scheme it sounds each nullifier verification=
 participant
<br> &gt; needs the banwidth cost to read the whole of the blockchain.
<br>
<br>You&#39;re correct. Shielded CSV nodes need to have access to the curre=
nt best
<br>blockchain, similar to regular Bitcoin nodes. Shielded CSV nodes scan f=
or
<br>64-byte nullifiers, verify their half-aggregate signatures and place th=
em in a
<br>data structure we call &quot;nullifier accumulator&quot;.
<br>
<br>There&#39;s potential for a light client scheme, where users don&#39;t =
validate blocks,
<br>but infer the best blockchain via proof-of-work (similar to SPV) and ob=
tain the
<br>corresponding nullifier accumulator value from somewhere. In addition, =
they
<br>receive a succinct proof that the blockchain is valid and the nullifier
<br>accumulator value is correct.
<br>
<br>This model allows the light client to receive transactions. However, to=
 create
<br>transactions, they need to prove inclusion in the nullifier accumulator=
, which
<br>requires knowledge of the nullifiers in the blockchain. There are some =
ideas for
<br>how to do this in a relatively light fashion, but nothing concrete yet.=
 It&#39;s
<br>certainly an interesting area for further exploration.
<br>
<br> &gt; there could be a way to hide the coin creation time
<br>
<br>A coin (the data sent to the recipient) contains the exact location of =
the
<br>nullifier that created the coin. This is indeed a noteworthy issue and =
we
<br>discuss the implications in section 6.3 of the paper. In particular, re=
vealing
<br>the nullifier location implies that outputs of the same transaction are
<br>linkable. We therefore suggest that regular wallets should just create =
a single
<br>output.
<br>
<br>A fundamental limitation of the Shielded CSV model appears to be that t=
he sender
<br>must reveal an upper bound on when the coin has been created (&quot;Thi=
s coin is
<br>older than the block at height...&quot;). Otherwise, the receiver would=
 not know how
<br>long to wait until the coin has sufficient confirmations.
<br>
<br>In fact, a previous version of the Shielded CSV protocol did exactly th=
at. But
<br>we moved away from that because it was incompatible with our ideas to s=
upport
<br>pruning the wallet state (i.e., removing old transaction history), whic=
h is an
<br>important aspect in holistic privacy.
<br>
<br>We came up with a version of the protocol that supported prunable walle=
t state
<br>and only leaked the block in which the coin was created and not the exa=
ct
<br>nullifier. However, this version has two drawbacks:
<br>1. The state the wallet needs to keep for the unpruned transaction hist=
ory is
<br>    larger: 256 bits per received coin (one hash) instead of about 60 b=
its (the
<br>    blockchain location).
<br>2. The privacy improvement is fuzzy and difficult to understand. In the=
 extreme
<br>    case, such as when there&#39;s only one nullifier in the block, the=
re&#39;s no
<br>    improvement over the current Shielded CSV version.
<br>
<br>But I agree, if possible without significant drawbacks, this privacy le=
ak should
<br>be mitigated.
<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/27a7ee92-8c2b-45ca-9e1c-257a32eb3252n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/27a7ee92-8c2b-45ca-9e1c-257a32eb3252n%40googlegroups.com</a>.=
<br />

------=_Part_55331_185842420.1727362944033--

------=_Part_55330_171915413.1727362944033--