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

Proposal: multi-transaction #2534

Open
tuloski opened this Issue May 15, 2018 · 7 comments

Comments

Projects
None yet
6 participants
@tuloski

tuloski commented May 15, 2018

Just a weird idea I came up: a transaction that is a multi-transaction.
The idea is to have a single transaction that incorporates multiple "sequential" transactions, such that they either succeed all in one ledger or fail together. The transaction will result in a single meta.
If one of the transaction in the sequence get a tec failure, then all the other transactions are not applied.
If one of the transactions get a ter code, all the transactions are not applied in that ledger and tried in future ledgers.
XRP fee should be higher (multiply by the number of transactions?).

Application examples:

  • N to 1 payment: a user could send a payment in one currency using different currencies at the same time. For example he pays 100XRP using 20 USD, 0.001BTC and 500 CNY.
  • Advanced market making strategies: for example placing orders at different spread without risking that one or many transactions don't go trough.
  • Arbitrage: "close the loop" in one single transaction made up of multiple payments or offerCreate or both
  • More???

I think it could open up a lot of possibilities, but it might be tricky to implement.

@MarkusTeufelberger

This comment has been minimized.

Contributor

MarkusTeufelberger commented May 16, 2018

I would expand this a bit:
There are 4 scenarios possible

1:1 payments - currently implemented

1:n payments - could be done by allowing to submit a list of issuer/amount/currency/paths instead of a single instance of these, probably needs to be applied in order and should atomically fail if any sub-payment fails for any reason (e.g. dry paths)

n:1 payments - would require serious custom logic (you are describing sending out multiple different currencies, not receiving them from multiple different accounts atomically at once). Would be probably doable with muti-signing (all inputs to the transaction must be validly signed by whatever method is possible for each sending account). Should also fail atomically (one input can't be applied - e.g. because there is no trust line - no value gets transferred at all).

m:n payments - while kinda combining the two concepts above, it maybe could be necessary to also have some logic to deal with paths. I haven't fully thought this one through if it would be just a logical next step or if there's some fundamental problem hidden somewhere (I suspect paths could be a bit problematic if they are not supplied with the transaction).

@yxxyun

This comment has been minimized.

yxxyun commented May 17, 2018

https://www.stellar.org/developers/guides/concepts/transactions.html

Transactions contain an arbitrary list of operations inside them. Typically there is just one operation, but it’s possible to have multiple (up to 100). Operations are executed in order as one ACID transaction, meaning that either all operations are applied or none are. If any operation fails, the whole transaction fails. If operations are on accounts other than the source account, then they require signatures of the accounts in question.
Here are the possible operation types:
Create Account
Payment
Path Payment
Manage Offer
Create Passive Offer
Set Options
Change Trust
Allow Trust
Account Merge
Inflation
Manage Data

@tuloski

This comment has been minimized.

tuloski commented May 17, 2018

@MarkusTeufelberger yeah, that is only one of the applications. But the multi-transaction could solve much more applications.
And as pointed by @yxxyun it seems stellar is already supporting it.

@nbougalis nbougalis changed the title from [ENH] Proposal: multi-transaction to Proposal: multi-transaction Nov 1, 2018

@whotooktwarden

This comment has been minimized.

whotooktwarden commented Nov 14, 2018

I would like to be able to submit a multi-transaction where an account may take the output of noripple_check to then be able to use the transactions array provided to then attempt to set the affected accounts with the ClearNoRipple/SetNoRipple flag. This would especially help people lower their owner count/owner reserve. I would prefer that if this were to be implemented, if a transaction were to fail perhaps due to an insufficient reserve, then to continue onto the next transaction in the array and report an array of error codes if any occurred. Thanks for your consideration on this use case of multi-transaction's potential functionality.

@sublimator

This comment has been minimized.

Contributor

sublimator commented Nov 14, 2018

@nbougalis

This comment has been minimized.

Member

nbougalis commented Nov 14, 2018

This is on our roadmap, but I don’t have a specific timeframe.

@whotooktwarden

This comment has been minimized.

whotooktwarden commented Nov 14, 2018

I would love to be able to send an "agenda" transaction that allows me to apply specific types of other ripple transactions which will either a) attempt to submit & verify the transaction, if an error occurs create an array of errors to report at the end of processing or b) if an attempt to submit a transaction is verified to have failed with an error message then the agenda transaction fails and no other transactions intended for submission are attempted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment