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

Cap 0027: first class multiplexed accounts #2498

Merged
merged 2 commits into from
Apr 14, 2020

Conversation

MonsieurNicolas
Copy link
Contributor

Description

This PR implements CAP-0027 : First-class multiplexed accounts

This PR addresses feedback from #2497

Checklist

  • Reviewed the contributing document
  • Rebased on top of master (no merge commits)
  • Ran clang-format v5.0.0 (via make format or the Visual Studio extension)
  • Compiles
  • Ran all tests
  • If change impacts performance, include supporting evidence per the performance document

@MonsieurNicolas MonsieurNicolas changed the title Cap 0027: first class multipexed accounts Cap 0027: first class multiplexed accounts Apr 12, 2020
src/xdr/Stellar-transaction.x Show resolved Hide resolved
src/transactions/TransactionUtils.h Outdated Show resolved Hide resolved
src/transactions/TransactionUtils.cpp Outdated Show resolved Hide resolved
src/transactions/TransactionUtils.cpp Outdated Show resolved Hide resolved
@@ -47,7 +47,7 @@ PathPaymentStrictReceiveOpFrame::doApply(AbstractLedgerTxn& ltx)
return false;
}
innerResult().success().last = SimplePaymentResult(
getDestID(), getDestAsset(), mPathPayment.destAmount);
getDestMuxedAccount(), getDestAsset(), mPathPayment.destAmount);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change isn't mentioned in the proposal. Is this change actually desired?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I saw this too. I don't think we can actually do this either as SDKs are probably using the return the RAW result (like exchanges checking if a transaction is for them).
This is not a conversation for the PR but against the CAP, so let's discuss elsewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh it was actually mentioned. I missed it as well (last bullet point).

The following fields, which were previously an AccountID or AccountID*, are now a MuxedAccount or MuxedAccount* (respectively):

    PaymentOp::destination
    PathPaymentStrictReceiveOp::destination
    PathPaymentStrictSendOp::destination
    Operation::sourceAccount
    Operation::destination (for ACCOUNT_MERGE)
    Transaction::sourceAccount
    SimplePaymentResult::destination

innerResult().success().last =
SimplePaymentResult(getDestID(), getDestAsset(), maxAmountSend);
innerResult().success().last = SimplePaymentResult(
getDestMuxedAccount(), getDestAsset(), maxAmountSend);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as for PathPaymentStrictReceipeOpFrame.

@MonsieurNicolas MonsieurNicolas force-pushed the cap-0027-MuxedAccounts branch 2 times, most recently from 03eb108 to 7253b0b Compare April 13, 2020 22:21
@jonjove
Copy link
Contributor

jonjove commented Apr 14, 2020

r+ ef71e8c

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

Successfully merging this pull request may close these issues.

3 participants