search

purpleprotocol / purple_prototype

Old experiment, not related to the new Purplecoin architecture. Only kept for historical reasons. Please ignore.
GNU General Public License v3.0
89 stars 6 forks source link

Threshold signatures #7

Closed octavonce closed 5 years ago

octavonce commented 5 years ago

Currently, multi-signature functionality in Purple requires different signatures per each signer, effectively making the state storage complexity per transaction O(n). In order to make this O(1), threshold signing must be implemented.

There are three approaches to this: 1) Implement a threshold signing crypto-system for the schnorr variant ed25519, which Purple currently uses. 2) Implement a new signing algorithm using an aggregate non-interactive zero-knowledge proofs protocol. This has the benefits of adding quantum security to the protocol and it keeps the multi-signature process non-interactive. However, this is impossible? 3) Use BLS only for shareholders accounts so that signatures can be aggregated non-interactively. Limiting it only to shareholder accounts doesn't put that much of a strain while performance loss on shareholder accounts will result in higher fees but is a fair price to pay for O(1) storage complexity. This can be further optimized via caching. Multi-sig accounts can then use the ed25519 threshold scheme. However this poses problems for stock transfers since the signers are required to have a BLS address but this can be addressed by requiring accounts to be tied to two addresses (one for authorizing stock transfers and one for other assets).

octavonce commented 5 years ago

We are no longer implementing threshold signatures at the protocol layer as stated in #68