Vote stapling

[PlasmaPower]

Simple explanation:
With vote stapling, when a node publishes a block, it will first communicate directly with representatives to make an aggregate signature. Then, the node will publish the block along with the aggregate signature in the same message. The aggregate signature is the same size as a normal signature, because it uses a multisignature protocol called MuSig: https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures.html. This means that we can package up the entire voting process into the size of one vote.

Protocol explanation (knowledge of the MuSig protocol in the link above is required):

1. musig_stage0_req: The block publisher sends a packet to top representatives containing the block it wants to publish, the rep it's looking for (or the burn address if it's blindly broadcasting), and a signature of that info with its node ID.
2. musig_stage0_res: The representative responds with an R value for this session (referred to as rB in the code to prevent confusion with r), a request ID equal to the representative address xor the block hash, and a signature of that info as the representative.
3. musig_stage1_req: Once the block publisher has received enough stage0 responses such that the vote weight totals at least 70% of the online stake, it will send a stage1 request containing the total R value, a hash of the public keys I'm calling l_base (in this scheme each participant's public key is H(H(pk[0] || pk[1] || ... || pk[n]) || pk[i]), and the inner hash is l_base), and a signature of that info with its node id.
4. musig_stage1_res: The representative responds with an s value computed from that information and its r value. It deletes the stage0 info, but it caches the s value for a bit so that repeat requests can still get the s value.
5. publish_vote_staple: The block publisher broadcasts the block, the signature, and the xor of all of the representatives used for signature (this is limited to the top 127 reps, so linear algebra is used to reverse the process and discover which representatives are in the signature). Other nodes check if the reps have quorum, and if the signature matches. If it checks out, the node processes the block, then rebroadcasts the packet.

TODO:

• Write up a description of what this actually is
• Fix node.send_single_many_peers (initialization fails)
• Fix sporadic node.auto_bootstrap failure (may not be related to vote stapling, not sure) seems unrelated
• Add tests specific to vote stapling (maybe some more, though this seems good)
• Cleanup old stuff in vote_stapler and vote_staple_requester
• Add additional validation before signing something (a bit of active graph?)
• When increasing publish PoW, change how rebroadcast_info works to stick with vote stapling even if weight is low
• Implement automatic rep blacklisting in case of bad behavior
• Change RPC publish to use vote stapling when possible
• Maybe support many to many request id to block hash mappings
• Wallet queueing probably needs fixing with this: immediate process should fix this
• Maybe prevent precomputing
• Either add timestamps or store stapled votes in DB

[cryptocode]

Maybe add msvc compatibility to the PR's TODO list ? Possibly a compiler specific macro that does __builtin_popcount (gcc) or __popcnt (msvc) with an LSB mask.

[cryptocode]

Due to the max_peers_per_ip reduction it seems

[PlasmaPower]

Oh, nice catch. Thank you very much. I was wondering how that happened.

[rkeene]

I'm moving this to V19 (V18 is still intended to be cleanup) since it will likely not be ready to merge in time for V17 and we don't want to rush the work on such a large change.

[PlasmaPower]

Some weaknesses have been found in the 2 round MuSig, so we'd definitely need to implement this with the 3 round MuSig or a pairing based multisignature scheme. I'm closing this PR because it's very out of date now, and a future implementation would probably need to be separate.