Introducing Schnorr crypto mechanics to FairCoin2
A couple of weeks ago I proposed to use the modern, secure and fast signature scheme EC-Schnorr (= Schnorr over elliptic curve) for the PoC (proof-of-cooperation) system of Faircoin2.
Further information about this scheme can be found here:
The current cryptographic signature library used in FairCoin2 is available here: https://github.com/faircoin/faircoin2/tree/schnorr_integration/src/secp256k1
Besides standard ECDSA this software library also contains experimental support for Schnorr based digital signatures. It can not be used as a drop-in replacement for ECDSA in transaction signing. (See previous youtube link) But it is very suitable for the chain signatures required by FairCoin2. EC-Schnorr has the extraordinary property of signature aggregation. This means that we can combine numerous PARTIAL signatures into just ONE. Which is exactly what we need to make chain signing in PoC efficient.
The rework from standard ECDSA to EC-Schnorr was a lot of work but straightforward and I was able to start a Schnorr based blockchain quite fast. Unfortunately, the library mentioned earlier did not include the crucial functionality of verifying partial Schnorr signatures. I had to extend the library and implement this functionality. But this required me to understand ECC (https://en.wikipedia.org/wiki/Elliptic_curve_cryptography). Tenacity and some vague hints from Pieter Wuille (Bitcoin core developer) on IRC helped me to come up with the correct equation for the partial Schnorr signature verification.
Combined Schnorr signatures are created in three steps. First, the participants (in our case the CVNs) create a nonce (= a token) which they communicate to each other. Second, every participant uses all the received nonces and its private key to create their partial signature and send it out to all other nodes. Third, the CVN which creates the next block now combines all these partial signatures from all the CVNs into a single combined signature (which is only 64 bytes) and puts it into its new block.
This procedure is rather sensitive to network outages or a possibly malicious CVN which greatly lowered the benefit of the aggregated signatures. So I started working on optimising this multi-step signature process and came up with the exciting idea to create a nonce pool of 20-30 nonces in advance. Every CVN creates his pool and sends it to the network. This way the first step is greatly simplified and the procedure becomes almost as simple and thus stable as standard ECDSA signature creation.
Currently I'm working on implementing this nonce-pool functionality. Next week I will adopt the PoC system to support the nonce pools. After that I will start a new blockchain and ask all the test CVN operators to compile the new code and join the new blockchain for testing.
Thanks to all for helping, testing and keeping their nodes up!