You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our commitment scheme follows ZeroCash's and truncates the outer commitment to 128 bits.
ZCash considers this as a vulnerability however as an adversary would need to perform only 2^64 operations to find a collision which they argue is feasible nowadays (c.f. https://electriccoin.co/blog/fixing-zcash-vulns/).
I propose in this issue to remove the truncation (and have r_trap of size 256 bits). This changes our security properties from statistical hiding commitment scheme to computationally hiding.
The text was updated successfully, but these errors were encountered:
I propose in this issue to remove the truncation (and have r_trap of size 256 bits). This changes our security properties from statistical hiding commitment scheme to computationally hiding.
What about to implement the zcash commitment scheme? cm=SHA256(0xB0 \| apk \| v \| ρ \| r)
By using Blake of course. I think we already discussed it off-line.
Our commitment scheme follows ZeroCash's and truncates the outer commitment to 128 bits.
ZCash considers this as a vulnerability however as an adversary would need to perform only 2^64 operations to find a collision which they argue is feasible nowadays (c.f. https://electriccoin.co/blog/fixing-zcash-vulns/).
I propose in this issue to remove the truncation (and have r_trap of size 256 bits). This changes our security properties from statistical hiding commitment scheme to computationally hiding.
The text was updated successfully, but these errors were encountered: