Reflections on two methods of multisig transactions

in steem •  12 days ago

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.


Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

To listen to the audio version of this article click on the play image.

Brought to you by @tts. If you find it useful please consider upvoting this reply.

I'm not sure what the uses cases are for multi-auth that are satisfied by shipping keys around. If you have a third party to store N keys, why couldn't they store just 1 key?

That is, if your model is that an intermediate collects keys and then signs, wouldn't it be strictly better to give the intermediate a single key and collect authorizations (signatures) instead? (I guess the intermediate could lose the key in this case.)


Well, one way to do second-level key security is to have the program collect keys and then forget them after it uses them. That way rather than having one master key in permanent storage where it can be compromised we have no access to the account except during the extremely-brief period when it has enough keys to do a sign.

This post has been included in today's SOS Daily News - a digest of all you need to know about the State of Steem.

Hi @tcpolymath!

Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your UA account score is currently 4.728 which ranks you at #1484 across all Steem accounts.
Your rank has dropped 3 places in the last three days (old rank 1481).

In our last Algorithmic Curation Round, consisting of 206 contributions, your post is ranked at #27.

Evaluation of your UA score:
  • Some people are already following you, keep going!
  • The readers appreciate your great work!
  • Good user engagement!

Feel free to join our @steem-ua Discord server

You got a 43.84% upvote from @ocdb courtesy of @tcpolymath!

@ocdb is a non-profit bidbot for whitelisted Steemians, current max bid is 12 SBD and the respective amount in Steem.
Check our website for the whitelist, queue and delegation info. Join our Discord channel for more information.

If you like what @ocd does, consider voting for ocd-witness through SteemConnect or on the Steemit Witnesses page. :)