Safe slate document describes some potential problems around multiparty slatepack building and how this may be done in a safe way. The main issue it tries to solve is to verify who the partial excess contributor is and how to make sure they will indeed contribute a signature without seeing their partial sig.
As the document suggests, this would have to be verified by a cryptographer. But it’s good to have this documented somewhere.
In a multiparty slate, how would the be the best way to encrypt the slatepack?
Probably no different than what we do today which is to encrypt the whole slate with the public key of the next party. There could be an order specified by having each participant address in the slate and then simply check who’s the first one that did not contribute their partial excess or partial sig if they came to this point. This doesn’t make this order guaranteed, it would be more like a helper or suggestion to avoid manually selecting/searching for the next one.
Probably it is best to make it a fixed order. Otherwise people might accidentally send it back to someone who already signed, in which case they can reconstruct the Shamir Secret Share of the other since they know the state before and after they signed. If it is done in a round/circle way that is somehow fixed through logic, meaning all wallets expect the same order, it is more secure.
The above applies for Multi-Sig using Shamir Secret Sharing (SSS) as suggested by Poolstra. One thing I always wonder about it how to de a receive with a multi party wallet. Having a very large multisig wallet means all these wallet need to be online all the time for receiving and probably it would result in a time-out very quickly.
So for the time being a 2 out of 2 MultiSig or 2 out of 3 would already be great to have, only the protocol should be designed to be extendible to larger multisig wallets…The only problem again with 2 out of 2 MultiSigs is that I am not sure if the signers could deduce the share of the other by comparing what they send and what the signature looks like on-chain. Or does the offset protect against that, not sure.I guess I should reread the explanation by Poolstra:
https://sci-hub.se/10.1007/s10623-019-00608-x
I don’t think you can guarantee the order because two adjacent parties could collude and fill parts in a different order. A scheme should not assume an order because of this. The above scheme is somewhat similar to Schnorr verification. In Schnorr, you commit to (X, R) to get a challenge and from this a scaled pubkey for which you show a private key. Here, you start with a sequence of pubkeys, commit to them and obtain a new scaled pubkey on which you’ll perform the Schnorr sig. Very similar trick, but instead of doing this to prove knowledge of the private key, you do it to get the guarantee of party inclusion (and later, you perform the regular Schnorr sig to actually prove the knowledge of private key).