Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OPT-IN support for SEP0023 (Muxed Accounts M-strkeys) #632

Closed
2opremio opened this issue Apr 15, 2021 · 2 comments
Closed

Add OPT-IN support for SEP0023 (Muxed Accounts M-strkeys) #632

2opremio opened this issue Apr 15, 2021 · 2 comments
Assignees

Comments

@2opremio
Copy link

TL;DR

Add opt-in support for SEP 23. SEP23 adds a strkey representation (M-strkeys) for MuxedAccounts.

For example, given the MuxedAccount MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26 , you might get the following fields:

source_account: GAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSTVY
source_account_muxed: MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26
source_account_muxed_id: 1234

It should be implemented as an opt-in feature

SEP23 is still a Draft. We plan to (at least initally) use the M-strkey representation to explore the use of Muxed Accounts. Later on, we me consider it stable and enable it by default.

As such, it's critical to make M-strkeys an opt-in feature (e.g. only usable by the user through am explicitly enabled flag or other mechanisms).

In particular, no user should be enabling M-addresss unknowingly, either for new or existing code (e.g. through an SDK update).

Recent SEP23 representation change

If you were already familiar with SEP23, it's worth noting that the encoding ordering changed recently at stellar/stellar-protocol#895

The SEP 23 specification already contains that modification.

Reference implementation

You can use the Go SDK implementation as a reference: stellar/go#3527

In the Go SDK we have one entry point into generating transaction envelopes, NewTransaction() . We added a configuration parameter to NewTransaction() which toggles support for muxed accounts. If NewTransaction() is configured with muxed account support then it will interpret "M..." address strings as muxed accounts at the xdr level. However, if NewTransaction() is configured to disable muxed accounts, whenever an "M..." address is provided we will extract the underlying "G..." address from and use that at the XDR level.

We followed a similar approach for the other entry points of the SDK (namely TransactionFromXDR() and NewFeeBumpTransaction()).

@Shaptic Shaptic self-assigned this Apr 20, 2021
@bartekn
Copy link
Contributor

bartekn commented Jun 10, 2021

Can be closed?

@Shaptic
Copy link
Contributor

Shaptic commented Jul 29, 2021

Yep, here are the relevant PRs to the base library:

There was also an SDK-specific bugfix in #655. It was released in the SDK v8.2.0.

@Shaptic Shaptic closed this as completed Jul 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants