Add draft: Onchain Signatures & Transaction Sharing

[MisterTicot]

This proposal describe the logic used in stellar-oc-multisig to share signatures and transaction request on-chain. I'm submitting it for discussion so we can get a standard out of it.

Please let me know if everything is done as it should as it's the first time I'm submitting a proposal like this.

View the proposal

[stanford-scs]

Okay, well I accidentally usurped your SEP number, because we don't have a good system for allocating the numbers. Sorry about that. I guess the least I can do is review your SEP.

High level, I think this addresses a need, but does it in kind of a clunky way. The clunkiness is sort of inevitable given what you are trying to do. So what I'd suggest is that you maybe take a layered approach. So I like the idea of signaling stuff using data entries (config:multisig, etc.), but maybe you should generalize it to other schemes. In particular, I could see wanting to use any number of distribution mediums for distributing transactions and signatures.

So what you would ideally do is exchange the information using URIs, where a URI might be https for something like a github gist or a tweet, it could be keybase:// for data stored in keybase, or it could be a new URI scheme you introduce for (ab)using Stellar's history for storage. Ideally you can at some point then update the latter, for instance if we ever add a NOP operation. Also, if it turns out people prefer off chain exchange of data, your SEP would still be useful to them.

[MisterTicot]

@stanford-scs TY for the feedback.

I think there's a confusions between data in config:* account entries, whose role here is to point to the right signature retrieval mechanism, transaction history, whose role here is listing the collection of signatures and transactions, and data embedded into transaction, which carry signatures and XDR.

I'm not sure for which one you propose to create a query-encoded equivalent, but in the first case I'm failing to see the point.

About sharing tx/signatures over queries I'm waiting for Dzham to release his Hydra solution to align on it. There's not point I make a SEP about it while someone else is actually coding it another way.

Ideally I would write specifications for a generic onchain message-passing protocol abd port this SEP over it. Still waiting for the SDF to say yes to that.

I'm not sure I got your idea right. I'm still a bit confused about how it would work practically, but looks like something interesting.

PS: Isn't setOptions without parameters already a NOP operation? Not sure how it would help, though.

[stanford-scs]

I was suggesting a NOP operation that lets you encode a bit more data, like a comment.

I guess my point was that there could be one data retrieval mechanism with multiple back-ends, and you should be able to specify what kind of data retrieval to use for each step of the multisig process (fetching transaction, fetching signature pieces).

Should I close this PR if you are waiting for Dzham? Or will the goal be to make this compatible with some version of Hydra?

[MisterTicot]

No because the point of this PR is to define how signatures & transactions should be shared on-chain.

It appears that the way it is configured could be generalized to achieve cross-wallet multisignature configuration. This is why in this SEP I leave that possibility open but undefined: it should be defined in another document.

[MisterTicot]

About the NOP operation: it would allow to encode twice as much than a manageData operation for the same space usage as we don't have the data entry name field (useless in this use case). So, that's a great idea.

[pselden]

I haven't officially posted this yet as I'm still working out some kinks and doing a full implementation/proof of concept, but this sort of dovetails into the multisig bootstrapping process I've listed here: https://github.com/stellarguard/stellar-protocol/blob/sep-multisig-coordinator-server/drafts/draft-0005.md

@MisterTicot and I had a talk about ways we could make this compatible with this protocol, and the root of it came down to sharing some data field that indicates what type of request it is. I'm glad to have a full discussion on when I open it up for a full PR, but I like @stanford-scs method of generalizing it. What that generalization looks like, I'm not exactly sure.

[MisterTicot]

Just to update on this SEP: I think it bring too much new concepts at once to be properly reviewed. I'm thinking about breaking it down into logical pieces:

• Namespaces usage
• How we define a signature collector, what's the scope of it (each time it is source of a transaction is elegant solution), how a new collection service can be made compatible. I think this could enter in the SEP you're working on @pselden.
• Another SEP that define messaging over the ledger (the base I use to publish signatures and transactions)
• With those 3 concept being cleared out the core of on-chain signature & transaction sharing will be much simplier to describe

[theaeolianmachine]

@MisterTicot what are the next steps you want to do here? At the minimum we could push this in as a draft for further edits in the repo, or if you want to scrap the work entirely, we can close the pull request.

If you want to move this forward with the new process as a draft (and actually get some more momentum into this), could you do the following?

1. Pick which track you'd like to propose this idea to: Standard or Informational. Info about both can be found here: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/README.md. In general, Informational's bar for acceptance is much lower and is mostly to prevent security risks from being adopted by the community. The Standard track requires more scrutiny (especially if there are multiple competing ideas).
2. Rename the file for how drafts are to be named in that process. I'll assign a number when this gets merged in and take care of that for you :).
3. Take a look at the process in the above readme, and let me know if you have any questions.

Once you choose the track, it's up to you to put the time into editing the draft until you're ready for bringing it to a vote. The intent will be to merge this in, and when you make a new PR moving it to Awaiting Decision we'll assign a buddy to give feedback and open deliberation to the public. Any draft feedback we suggest you discuss on our public mailing list, so thanks for already doing that! Finally, do note the new process for submitting drafts for future drafts.

I'll rename and move this file, along with giving it a number when this is merged in.

[MisterTicot]

This is still the plan:

Just to update on this SEP: I think it bring too much new concepts at once to be properly reviewed. I'm thinking about breaking it down into logical pieces:

• Namespaces usage
• How we define a signature collector, what's the scope of it (each time it is source of a transaction is elegant solution), how a new collection service can be made compatible. I think this could enter in the SEP you're working on @pselden.
• Another SEP that define messaging over the ledger (the base I use to publish signatures and transactions)
• With those 3 concept being cleared out the core of on-chain signature & transaction sharing will be much simpler to describe

Namespaces & Bootstrapping Signature Coordination have been figured out enough for me to go ahead. Now, I need to write the Onchain Messaging SEP prior to rewrite Onchain Signatures & Transaction Sharing on top of it.

I think we could keep this SEP as a draft on the Informal track for now. I'm still willing to follow up with that work as it's likely to be put in production somewhere between that spring and that summer.

[theaeolianmachine]

Sounds good, if you can move it over to the new file format, mark the track as Informational, and remove the current number, I'll merge this in as a draft.

[theaeolianmachine]

Went ahead and made the changes, and merging this in.