Delivery-date: Thu, 26 Sep 2024 07:43:29 -0700
Received-SPF: pass (google.com: domain of jonasd.nick@gmail.com designates 2a00:1450:4864:20::436 as permitted sender) client-ip=2a00:1450:4864:20::436;
Sender: Jonas Nick <jonasdnick@gmail.com>
Message-ID: <14b8d064-1097-4cc5-a0f4-56bbd4f9417b@gmail.com>
Date: Thu, 26 Sep 2024 14:34:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [bitcoindev] Re: Shielded CSV: Private and Efficient Client-Side Validation
To: bitcoindev@googlegroups.com
References: <b0afc5f2-4dcc-469d-b952-03eeac6e7d1b@gmail.com>
 <33cd30ab-c5c2-4785-9815-4a2da3c7e267n@googlegroups.com>
Content-Language: en-US
From: Jonas Nick <jonasd.nick@gmail.com>
In-Reply-To: <33cd30ab-c5c2-4785-9815-4a2da3c7e267n@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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/14b8d064-1097-4cc5-a0f4-56bbd4f9417b%40gmail.com.