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
{{ message }}
This repository has been archived by the owner on May 8, 2020. It is now read-only.
The current cosi draft briefly mentions a couple open issues for discussion in section 9 toward the end of the document, but this list of discussion points needs to be (a) much more prominent, e.g., perhaps near the top of the document, and/or with individual discussion-point markers sprinkled throughout the document at appropriate places, and (b) significantly longer. Additional topics to be discussed include:
Consider whether the scheme should tolerate cosigners failing between the "challenge" and "response" phases without requiring restart from scratch. This would be another nice-to-have robustness refinement, at the cost of added complexity. See section IV.D of our CoSi paper.
In the current, simple scheme, the verifier must have a complete list of the public keys of the members of a collective signing group, in order to adjust the verification to the particular set of members that actually signed according to the bitmask. For large collective signing groups, this public key list could get large and hence be a storage burden for verifiers. An alternative is to assume the verifiers only know the root hash of a Merkle tree of public keys, at the cost that actual signatures would need to be variable-size and include Merkle inclusion-proofs of the public keys of missing cosigners. See section IV.B of our CoSi paper.
Finally, probably as more of a long-term roadmap item, it would be worth considering similar collective signing schemes based on other cryptosystems, e.g., BLS instead of Schnoor. BLS in particular is attractive because it supports collective signing in just one phase rather than two, eliminates the restart issue above when cosigners disappear between the challenge and response phases, and potentially supports completely organic, asynchronous aggregation of partial signatures in gossip fashion, which maybe particularly attractive to Bitcoin-type systems in which most communication happens via a peer-to-peer gossip network. But since BLS is pairing-based, we probably need to standardized pairing-based curves before we can realistically standardize BLS signing. Still, important to keep on the horizon. For further details see section IV.E of our CoSi paper.
The text was updated successfully, but these errors were encountered:
The current cosi draft briefly mentions a couple open issues for discussion in section 9 toward the end of the document, but this list of discussion points needs to be (a) much more prominent, e.g., perhaps near the top of the document, and/or with individual discussion-point markers sprinkled throughout the document at appropriate places, and (b) significantly longer. Additional topics to be discussed include:
Potentially adding a delinearization mechanism of some kind to increase robustness to related-key attacks (see cosi: consider delinearization schemes to increase robustness to related-key attacks #1)
Consider whether the scheme should tolerate cosigners failing between the "challenge" and "response" phases without requiring restart from scratch. This would be another nice-to-have robustness refinement, at the cost of added complexity. See section IV.D of our CoSi paper.
In the current, simple scheme, the verifier must have a complete list of the public keys of the members of a collective signing group, in order to adjust the verification to the particular set of members that actually signed according to the bitmask. For large collective signing groups, this public key list could get large and hence be a storage burden for verifiers. An alternative is to assume the verifiers only know the root hash of a Merkle tree of public keys, at the cost that actual signatures would need to be variable-size and include Merkle inclusion-proofs of the public keys of missing cosigners. See section IV.B of our CoSi paper.
Finally, probably as more of a long-term roadmap item, it would be worth considering similar collective signing schemes based on other cryptosystems, e.g., BLS instead of Schnoor. BLS in particular is attractive because it supports collective signing in just one phase rather than two, eliminates the restart issue above when cosigners disappear between the challenge and response phases, and potentially supports completely organic, asynchronous aggregation of partial signatures in gossip fashion, which maybe particularly attractive to Bitcoin-type systems in which most communication happens via a peer-to-peer gossip network. But since BLS is pairing-based, we probably need to standardized pairing-based curves before we can realistically standardize BLS signing. Still, important to keep on the horizon. For further details see section IV.E of our CoSi paper.
The text was updated successfully, but these errors were encountered: