As you may know I've been mentionning this here and there since I came around in january. While being on my way to implement this I noticed I'm not the only one working on that anymore. So, I'd rather open the thinking process now. The aim is to see if we can agree on a solution satisfying enough. Stellar is a step ahead when it comes to multisignatures, as all setting up operations are handled natively on the blockain, allowing for a wide variety of configurations. However, the signature collection is not part of the scheme so we had to rely on old-school servers with all their known pitfalls. It is possible to move the signature collection process to the blockchain itself and I'll try here to expose a solution for that. Goal When several parties are signing a transaction for a shared account, we want that: Each signer can send its signature to the collection service Each signer who happens to get a signature from someone else can send it to the collection service aswell Each signer can witness the process Nobody can delete or modify collected signature Anyone can gather the signatures and attempt to validate the transaction Non-legit signers can't participate in the process Nobody owns or rule over the collection service It should be efficient Those goals fit very well what blockchain technology have to offer. Attaching datas to transactions Assuming that each signer can already access the transaction to be signed, a minimum of two pieces of datas have to send to the blockchain: The hash of the signed transaction A signature It could be desirable to be able to attach more signatures in some cases. A Stellar transaction allow for a memo where a transaction hash can fit. The manageData operation allows to set an entry field to a 64 bytes value, which is exactly the size of a signature. An additional payment operation with the minimum amount is needed to define a recipient for this transaction. The recipient will be the account where the signatures are collected. Collecting account Ideally, this would be a dedicated account, that nobody use, and that would be attached to only one account . This way, we minimize the number of transactions to go through when looking for signatures. Stellar horizon servers arn't exposing a way to select a transaction by memo, so this is important if we want to keep good performances. This collecting account should be recorded as an entry into the main account; So the signers would have to meet the threshold to set it up / change it / disable it. In this setup, I would recommend that the lowThreshold, which rules upon manageData operation, is set at the same level than the midThreshold, that rules over most transactions except adding/removing signers. I propose that we use an entry named "config:signature_sharing" to store the publicKey of the collecting account. Fetching signatures Getting the signatures from the transactions on the collecting account is simple enough. One have to filter them by memo, then get the value out of manageData operations. As we don't send any hint about the signature emitter, and as we want that signers can transmit signatures from other members as well, we simply have to try each signature against each signer to find which match. This scheme allow transmitting of hash signatures as well which is a must-have. This should be noted that only transactions sended by legit signers to the collecting account should be fetched for this operation. Additional side-effect This setup also allows to handle cases were several single signatures account are involved in a multiple-operation transactions, like in smart contracts. In which case, each signers could share its signatures if the transaction source have the protocol enabled. Pitfalls Setting this up may require signature collection which have to be handled another way (i.e.: XDR copying); For new accounts, it is adviseable to enable onchain signature collection first, add co-signers then. Account master key can't send its signatures as it would mess with sequence number and require multisignature itself. However, it can gather signatures and validate. Ideally, the master key of a shared account would be put to 0 for simplicity. Stellar protocol currently reject transaction with "too much" valid signatures, which's something we'll have to work around. Getting the exact right number of signatures may be tricky. Anyway this is true for multisig in general and it's not specific to the present proposal. It is not clear whether the Stellar Foundation welcome hosting datas on the blockchain; I told them about my plans and I'm currently waiting for news (doesn't looks like I'll get any). That's all folks! Hopefully this is consensual and simple enough so we can get a standard out of it. I'm actually coding the javascript library that will handle it and I hope to present a reference implementation soon enough. A next step would be to use a similar design to setup a transaction collecting account, where transaction XDR could be shared between legit signers. This would complete the scheme and allow us to have a really secure and complete solution for multisigning on the Stellar blockchain. If you have any comment to do on this please go ahead so we tackle anything I would have missed.

I know it works, but honestly, I think this should be done off-chain. Instead of working on this, I welcome people to collaborate with me on making the off-chain solution I have into something decentralized. (Ultimately, this should have been part of horizon from the get-go.)

dzham Hey ? Could you give us the reasons why you think it should be done offchain? It seems very counter intuitive to me.

MisterTicot It's better than hogging up the ledgers with ephemeral data, until we get some Coda Protocol-like ZKPs for removing the need for historical archives? Also, off-chain isn't limited by the same transaction speeds that on-chain is.. I.e, having to wait for a ledger close. I get why on-chain seems attractive, but it's just a mirage.

