From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <27a7ee92-8c2b-45ca-9e1c-257a32eb3252n@googlegroups.com> In-Reply-To: <14b8d064-1097-4cc5-a0f4-56bbd4f9417b@gmail.com> References: <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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
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.

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.


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

Thank you for your comments. They are touching on some of the key aspec= ts of the
protocol.

> in this proposed CSV scheme it sounds each nullifier verification= participant
> needs the banwidth cost to read the whole of the blockchain.

You're correct. Shielded CSV nodes need to have access to the curre= nt best
blockchain, similar to regular Bitcoin nodes. Shielded CSV nodes scan f= or
64-byte nullifiers, verify their half-aggregate signatures and place th= em in a
data structure we call "nullifier accumulator".

There's potential for a light client scheme, where users don't = validate blocks,
but infer the best blockchain via proof-of-work (similar to SPV) and ob= tain the
corresponding nullifier accumulator value from somewhere. In addition, = they
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= create
transactions, they need to prove inclusion in the nullifier accumulator= , which
requires knowledge of the nullifiers in the blockchain. There are some = ideas for
how to do this in a relatively light fashion, but nothing concrete yet.= 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 = the
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, re= vealing
the nullifier location implies that outputs of the same transaction are
linkable. We therefore suggest that regular wallets should just create = a single
output.

A fundamental limitation of the Shielded CSV model appears to be that t= he sender
must reveal an upper bound on when the coin has been created ("Thi= s coin is
older than the block at height..."). Otherwise, the receiver would= not know how
long to wait until the coin has sufficient confirmations.

In fact, a previous version of the Shielded CSV protocol did exactly th= at. But
we moved away from that because it was incompatible with our ideas to s= upport
pruning the wallet state (i.e., removing old transaction history), whic= h is an
important aspect in holistic privacy.

We came up with a version of the protocol that supported prunable walle= t state
and only leaked the block in which the coin was created and not the exa= ct
nullifier. However, this version has two drawbacks:
1. The state the wallet needs to keep for the unpruned transaction hist= ory is
larger: 256 bits per received coin (one hash) instead of about 60 b= its (the
blockchain location).
2. The privacy improvement is fuzzy and difficult to understand. In the= extreme
case, such as when there's only one nullifier in the block, the= re's no
improvement over the current Shielded CSV version.

But I agree, if possible without significant drawbacks, this privacy le= ak should
be mitigated.

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