Protocol: Double Blinded Pedersen Commitments

[nopara73]

Caution. I don't know if there is crypto for this, but I strongly suspect there is and conceptually it could be the ideal scheme we are looking for.

Amount Splitting

User has UTXO with value v and want to split them into outputs with values v1 and v2 such that v = v1 + v2.

Input Registration

User creates n double blinded Pedersen Commitments: C(v1, r10, r11), C(v2, r20, r21), C(v3, r30, r31), C(v4, r40, r41), ... C(vn, rn0, rn1) where v3, v4, ... vn equal to 0.

User also creates a Pedersen commitment for their sums: C(v1+v2+...vn, r10+r20...+rn0, r11+r21+...+rn1).

User tells the coordinator the double blinded Pedersen commitments, the commitment to their sums, v1+v2+...vn, r10+r20...+rn0 and r11+r21+...+rn1 and rangeproofs, preferably Bulletproofs.

The coordinator signs the double blinded commitments one by one and the user unblinds these signatures such that they are valid for the single blinded commitments: C(v1, r10), C(v2, r20),... C(vn, rn0).

Output Registration

User can register a desired output for v1 by sending the coordinator C(v1, r10), some 0 commitments, but for simplicity let's say it only sends C(v3, r30), valid signatures for those commitments and their sums: v1 + v3 = v3, r10 + r30.

Amount Merging

The protocol is the same, except instead of only registering signed zero commitments at output registration, some of those commitments aren't zero, but maybe they were coming from different inputs.

Unlinkability

Since the coordinator cannot recognize the unblinded signatures at output registration, it can only tell they are valid, unlinkability is guaranteed.

Double Spend

Since the unblinded signatures are valid for single blinded commitments only, the coordinator can make sure one signature can only be used once.

[nothingmuch]

mostly nitpicking:

at input registration, multiple rangeproofs are needed, one for each v, but i think these can be batched together into a single bulletproof, but i think it's clearer to think of them as separate range proofs

why is a range proof required at output registration? why does the sum need to be a commitment? the total amount will be known anyway so it might as well be a public parameter, the coordinator just needs the combined randomness to ensure that the combined commitment opens to this value incorrect, but see this comment

are the two separate r values per commitment meant to represent the double blinding? in this case i think that's algebraicly the same as just having one r value and that it's not actually required for what is described here (but some sort of double blinding scheme is probably needed for the signature algorithm to work out)

edit: that's not correct, the double blinding described in the Lelantus paper uses a different generator for the 2nd blinding term

[nopara73]

I fixed your first two suggestions. Not sure I can say anything about your 3rd suggestion, as I'm not even sure the second random should be another r value or something other magic blinding factor. Anyway, yes, I indexed the r values instead of going one by one on the numbers.

[nothingmuch]

i think the key improvement compared to #10 is that signatures are on the commitments instead of the values themselves.

i arrived at essentially same approach by necessity in trying to work out how #10 can be realized using ACL signature scheme (where the amount is an attribute on the credential), so i think this all makes sense

[nopara73]

There are 3 key cryptographic questions to settle here:

1. What is a Double Blinded Pedersen commitment construction I assume to be our basic building block? Is it another r value or some other crypto magic needed there?
2. Can we have rangeproofs, preferably Bulletproofs on the double blinded commitments?
3. Can we acquire blind signatures on the double blinded commitments such that the unblinded signatures are valid for the corresponding single blinded commitments?

[nopara73]

i think the key improvement compared to #10 is that signatures are on the commitments instead of the values themselves.

Yes, this is the major insight, let's keep this in mind.

[nopara73]

Closing in favor of https://github.com/zkSNACKs/WabiSabi/issues/16