path: root/56/6d1a8e33d45280bb1713b04ead37b5dc0be515

Delivery-date: Thu, 26 Sep 2024 08:07:48 -0700
Received: from mail-yb1-f189.google.com ([209.85.219.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCTP33FZ3YMBBO7R2W3QMGQEZCEZHBA@googlegroups.com>)
	id 1stq5s-0005QL-1N
	for bitcoindev@gnusha.org; Thu, 26 Sep 2024 08:07:48 -0700
Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e25cba4c68esf1622414276.3
        for <bitcoindev@gnusha.org>; Thu, 26 Sep 2024 08:07:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1727363262; x=1727968062; 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=JdSty+uCBotx3bfmMgsngYQlwVBhPzO/jcNLa8XLHy0=;
        b=NGpLcLmXtYMwUF2iai8sByYZT1oLzv1HdZBzvzoWTVpNZWlZsz1G9tItMO2M+y7uTe
         XMnNRXr5o7CEuJ9UfvgGXRsu/GJg420pCiYbEARFKnDHOoJ3fvxvSlVgX8m7BrL+bDxM
         cUD5z7hM41i0HwUn4bJt9ZBXfuZVO77PKUN7BxQKNX7nm59IzbiqIbxE7d6OOYSnI8hu
         193ivqL3xnwZH3D3r3Si7gvnRM38gLz4X6KVVjQzeyXl8XqrDhHZJV3JmDdCjUQkGoov
         9zTdI9jXLF/t0MFGphZ+tkzDfi7jMO7yoTS68uwEsbOLaxY0FuPlQclHnN5iInYd09z4
         WgCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1727363262; x=1727968062; 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=JdSty+uCBotx3bfmMgsngYQlwVBhPzO/jcNLa8XLHy0=;
        b=dYKdzFMHxUEu8RGu1xRy/aU5ZqmvjL73+YoWjE9NpeFReE+Zr+4RMDymnxP8FFczOk
         h4dloAl/esy+ugoLPguff62RthRTIrmX8Vog06XpUr3pIgTrIkt4PWzuZLXMlUdLeMMD
         wVaCcfRFrifNFA/9SITPlLrckqxp/bx6cgTbjLdTzTwTvNR5D9aKs1jfSpnhYHC3cDoQ
         vduzPaqCpIi45qR1e55BjhxmSwhw3n9i9hYk8eH/W2zbqEG3Hr0jR7FQ8WaWvwcdCeho
         OYHx8v5Dq1yECZOUeYsV0A10l8w6ANkSSFXK9AhZirZE4I99OX7owVmReKwkwc7Be7U9
         2yKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1727363262; x=1727968062;
        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=JdSty+uCBotx3bfmMgsngYQlwVBhPzO/jcNLa8XLHy0=;
        b=ayYLzBnd3o5Q6piOIdxSHhiUhlROcnonO+EJLZ8vqBAuI03DQlMEXUhID6EywOUA7B
         Dap/5WRFu9LUCARrC/AFZcWNiRnKRT/U/DFOY+NRgiHsEm8B5X8nZP8Pr/3HocJH5Mzo
         ZQPvZAqJanZZvUkfirK2JWGvv8wqSuis0ygbjI85TXZr5+3sbQok8BmYIFlg00l+e6jJ
         a0Zhd6vanCypKIJDKgLTKBGIuF36NG2LbcQ9nyqrjAhoEPjrhlsjnNuriqn80eMCrpEc
         13cwpndfeybMbjeyPTPn77voFP6Ak6eNtuJEhtBg+/MrDR1yGtVXxj5z8GHpiThZwni7
         7UEA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXnAVwZW/1ULw8p202b6gRAOQA5Zlihz0gqQMYCNVV/y+/5p4SRcKGBB044UNnhErfU1f4ihVgP3GSO@gnusha.org
X-Gm-Message-State: AOJu0YyBM2fkDMRtuZiYIrLVfJbIQPSxLaWt3HqgEGEXAYv33h+FhVyA
	evhQ5OegmUs18/a9dwLZDct6jK/PS4jFZcqqjYV2Q/6WD6J5QLB+
X-Google-Smtp-Source: AGHT+IH6W88Gbh9m8p5F5pJCVB7y2TyyUx0PFC1KJ42+5amepanTP83q2gsrKSBhgzi2oqHlUcY12Q==
X-Received: by 2002:a05:6902:1242:b0:e24:9edb:8e52 with SMTP id 3f1490d57ef6-e24d9dc6497mr4723428276.41.1727363261746;
        Thu, 26 Sep 2024 08:07:41 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:188b:b0:e22:6000:7f32 with SMTP id
 3f1490d57ef6-e25ca7b263bls1239035276.1.-pod-prod-08-us; Thu, 26 Sep 2024
 08:07:39 -0700 (PDT)
X-Received: by 2002:a05:690c:ecf:b0:6e2:1626:fc4a with SMTP id 00721157ae682-6e21d6c605fmr58704567b3.9.1727363259622;
        Thu, 26 Sep 2024 08:07:39 -0700 (PDT)
Received: by 2002:a05:690c:4386:b0:6dd:f386:13dc with SMTP id 00721157ae682-6e21f30dab0ms7b3;
        Thu, 26 Sep 2024 08:02:25 -0700 (PDT)
X-Received: by 2002:a05:690c:39a:b0:69d:e911:88c3 with SMTP id 00721157ae682-6e21d9ead90mr58924087b3.29.1727362944314;
        Thu, 26 Sep 2024 08:02:24 -0700 (PDT)
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"
X-Original-Sender: weikeng.chen@l2iterative.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.7 (/)

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