I don’t understand how this is possible. The user knows the commitment, they can exit the system at any time and since the system is private it’s not possible to distinguish between slashing a cheater and a cheater slashing themselves to avoid punishment. Because of this anonymity, adding delays is not useful either.
Provider set size is bounded by the deposit amount. Users could recycle their deposit for bigger ones that include more providers. Multiple deposits are not needed AFAIU. They would have to pay extra TX cost that is true.
The FMT only reveal winning tickets, nullpayments don’t require blockchain access.
I disagree. The problem is the timing. RLN blockchain access is required just before every tickets sent by the user, where as the DAM scheme the TX to create deposits can be done at any time prior to sending many tickets. One is much more “Offline” than the other.
This is a good point. The malicious user cannot prevent at least one ticket being redeemed by frontrunning (since we don’t use the deposit for ticket payments), but they could try to frontrun double spend detection and subsequent slashing.
I’ll need to think about this more, but on the surface this seems less likely for RLN than for the DAM scheme: with RLN it should be possible to detect double spending even on null payment tickets, making it more risky. As soon as a commitment is slashed, either by the malicious user or anyone else in the system, there can be no more utility against that membership from the next epoch onwards. With a per-epoch rate limit it seems unlikely that a malicious user would therefore get much utility when trying to frontrun a double spend detection and the risk of slashing would be large enough IMO to mitigate this effectively.
This is true for the FMT, but afaiu the deposit (and other vectors in π_pt) need to be verified for each ticket and therefore don’t form part of the FMT ciphertext. This is how I read 7.1.2., though I’ll dig a bit deeper tomorrow.
In fact, the user needs to include a proof
that d’s serial number has not appeared
on the ledger prior to the current epoch (that is, d was not revoked or withdrawn in prior epochs)
You mentioned this in your Notion summary of the scheme as well, but I haven’t previously questioned where this information comes from. For me it sounds like a non-inclusion proof based on on-chain information (i.e. consensus on a Merkle tree of revoked deposits) and that this needs to be synced by both user and provider up to the previous epoch?
Yes I agree, in that case there’s no slashing even needed. Detecting rate-limit violation is enough to refuse service but we have to be careful about the “cons”, the DAM scheme has a very simple rate limit mechanism that works well “enough” but again maybe RLN could allow stronger guaranties.
In any case, it would not replace the double spend protection in the DAM. AFAIU it’s a separate mechanism. The rate limiting only exist to bound the extra utility so that the double spend slashing is effective.
Ah I see what you mean! AFAIU both sets are sent by the provider on first interaction and proofs created against those. One set is local to the provider (for this epoch) the other is the onchain one (all previous epoch).