dzham Well, I can tell there's truth in your ideas but dismissing the whole project that way seems kind of a light behavior to me. It should be seen that both ways have their own benefits and that on-chain signature sharing could clearly be the best solution in some cases. Once again you're simply making the affirmation that it shouldn't be tried at all, but without any kind of convincing demonstration. (How could it be a mirage to start with?)

MisterTicot I don't have better arguments for it right now, but it's based on years of thinking about this, and writing multi-sig code on Stellar.

The transaction system in Stellar is something I find very elegant. It's very expressive, and very powerful, for what it does. The way you can have multiple parties come together in one transaction, and do things atomically in one go (OTC trades/swaps/shuffles, e.g.), which would in other systems take multiple rounds of carefully thought-out transactions. The way you bundle operations into atomic packets, where every operation has to succeed, and how you can do conditional transactions using that. The way signature thresholds and signing weights can be use to express much more complex schemes than just your regular old n-of-m. The way user specified signers sign for accounts, and not necessarily just the private key corresponding to an account. Somehow signature aggregation didn't make it into the system. I think it should have. I've seen systems where you post a transaction on the chain, and then signers post their signatures on the chain, and when a required number of signers have signed the transaction is executed. Stellar decided against a solution like that, and I'd agree. Signature aggregation is messaging about transactions. I guess I'm a bit of a purist here, but I think that is something that is better taken care of off-chain. First of all, you have no bloating of the ledger with ephemeral data. A proposed transaction is only live until either the transaction is accepted by enough signers (and subsequently published), or until it's cancelled (manually, or by a time out). Not having to worry about data sizes also brings you a lot more flexibility, and security; You can encrypt proposed transactions so only the signers can examine them, sending each signer an encrypted blob only they can decrypt. You're not dependent on ledger updates for disseminating information between signers, so your information flow is a lot quicker. No complications with sequence numbers I think what ought to have been done, is for signature aggregation to have been integrated into the Horizon service. Horizon is what everyone is interacting with already. Instead of posting a fully signed transaction, you'd post a partially signed transaction. Signing requests would be broadcast to signers using event streams, just like the various ledger events are. Since that didn't happen, the second best thing is having a 3rd party decentralized network for off-chain signing, working in the same way. Decentralized networks aren't anything new, we know how to deal with them. You'd get some amount of people to run nodes, and have clients remember a number of nodes they have been in touch with + a couple of seeds. The nodes make sure to synchronize transaction proposals, signatures, and signing requests. Again, ideally that would have been part of Horizon, to get things working seamlessly. I think elegance is worth striving for, and that's why I'd go off-chain anytime. On-chain is like putting lipstick on Mona Lisa.

On-chain signature collection

umbrel

dzham I agree that horizon would be a perfect place for it. I also sometimes feel, that we need multiple horizon-like implementations, focused on specific use case, instead of trying to do payments + trading + every other use case.
What are you currently working on? Is it some kind of API we should all host?

dzham

umbrel I agree that horizon would be a perfect place for it. I also sometimes feel, that we need multiple horizon-like implementations, focused on specific use case, instead of trying to do payments + trading + every other use case.

It's hard to make a one-size-fits-all solution. Even for basics you sometimes have to go over the bridge for water.
It doesn't do everything I need, I know that. And it's starting to become quite bloated, in terms of the default returns.

The GraphQL PoC that was made wasn't such a bad idea, it just needs to be able to support more kinds of queries.

umbrel What are you currently working on?

