Detail the signing process

[mhluongo]

We can link out to the threshold ECDSA yellowpaper, but it's worth describing signing at a high-level.

Bare minimum, we should explain

• [x] Threshold signature schemes
• [x] Threshold ECDSA
• [x] Future threshold-friendly signature schemes

[mhluongo]

A flow diagram would be :fire:

I think we'll be covered here by #39

[mhluongo]

@gakonst I'll take the first draft here and get it to PR- after than can you take it to the finish line?

[gakonst]

Since #39 is now almost done I've started documenting this.

• Signing:
  • BTC: multisig not good enough, can't handle more than 15-of-15 in practice (maybe 20?). Mast/Taproot can potentially bump this, but we don't want to rely on it. Aggregate signatures to the rescue!
  • ETH: Multisig is hard (parity bugs), also more
  • we can also tune the size of the multisig just by changing the selected key
• Threshold ECDSA: Currently bitcoin uses ecdsa, we don't want to wait for schnorr. Quickly describe protocol from https://eprint.iacr.org/2019/114.pdf, https://www.youtube.com/watch?v=PMk2v9hjqEI
• Aborts: Can't do much currently, the Gennaro construction is not fault attributable. Add some information about fault attributable aggregate signatures

Future threshold/aggregation friendly:

• Schnorr: Once in Bitcoin, we can implement it. Verify on Ethereum with https://github.com/HarryR/solcrypto/blob/master/contracts/Schnorr.sol.
• BLS: The holy grail. Unlikely to get in bitcoin soon (although I recall Pieter Wuille in a discussion in SBC saying that he'd really like it), it's good because it's non-interactive and simpler protocol (you just do the pairing - novel crypto though). You already have a verifier: https://github.com/keep-network/keep-core/blob/master/contracts/solidity/contracts/cryptography/BLS.sol, and a lot of context in http://docs.keep.network/random-beacon/index.pdf
• https://eprint.iacr.org/2019/514 also forward secure (can solve long range attacks for PoS systems, of independent interest)

[mhluongo]

BTC multisig not good enough, can't handle more than 15-of-15 in practice

We also get the benefit of much simpler validation from the EVM and forwards compatibility- eg we can increase the number of signers as tech improves in future upgrades without it making a difference on the BTC side, growing tx sizes, etc

[gakonst]

Update, I'm almost done with this, just re-reading the fast tecdsa with fast trustless setup paper to make sure the summary is accurate.

[gakonst]

Closing since #238 is merged.