A while ago I was discussing the issue of how many wallets do not handle multisig transactions very well (or at all), and I believe that one of the major reasons why is that each service/wallet needs to create its own multisig coordinator to handle them, or explicitly delegate to an existing service. But what if we put the power back into the hands of the people, so to speak, to choose how they want to handle multisig transactions. Every use case is different, so maybe it makes sense to allow users to decide what service should handle their multisig. It could be an internal accounting service where unsigned transactions aren't made public, it could be a completely open multisig service like @dzham 's Hydra or Constellation, or a bridge to a tool like @MisterTicot 's cosmic.link -- or it could be a niche security service like StellarGuard. After some discussion about adding StellarGuard support to the Account Viewer ( https://github.com/stellar/account-viewer/pull/68#issuecomment-411414041 ) we talked about some possibilities to making this process agnostic to any particular vendor and came up with the following sketch of what it might look like: Look up a data field on the account that is originating the transaction. EX: "multisig_coordinator" 1a) If that field does not exist, do not continue with this process. That field should be a domain that has a stellar.toml file. EX: "stellarguard.me" The stellar.toml file contains a separate field for multisig_endpoint or something similar. EX: MULTISIG_ENDPOINT=" https://stellarguard.me/transactions/new " Submit the transaction to that endpoint in a standardized format (details TBD, but probably POST xdr or a SEP-0007 style URI, maybe with some callback) That service is then responsible for coordinating the rest of the signatures, and then submitting to the Stellar network once the transaction thresholds are satisfied, or possibly submitting a callback. Details of how the coordination is done is up to the service itself. Basically, the idea is that users that want to use multisig will explicitly opt in to a multisig service by setting that data field in a way that fits their needs (this is similar to the way that StellarGuard adds an inactive signing key to indicate that the user wants to use StellarGuard) I'd like to start collecting some feedback on this idea, and if it has merit I'll propose it officially as a SEP.

StellarGuard Hi, I may have a good news for you. I'm working on a SEP for on-chain signature sharing. As you may know, oc-multisig is configured by up to three account entries (on-chain): config:multisig holds the public key for collection account config:multisig:network holds the network on which collection happens (public, test or passphrase) config:multisig:server may be used to pass the URL of an horizon instance Now the SEP specify that oc:multisig can eventually something else than a public key, in which case network and server fields should point to an off-chain signature & transaction service. The goal is indeed to introduce support for services such as Dhzam one. I'm going to publish the proposal I a couple of days. I think we could work together to refine the off-chain support.

StellarGuard Sounds like a recipe for disaster ? Seriously though, if the initiator specifies a coordinator, everyone else must support it. So, we're still in a position where wallets have to support all different kinds of coordinating services.

dzham Well and could make a library that support 2 or 3 reliable protocols with different properties. And if the way to pass transactions/signatures to a server is standardized into a SEP we could leave the doors opens for challengers.

(Re-iterating, the whole raison d'être of a service like Hydra is to be vendor agnostic, to be decentralized -- Cut off one head, there's still ten more servers running.)

MisterTicot What about just collaborating on making one service? Why does everyone have to compete with everything on Stellar?

dzham That's exactly the reason why I decided to extend conf:multisig fields usage to use them with off-chain solution: to support Hydra when user choose to enable it.

dzham Well it's true I've got that bad feeling about each one doing its own thing as well. On the other hand I still think on-chain solution brings its own possibilities as we already discussed, and the solution is ready and functional. I understood Hydra got properties that makes it a better solution in various cases and found this way to make things works together with low friction.

MisterTicot Hydra stores collected signatures in a distributed database, and needs direct access to a stellar-core for queries. Besides, we have different scopes. Hydra tracks (and notifies users of) the signing progress, and (optionally) submits a transaction when it has enough signatures.

dzham Mind elaborating on your disaster scenarios? Right now we are here: https://www.xkcd.com/927/ But where I think this approach could help with that is that your service will define what endpoints to call in the toml file so that there doesn’t actually have to be 8 different client libs that bridge these different services — there can just be a single one that allows you to send to many different services. Hydra sounds like it will be a great solution for public multisig coordination — but as we discussed in a github issue a few months ago, everyone who uses multisig does it in a slightly different way, so it’s hard to build a one size fits all approach that works. I think this scheme (or any scheme that lets the user decide) provides the flexibility to help with that.

StellarGuard Right now we are here: https://www.xkcd.com/927/ I was just thinking about posting that one before. That's the Stellar ecosystem in a nutshell.

A vendor-agnostic way to bootstrapping multisig coordination

MisterTicot

dzham I was referring to the fact that the 2FA usual flow is to be validated when signer sign, not at a later time.

dzham

StellarGuard

I'm just saying how signatures work in Stellar. Stellar-core doesn't know that a signer is 2FA or not. They're all the same.

Having a StellarGuard user-flow where the "2FA signer" only signs if the "primary signer" has signed first makes all the sense, and would still work for something like Hydra.

« Previous Page