Nothing tangible. I have the centralized version (https://constellation.futuretense.io/) running since a year or so, and I have lots of thoughts and sketches. I never went further because there just didn't seem to be any interest. The only people talking multi-sig, for years, were me and sacarlson.

Is it some kind of API we should all host?

That's the idea. We get a number of people to host servers, and we publish a couple of seed nodes.
I'm not sure how many would be enough. There aren't really any security issues -- it's about availability, and not having a single-point-of-failure.

MisterTicot

dzham

Thank you for this complete answer. It helps me thinking about it.

I totally agree that this should be implemented in horizon as well.

I think the first official reason not to do that was to preserve ressources.
However, alternatives use more ressources or are redundantly implementing a side-network. So this "pushing outside" the problem can't really lead to a satisfying solution.

Making a side-network have the main issue of not having the same level of trust and security than the blockchain itself, making the feature half-implemented. For this reason, I think we should not aim for such solution on the long term.

Putting data's on the block chain is like using validators network, except the data are not cleaned after being used. This is cumbersome and doesn't makes much sense. For this reason, this should not be the final solution either.

Hopefully having a less-than-optimal solution running on the blockchain will show that:

It's not so difficult to implement into the network itself.
There's a demand for it.
It doesn't use so much ressources than one would think.

The storage issue may then push the dev to implement it properly in horizon, if the system proves usefull.

Of course this is pure speculation. I'm only trying to clarify my views about it.

I mostly agree with what you said. I still think the on-chain solution is a desirable fallback solution for a lot of users. I would say your rationale seems to make more sense from a developer point-of-view; Meaning: if they had to choose, lot of users may prefer a full on-chain solution than a split system, even if it is not optimal as a design.

I can tell people with high-speed automation would need something another network, though.

dzham

MisterTicot I still think the on-chain solution is a desirable fallback solution for a lot of users. I would say your rationale seems to make more sense from a developer point-of-view; Meaning: if they had to choose, lot of users may prefer a full on-chain solution than a split system, even if it is not optimal as a design.

My fear with that, is that most people would find on-chain good enough (because it is good enough for everyday use), and then we won't get the benefits of something more scalable, faster, etc. It's all about interoperability in the end.

dzham

@MisterTicot

If it has to be on-chain, what would be your take on using testnet (or a private network) for signature aggregation?

MisterTicot

dzham

I thought about this solution also. The issue with it is the same than side-network: it's simply not stellar anymore, meaning you don't have the same security and guarantees. Especially on testnet.

Now, having several of us running a private network for this purpose could be a form of solution. I would not be so happy about it though, because it seems like settling durably for the low-grade solution. I don't know if you get what trouble me here.

I mean, multisig is not a secondary-level feature, right? It's in the core of the design now and it deserves to be implemented right. Now, if we put in place this kind of community-driven fix, don't we give a mandate to never make it right?

MisterTicot

Maybe it would help to have @jed or someone from Stellar team commenting on this one ?

dzham

MisterTicot

Maybe.. In the meantime I'm working on an off-chain solution, using ipfs pub/sub for synchronizing hubs.

StellarGuard

I would not be surprised at all if this is something that would be accepted if we put the work into adding it to Horizon and did a PR. I would be surprised though if this was something that SDF were planning to work on themselves — I just don’t see enough demand for it yet. The people who have encountered and understand why this is a problem probably aren’t much more than the people in this thread already.

With that said, if we can come up with some tangible plans for how to implement this I’d be more than happy to help code it.

dzham

If I talked golang, integrating it directly into Horizon would be my first choice.

It's not just multi-sig though, it's bigger than that. The same messaging rail could be used for regular transactions also, instead of SEP-0007:y links, or QR codes.

I'm reading up on distributed logs, which is basically what this is.

For signing requests you have four types of messages (signed by end-user, and verified by the hubs),

create a signing request
approve a signing request
reject a signing request
cancel a signing request

and these get replicated throughout a network of hubs, where end-users can connect to any hub in the network.

All state can be recreated from the message log. If we let requests have a (say) 24h expiry, logs can be trimmed to only include messages that relate to open requests, making log catchup quicker.

MisterTicot

dzham

It looks like a specialized ledger on which you can delete entries. So I guess that somehow most of the code is already in there (stellar core).

There would be two kind of data's in there:
- Unsigned transactions that need to be shared between signers. The deletion condition would be "outdated " sequence number.
- Signatures for a given transaction (referred as a txhash - we don't always need to share the transaction when we share the signatures). The first deletion condition would be on transaction approval on the blockchain. If the reference transaction is known, the second deletion condition would be when sequence "outdate". If not, it could be time-based. Hence, smart-contract reliying on publicly available signatures are supported even it takes 10 years to resolve. An additional condition for removal could be if enough signers declare they won't sign a transaction (in which case we need to record in the editable ledger when user decline to sign - which is an interesting feature that could actually save ressources and allow the time-based condition to be softer).

This service should incur a fee anyway to counter spam.

I can't get how it would obsolete SEP0007. In my mind this scheme would only allow to share signatures/transactions between the actual valid signers . If you allow transaction request from any arbitrary peer, you open the doors to crazy spamming. Please note that a particular peer can be added as a signer with a non-determining weight to be allowed to send transaction request if the user wish to do so.

Moreover transactions-as-querries is still a must have for direct communication between services and over social medias / websites / email. URIs are selectable by the user, while direct transaction request are imposed to the user.

dzham

It's a bit similar, except you won't ever need the full message history, since signing requests are removed when they 1) have enough signature weights, 2) have enough rejections that they can't ever reach (1), 3) are cancelled by the creator, or 4) expire by means of a timeout.

Spam could become an issue, not sure how to deal with that yet. I'd prefer something you don't have to pay for, since that opens up a whole new can of worms.