Reflections on two methods of multisig transactions

I've been thinking about the two methods first used to make multisig tutorials today, and about how the differences between them offer advantages and disadvantages for different situations. Since this is more of a philosophy post than a tutorial I thought I'd make it into a separate one.

@crokkon's method, which @holger80 eventually used as well, involves accounts signing transactions and then passing them to other accounts who sign them as well, until the threshold value is reached and the transaction is broadcast.

My method involves the core algorithm collecting keys and, once it has enough to surpass the threshold, signing and broadcasting the transaction.

Both have advantages and disadvantages. The sign-and-pass method offers greater key security, as only signed transactions are communicated, not the keys themselves. Because of this it's also able to be integrated into third-party software which makes signed transactions rather than communicating keys, such as Keychain or SteemConnect. On the disadvantage side, however, it's considerably less flexible because everything it does is in blockchain ops and limited by the blockchain. Particularly large is the one-hour maximum time between first and last sign for any transaction, but it also limits other possibilities for work on the second layer. Transactions are also fundamentally ordered: if two users are signing at the same time, one of them is going to have to be rejected and do it again.

The key-collecting method offers less key security, as keys are either stored centrally or communicated. Some security can be added on the second layer, but on a fundamental basis no matter how good it is it can't compare with never having to share your keys at all. However, on the benefit side, it isn't subject to the one-hour limit, and other time- and situation-limits on voting can be implemented freely. It also can offer more flexibility, such as allowing users to sign concurrently (particularly important with a large user population), making provisions to resolve conflicts between similar transaction proposals, using substitute or parallel voting thresholds that aren't just linear weight, proxy voting, and so on. There's a great deal more potential complexity in the key-collecting system.

I don't see either approach as fundamentally better than the other. Which approach is superior is going to depend entirely on the goals and challenges of the particular project in question. I'm skeptical of the importance of key security since multi-auth can be entirely unwound by changing the master password or doing an account recovery, which to me makes it unsuitable for very-high-security operations to begin with. However, integration with Keychain and SteemConnect is a big deal for simple uses of multi-auth which can fit into the one-hour time limit.

In the long-term, however, for more complex projects, I really like the potential of building a second layer on top of multi-auth that comes with key collection, even though it comes at the higher development cost of building a new layer of security to keep those keys safe. Multi-auth on the blockchain could be used as the basis for developing all sorts of interesting account governance algorithms on that second layer. Much of this could be done without multi-auth, but there are particularly some interesting things that become available when you stack multi-auth accounts so that individual groups can interact within one program to make decisions for their account which then contributes that decision to another multi-auth account, combining the decisions of several groups.

That may just be theoretically interesting; Steem accounts don't yet do all that much that really needs wide governance, though if custom_json subchains do end up becoming a major thing that might not be true for very long.

I suppose there's a multi-auth solution for proposing, approving, and rewarding particular Steem Monsters teams waiting to be built already, if anyone's into mixed cooperative-competitive group play. I may have to think about that one a little bit.