Implement BLS M-of-N like sporks

[UdjinM6]

The general idea is this:

• allow multiple hardcoded spork addresses (N) to be specified in chainparams/cmd-line/config (smth similar to -budgetparams but for -sporkaddress?);
• allow multiple messages with the same id/value signed by different spork addresses;
• (de)activate some spork only when at least M similar message with the same id/value signed by different signers were received (i.e. code changes of that nature: map<id,spork> --> map<id, map<signer, spork>> or smth like that).

[nmarley]

M of N? 😉

Great idea, I've been thinking of this also for several months. One of the questions I have is about who determines spork key owners. DIP2 could enable a type of TX for "Spork Candidate" and MNOs could then vote on those, and if sanctioned by the network, then those candidate pubkeys (or addresses) become part of the valid N set of spork keys. That would be part of a larger spork re-engineering which includes on-chain spork votes by spork key holders.

And obviously this enables Dash to be more decentralized by allowing MNOs to elect stewards to watch over the network. I think this would be much better than something like asking MNOs to directly vote on sporks, as this ability requires both timeliness and Dash network expertise -- knowledge of how each spork will affect the network.

[thephez]

I have not thought through the security implications of this enough to know if it is a reasonable idea, but it may eventually make sense to use reference spork key owners via BU instead of an actual address/key. This would probably have to be done via a process like @nmarley mentioned. Something to think about anyway... 🙂

[codablock]

I'm wondering if it wouldn't be better to "just" switch to BLS M-of-N here? With BLS based sporks, we'd not have to worry about multiple signed spork messages per spork. All the logic would stay the same for spork management and propagation.

There is however some additional effort required to allow offline DKG's controlled by RPC commands. So multiple devs would have to issue a set RPC commands to first agree on the threshold public key and then later perform other RPC commands to threshold sign individual sporks.

An alternative would be to leverage already existing LLMQs for the communication required in the "offline" DKG. So, devs would initiate a "offline" DKG session by issuing some RPC commands and Core would figure out which LLMQ to use for the communication. This would automate large parts of the "offline" protocol.

I have this planned already for the time when we eventually switch to using BLS for transactional signing. It would allow people to perform a trustless setup of a M-of-N address. It might also be useful for other stuff were people need M-of-N threshold signing (e.g. sporks).