Add support for CAP 0027 (MuxedAccounts) #325
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
abuiles
commented
Apr 15, 2020
| describe('Keypair.contructor', function() { | ||
| it("fails when passes secret key does not match public key", function() { | ||
| let secret = "SD7X7LEHBNMUIKQGKPARG5TDJNBHKC346OUARHGZL5ITC6IJPXHILY36"; | ||
| it('fails when passes secret key does not match public key', function() { |
There was a problem hiding this comment.
oh, this is replaced automatically by some linter on this repo -- ignore this changes
abuiles
commented
Apr 15, 2020
|
|
||
| describe('Keypair.xdrMuxedAccount', function() { |
There was a problem hiding this comment.
this is the new tests
tamirms
approved these changes
Apr 15, 2020
Merged
abuiles
added a commit
that referenced
this pull request
Apr 20, 2020
* Update XDRs with muxed accounts. * Add helper to convert keypair to muxed account. * Fix tests.
This was referenced Apr 24, 2020
Closed
Merged
abuiles
added a commit
that referenced
this pull request
Apr 27, 2020
This version brings protocol 13 support with backwards compatibility support for protocol 12. ### Add - Add `TransactionBuilder.buildFeeBumpTransaction` which makes it easy to create `FeeBumpTransaction` ([#321](#321)). - Adds a feature flag which allow consumers of this library to create V1 (protocol 13) transactions using the `TransactionBuilder` ([#321](#321)). - Add support for [CAP0027](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0027.md): First-class multiplexed accounts ([#325](#325)). - Add `Keypair.xdrMuxedAccount` which creates a new `xdr.MuxedAccount`([#325](#325)). - Add `FeeBumpTransaction` which makes it easy to work with fee bump transactions ([#328](#328)). - Add `TransactionBuilder.fromXDR` which receives an xdr envelope and return a `Transaction` or `FeeBumpTransaction` ([#328](#328)). ### Update - Update XDR definitions with protocol 13 ([#317](#317)). - Extend `Transaction` to work with `TransactionV1Envelope` and `TransactionV0Envelope` ([#317](#317)). - Add backward compatibility support for [CAP0018](https://github.com/stellar/stellar-protocol/blob/f01c9354aaab1e8ca97a25cf888829749cadf36a/core/cap-0018.md) ([#317](#317)). - Update operations builder to support multiplexed accounts ([#337](#337)). This allows you to specify an `M` account as the destination or source: ``` var destination = 'MAAAAAAAAAAAAAB7BQ2L7E5NBWMXDUCMZSIPOBKRDSBYVLMXGSSKF6YNPIB7Y77ITLVL6'; var amount = '1000.0000000'; var asset = new StellarBase.Asset( 'USDUSD', 'GDGU5OAPHNPU5UCLE5RDJHG7PXZFQYWKCFOEXSXNMR6KRQRI5T6XXCD7' ); var source = 'MAAAAAAAAAAAAAB7BQ2L7E5NBWMXDUCMZSIPOBKRDSBYVLMXGSSKF6YNPIB7Y77ITLVL6'; StellarBase.Operation.payment({ destination, asset, amount, source }); ``` **To use multiplexed accounts you need an instance of Stellar running on Protocol 13 or higher** ### Breaking changes - `Transaction.toEnvelope()` returns a protocol 13 `xdr.TransactionEnvelope` which is an `xdr.Union` ([#317](#317)). If you have code that looks like this `transaction.toEnvelope().tx` you have two options: - You can grab the value wrapped by the union, calling `value()` like `transaction.toEnvelope().value().tx`. - You can check which is the discriminant by using `switch()` and then call `v0()`, `v1()`, or `feeBump()`. - The return value from `Transaction.fee` changed from `number` to `string`. This brings support for `Int64` values ([#321](#321)). - The const `BASE_FEE` changed from `number` to `string` ([#321](#321)). - The option `fee` passed to `new TransactionBuilder({fee: ..})` changed from `number` to `string` ([#321](#321)). - The following fields, which were previously an `xdr.AccountID` are now a `xdr.MuxedAccount` ([#325](#325)): - `PaymentOp.destination` - `PathPaymentStrictReceiveOp.destination` - `PathPaymentStrictSendOp.destination` - `Operation.sourceAccount` - `Operation.destination` (for `ACCOUNT_MERGE`) - `Transaction.sourceAccount` - `FeeBumpTransaction.feeSource` You can get the string representation by calling `StrKey.encodeMuxedAccount` which will return a `G..` or `M..` account. - Remove the following deprecated functions ([#331](#331)): - `Operation.manageOffer` - `Operation.createPassiveOffer` - `Operation.pathPayment` - `Keypair.fromBase58Seed` - Remove the `Network` class ([#331](#331)). - Remove `vendor/base58.js` ([#331](#331)).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
Add support for CAP0027.
Why
Protocol 13 introduces multiplexed accounts, replacing some fields with the union
xdr.MuxedAccountwherexdr.PublicKeywas previously used.This pull requests:
Keypairwith a new method.xdrMuxedAccountwhich creates a newMuxedAccountusing theed25519discriminant.PublicKeytoMuxedAccount.Fixes #324
Breaking changes
This update doesn't include breaking changes for users of this library. However, if you are relying on XDRs, you'll get now a
MuxedAccountwhere aPublicKeywas returned.As long as you are not checking for the instance type, your code should continue to work since both
MuxedAccountandPublicKeyhave the discriminanted25519which returns the same data type.What is not implemented in this pull request
new Transaction(envelope)which containsMuxedAccounts with themed25519discriminant, won't work. For now, we expect an envelope to contain muxed accounts with theed25519discriminant. I'll update this code to be able to read themed25519discriminant in the same PR where I'll add SEP0023 support.