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
The current implementation of the ComputeSSID function can lead to inconsistencies in the length of the generated SSID. This issue arises because the id parameter can have a variable length, resulting in SSIDs of varying lengths. Consequently, this can cause the SSID and ZKSsid lengths to be inconsistent, which has been observed to cause failures in verifying the Pedersen parameter proof during the resharing process.
Additionally, during the Reshare phase, the id used to compute ssid is derived from dkgResult.Bks[selfId].String(), generated during the DKG phase.
Is there any special significance to the current implementation, or can I use padding to address this issue?
The text was updated successfully, but these errors were encountered:
I am working on fixing this issue because I encountered the same error mentioned in a previous issue: #233. To address this, I attempted to resolve the problem by fixing the input string length of ZKSSID, specifically for bks.x.
The current implementation of the ComputeSSID function can lead to inconsistencies in the length of the generated
SSID
. This issue arises because theid
parameter can have a variable length, resulting inSSIDs
of varying lengths. Consequently, this can cause theSSID
and ZKSsid lengths to be inconsistent, which has been observed to cause failures in verifying the Pedersen parameter proof during the resharing process.Additionally, during the Reshare phase, the
id
used to computessid
is derived fromdkgResult.Bks[selfId].String()
, generated during the DKG phase.Is there any special significance to the current implementation, or can I use padding to address this issue?
The text was updated successfully, but these errors were encountered: