Ok, so I went a bit through the doc and did appreciate the deepness of stellar system ?
I really enjoy the large set of usage case that can be derived out of a little set of transaction, this is really well crafted ?
Now to be honest I feel a bit overwhelmed by this and I didn't get the whole picture in my head, yet.
However maybe I can tell you how my ideas goes so far and then we can see together if something looks wrong?
Just to be sure we are on the same line I'd like to restate the design basis.
So the basics is that it would be desirable to split the functions handled by what we called a wallet until now.
If you take hardware wallet, they basically handle two main distinct task, right? That is, on one side management of the signing keypair handled by the hardware itself. And on the other side user frontend handled by various interfaces.
So we kind of call the whole stuff wallet and I believe that here is the first issue to solve, as we have cleary two things here. Let's call the first authenticator as in 2FA solutions, the second being the actual wallet, because it's where you can see how much you have and ask for transaction that you have then to sign somehow.
So the proposal was about a standard independent authenticator. As such it would have a finite set of functions:
- Create, name, protect, access and destroy your seeds
- Identify yourself
- Sign a transaction
By no means it would show your account holdings or anything like that, because that would be the task of 3rd party services, right?
So practically it looks like we want to receive a description of the transaction to be signed, build it locally, sign it then either send it to the Stellar network to be validated, either send the signature back to the service that issued the transaction description for further management.
So, your question was about complex transaction and multi-signature and it looks like two different issues to me.
In Stellar vocabulary, what I called transaction is actually named operation (payment, setOptions, allowTrust on so on). What is formally called a transaction is a construction made of one or several operations.
Here the issue is to find how to translate such construction into a URI semantic. We already solved the one-operation case. Multiple operation could be written like this:
web+stellar:transaction?ops=2&op1=payment&destination1=vendor*example.org&amount1=100&op2=payment&destination2=3rd-party*example.org&amount2=15
This is a two-operation transaction. It consists of a payment of 100 XLM to vendor*example.org, and another payment of 15 XLM to 3rd-party*example.org.
Complex transaction URI would likely be encoded via 3rd party services relying on API library and described in human language in the authenticator interface before signing. We could imagine web service that allow everyone to program such transaction and issue the corresponding URI, or eventually a shorten URI that lead to the transaction description for the sake of simplicity.
Now the real issue is about multisig. As far as I can get it, the valid transaction to be send to Stellar network is made of two parts:
- The unsigned transaction object
- The set of signature (one or more) making it valid
So all the signatures have to be gathered somehow prior to assemble the final transaction object to be send to the network.
Now if I refer to the initial design idea, this is not to be done at authenticator level but at 3rd party service level. A link could be send to every signers so they locally build the transaction to be signed and send back the signature to this third party, who would eventually assemble the final transaction object and send it to the network.
Here I expect the function building transaction objects to always return the same answer when provided with the same input.
So let's say you have a shared account that require several people to sign transaction. Your wallet service would allow you to program a transaction and would either give you a link to send to co-contractors or either send them directly the signature request.
So here we got additional complexity in our URI scheme because we need to tell the authenticator where the signature have to be sent:
web+stellar:transaction?....&handled-by=service.org&id=xyz123
Alternative ways of sharing transaction description are possible, like text files with dedicated extension. While the URI option is essential, the description doesn't have to be shared this way in every case.
I feel a bit disappointed about how multisig is handled in Stellar because whatever way you put it it seems that you need a third party handling signature collection. This could be an issue in itself. Let's say you make an account as a voting system, where you need 51% if cosigner's to set a data entry that represents the approval of collective decision. Nothing prevent the node handling signature collection to omit some signature and take unlegitimate power over the voting process. Or simply never send the transaction. Wouldn't it be more reliable to have the option of each peer sending its signature directly to Stellar nodes where signature collection could be safely handled by the network?
Well that's a side question that came during my searches. Also maybe I didn't got it right and this is actually possible?
I'm aware we've got something more complex than it was initially, and I have to admit now this is a bit messy in my head.
If we dig more in actual implementation issues, there's also the source, sequence number and time bounds fields to deal with.
Still, I suppose it's possible to deal with it by keeping simple and understandable design concepts and clear goals ?
Please bring your ideas in ?
