Replace "coin" with "network"

The Processor's coins folder referred to the networks it could process, as did
its Coin trait. This, and other similar cases throughout the codebase, have now
been corrected.

Also corrects dated documentation for a key pair is confirmed under the
validator-sets pallet.

docs/integrations/Instructions.md

@@ -8,7 +8,7 @@ encoded into transactions on connected networks. Serai will parse included
 instructions when it receives coins, executing the included specs.
 
   - Out Instructions detail how to transfer coins, either to a Serai address or
-an address native to the coin in question.
+an address native to the network of the coins in question.
 
 A transaction containing an In Instruction and an Out Instruction (to a native
 address) will receive coins to Serai and send coins from Serai, without

docs/protocol/Constants.md

@@ -15,6 +15,7 @@ protocol.
 | Session         | u32                                          |
 | Validator Set   | (Session, NetworkId)                         |
 | Key             | BoundedVec\<u8, 96>                          |
+| KeyPair         | (SeraiAddress, Key)                          |
 | ExternalAddress | BoundedVec\<u8, 128>                         |
 | Data            | BoundedVec\<u8, 512>                         |
 

docs/protocol/Validator Sets.md

@@ -30,19 +30,16 @@ reject newly added coins which would cross that threshold.
 Multisigs are created by processors, communicating via their Coordinators.
 They're then confirmed on chain via the `validator-sets` pallet. This is done by
 having 100% of participants agree on the resulting group key. While this isn't
-fault tolerant, a malicious actor who forces a `t`-of-`n` multisig to be
-`t`-of-`n-1` reduces the fault tolerance of the multisig which is a greater
-issue. If a node does prevent multisig creation, other validators should issue
-slashes for it/remove it from the Validator Set entirely.
+fault tolerant regarding liveliness, a malicious actor who forces a `t`-of-`n`
+multisig to be `t`-of-`n-1` reduces the fault tolerance of the created multisig
+which is a greater issue. If a node does prevent multisig creation, other
+validators should issue slashes for it/remove it from the Validator Set
+entirely.
 
-Due to the fact multiple key generations may occur to account for
-faulty/malicious nodes, voting on multiple keys for a single coin is allowed,
-with the first key to be confirmed becoming the key for that coin.
-
-Placing it on chain also solves the question of if the multisig was successfully
-created or not. Processors cannot simply ask each other if they succeeded
-without creating an instance of the Byzantine Generals Problem. Placing results
-within a Byzantine Fault Tolerant system resolves this.
+Placing the creation on chain also solves the question of if the multisig was
+successfully created or not. Processors cannot simply ask each other if they
+succeeded without creating an instance of the Byzantine Generals Problem.
+Placing results within a Byzantine Fault Tolerant system resolves this.
 
 ### Multisig Lifetime
 
@@ -61,9 +58,11 @@ no longer eligible to receive coins and they forward all of their coins to the
 new set of keys. It is only then that validators in the previous instance of the
 set, yet not the current instance, may unbond their stake.
 
-### Vote (message)
+### Set Keys (message)
 
-  - `coin` (Coin): Coin whose key is being voted for.
-  - `key`  (Key):  Key being voted on.
+  - `network`   (Network):   Network whose key is being voted for.
+  - `key_pair`  (KeyPair):   Key pair being set for this `Session`.
+  - `signature` (Signature): A MuSig-style signature of all validators,
+confirming this key.
 
 Once a key is voted on by every member, it's adopted as detailed above.