Dedicated library for intending and evaluating cosigns

Not only cleans the existing cosign code but enables non-Serai-coordinators to
evaluate cosigns if they gain access to a feed of them (such as over an RPC).
This would let centralized services not only track the finalized chain yet the
cosigned chain without directly running a coordinator.

Still being wrapped up.

coordinator/cosign/README.md

@@ -0,0 +1,121 @@
+# Serai Cosign
+
+The Serai blockchain is controlled by a set of validators referred to as the
+Serai validators. These validators could attempt to double-spend, even if every
+node on the network is a full node, via equivocating.
+
+Posit:
+  - The Serai validators control X SRI
+  - The Serai validators produce block A swapping X SRI to Y XYZ
+  - The Serai validators produce block B swapping X SRI to Z ABC
+  - The Serai validators finalize block A and send to the validators for XYZ
+  - The Serai validators finalize block B and send to the validators for ABC
+
+This is solved via the cosigning protocol. The validators for XYZ and the
+validators for ABC each sign their view of the Serai blockchain, communicating
+amongst each other to ensure consistency.
+
+The security of the cosigning protocol is not formally proven, and there are no
+claims it achieves Byzantine Fault Tolerance. This protocol is meant to be
+practical and make such attacks infeasible, when they could already be argued
+difficult to perform.
+
+### Definitions
+
+- Cosign: A signature from a non-Serai validator set for a Serai block
+- Cosign Commit: A collection of cosigns which achieve the necessary weight
+
+### Methodology
+
+Finalized blocks from the Serai network are intended to be cosigned if they
+contain burn events. Only once cosigned should non-Serai validators process
+them.
+
+Cosigning occurs by a non-Serai validator set, using their threshold keys
+declared on the Serai blockchain. Once 83% of non-Serai validator sets, by
+weight, cosign a block, a cosign commit is formed. A cosign commit for a block
+is considered to also cosign for all blocks preceding it.
+
+### Bounds Under Asynchrony
+
+Assuming an asynchronous environment fully controlled by the adversary, 34% of
+a validator set may cause an equivocation. Control of 67% of non-Serai
+validator sets, by weight, is sufficient to produce two distinct cosign commits
+at the same position. This is due to the honest stake, 33%, being split across
+the two candidates (67% + 16.5% = 83.5%, just over the threshold). This means
+the cosigning protocol may produce multiple cosign commits if 34% of 67%, just
+22.78%, of the non-Serai validator sets, is malicious. This would be in
+conjunction with 34% of the Serai validator set (assumed 20% of total stake),
+for a total stake requirement of 34% of 20% + 22.78% of 80% (25.024%). This is
+an increase from the 6.8% required without the cosigning protocol.
+
+### Bounds Under Synchrony
+
+Assuming the honest stake within the non-Serai validator sets detect the
+malicious stake within their set prior to assisting in producing a cosign for
+their set, for which there is a multi-second window, 67% of 67% of non-Serai
+validator sets is required to produce cosigns for those sets. This raises the
+total stake requirement to 42.712% (past the usual 34% threshold).
+
+### Behavior Reliant on Synchrony
+
+If the Serai blockchain node detects an equivocation, it will stop responding
+to all RPC requests and stop participating in finalizing further blocks. This
+lets the node communicate the equivocating commits to other nodes (causing them
+to exhibit the same behavior), yet prevents interaction with it.
+
+If cosigns representing 17% of the non-Serai validators sets by weight are
+detected for distinct blocks at the same position, the protocol halts. An
+explicit latency period of five seconds is enacted after receiving a cosign
+commit for the detection of such an equivocation. This is largely redundant
+given how the Serai blockchain node will presumably have halted itself by this
+time.
+
+### Equivocation-Detection Avoidance
+
+Malicious Serai validators could avoid detection of their equivocating if they
+produced two distinct blockchains, A and B, with different keys declared for
+the same non-Serai validator set. While the validators following A may detect
+the cosigns for distinct blocks by validators following B, the cosigns would be
+assumed invalid due to their signatures being verified against distinct keys.
+
+This is prevented by requiring cosigns on the blocks which declare new keys,
+ensuring all validators have a consistent view of the keys used within the
+cosigning protocol (per the bounds of the cosigning protocol). These blocks are
+exempt from the general policy of cosign commits cosigning all prior blocks,
+preventing the newly declared keys (which aren't yet cosigned) from being used
+to cosign themselves. These cosigns are flagged as "notable", are permanently
+archived, and must be synced before a validator will move forward.
+
+Cosigning the block which declares new keys also ensures agreement on the
+preceding block which declared the new set, with an exact specification of the
+participants and their weight, before it impacts the cosigning protocol.
+
+### Denial of Service Concerns
+
+Any historical Serai validator set may trigger a chain halt by producing an
+equivocation after their retiry. This requires 67% to be malicious. 34% of the
+active Serai validator set may also trigger a chain halt.
+
+17% of non-Serai validator sets equivocating causing a halt means 5.67% of
+non-Serai validator sets' stake may cause a halt (in an asynchronous
+environment fully controlled by the adversary). In a synchronous environment
+where the honest stake cannot be split across two candidates, 11.33% of
+non-Serai validator sets' stake is required.
+
+The more practical attack is for one to obtain 5.67% of non-Serai validator
+sets' stake, under any network conditions, and simply go offline. This will
+take 17% of validator sets offline with it, preventing any cosign commits
+from being performed. A fallback protocol where validators individually produce
+cosigns, removing the network's horizontal scalability but ensuring liveness,
+prevents this, restoring the additional requirements for control of an
+asynchronous network or 11.33% of non-Serai validator sets' stake.
+
+### TODO
+
+The Serai node no longer responding to RPC requests upon detecting any
+equivocation, and the fallback protocol where validators individually produce
+signatures, are not implemented at this time. The former means the detection of
+equivocating cosigns not redundant and the latter makes 5.67% of non-Serai
+validator sets' stake the DoS threshold, even without control of an
+asynchronous network.