feat: add extended range proofs #102
Conversation
| Ok(proof.to_bytes()) | ||
| } | ||
|
|
||
| fn verify_batch_and_recover_masks( |
There was a problem hiding this comment.
A user is either verifying or recovering. Verifying is implicit in the action, so it's not needed in the name. Adding it in the name makes it seem like verifying is the main action here, when it is actually recovering
| fn verify_batch_and_recover_masks( | |
| fn batch_recover_masks( |
There was a problem hiding this comment.
Batch recovery of masks is more expensive than linear mask recovery for the same amount of proofs, so that is not promoted. The primary action here is batch verification (logarithmic), with the additional benefit to recover masks at a linear cost. I will update the documentation to reflect this.
| proof: &Self::Proof, | ||
| statement: &RistrettoExtendedStatement, | ||
| ) -> Result<Option<RistrettoExtendedMask>, RangeProofError> { | ||
| return match RistrettoRangeProof::from_bytes(proof) |
There was a problem hiding this comment.
Can't you just call verify_batch_and_recover(vec![proof], vec![statement])
There was a problem hiding this comment.
See above comment: Batch recovery of masks is more expensive than linear mask recovery for the same amount of proofs... Also, as a proof + commitment owner, we do not always want to verify the proof, in which case we can just call recover_mask followed by verify_mask, both really cheap operations.
| }; | ||
| } | ||
|
|
||
| fn verify_mask( |
There was a problem hiding this comment.
Perhaps the commitment factory is a better place for this?
There was a problem hiding this comment.
The extended commitment factory can verify an extended commitment's opening, but is agnostic to mask verification, which is the primary action here.
I have added a specific test after mask recovery to also verify that the extended commitment factory can open the commitment.
hansieodendaal
force-pushed
the
ho_extended_range_proofs
branch
from
410c776 to
23a0b34
Compare
Added extended range proofs