From: Weikeng Chen <weikeng.chen@l2iterative•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Shielded CSV: Private and Efficient Client-Side Validation
Date: Thu, 26 Sep 2024 08:02:24 -0700 (PDT) [thread overview]
Message-ID: <27a7ee92-8c2b-45ca-9e1c-257a32eb3252n@googlegroups.com> (raw)
In-Reply-To: <14b8d064-1097-4cc5-a0f4-56bbd4f9417b@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4090 bytes --]
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 with it, but if we have some upgrades that provide the
necessary programmability (e.g., a full-fledged SNARK verification opcode)
then this protocol can be deployed on Bitcoin in no time, and Bitcoin can
finally have strong privacy.
On Thursday, September 26, 2024 at 5:43:23 PM UTC+3 Jonas Nick wrote:
> Hi Antoine,
>
> Thank you for your comments. They are touching on some of the key aspects
> 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 current best
> blockchain, similar to regular Bitcoin nodes. Shielded CSV nodes scan for
> 64-byte nullifiers, verify their half-aggregate signatures and place them
> 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
> obtain 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,
> revealing
> 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 the
> 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
> know how
> long to wait until the coin has sufficient confirmations.
>
> In fact, a previous version of the Shielded CSV protocol did exactly that.
> But
> we moved away from that because it was incompatible with our ideas to
> support
> pruning the wallet state (i.e., removing old transaction history), which
> is an
> important aspect in holistic privacy.
>
> We came up with a version of the protocol that supported prunable wallet
> 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 history
> is
> larger: 256 bits per received coin (one hash) instead of about 60 bits (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, there's no
> improvement over the current Shielded CSV version.
>
> But I agree, if possible without significant drawbacks, this privacy leak
> should
> be mitigated.
>
--
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 email 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.
[-- Attachment #1.2: Type: text/html, Size: 4727 bytes --]
prev parent reply other threads:[~2024-09-26 15:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 13:24 [bitcoindev] " Jonas Nick
2024-09-25 12:23 ` [bitcoindev] " Antoine Riard
2024-09-26 14:34 ` Jonas Nick
2024-09-26 15:02 ` Weikeng Chen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27a7ee92-8c2b-45ca-9e1c-257a32eb3252n@googlegroups.com \
--to=weikeng.chen@l2iterative$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox