Let's talk about Autobridging as a way to improve liquidity

[pc]

if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.

However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??

A database needs to be ACID so no one should end with an unwanted asset. If the order is snatched in an intermediate market it can't be allowed be taken some time after by anyone else as that order doesn't exist anymore. It's a different order now. However that will only be updated on the next 3 seconds right (next block)?

Unless teh exchange is overloaded with people I dont think this could happen, otherwise that would have caused a problem already with people taking the same order at the same time.

The database is atomic out of the fact that it is single-threaded and uses the LMAX technology ..
But another trader's order in one of your intermediate markets could have been executed in the same block before your set of orders simply because it reached the current block producer first ..
then you might end up in an intermediate asset ..

This could probably be prevented as described above .. I'll add a github issue for it
https://github.com/cryptonomex/graphene/issues/609

Is this problem solved?

The problem has never existed, see my post above for a solution.

[paisea]

if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.

However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??

A database needs to be ACID so no one should end with an unwanted asset. If the order is snatched in an intermediate market it can't be allowed be taken some time after by anyone else as that order doesn't exist anymore. It's a different order now. However that will only be updated on the next 3 seconds right (next block)?

Unless teh exchange is overloaded with people I dont think this could happen, otherwise that would have caused a problem already with people taking the same order at the same time.

The database is atomic out of the fact that it is single-threaded and uses the LMAX technology ..
But another trader's order in one of your intermediate markets could have been executed in the same block before your set of orders simply because it reached the current block producer first ..
then you might end up in an intermediate asset ..

This could probably be prevented as described above .. I'll add a github issue for it
https://github.com/cryptonomex/graphene/issues/609

Is this problem solved?

[cube]

bump.

[xh3]

Locking the whole transaction seems unlikely, so maybe this could be implemented without a guarantee of success with the lack of certainty being the cost of the function.  maybe with estimated probability of success within a certain price range to perform the operation.   such as 90% certainty within 1.5% of target price... computed based on amount of steps and adjacent orders on the books.

[noisy]

bump :)

[pc]

This could solve the over filling issue (I mean if there is better price than you want).
But how about partial filling?

Partially filled orders are not completely filled and will trigger an exception if the fill_or_kill flag is set. See limit_order_create_evaluator::do_apply and database::apply_order .

Is that really true? Arent they independently evaluated and in a chain of orders that breaks in the middle everything after the crack will be killed but all the orders before are filled.

Kill-fill flag is for ops .. not for transactiosn .. what am i missing here

If any of the operations in a transaction throws an exception during evaluation, the whole transaction is rolled back. (More precisely, it is only committed when no exception is thrown, see database::_generate_block)

Edit: ... oh .. going via temp account is a great idea .. that fixes a lot!

Well, yes. I attempted to create such a transaction manually and found that it's a real PITA because you essentially have to apply the full market logic with all kinds of fees etc to make sure that the TEMP_ACCOUNT ends up empty. Doable, but definitely not simple.

[xeroc]

I think it's even simpler than that. Just put all required orders into a single transaction and set the fill-or-kill-flag for each of them. Then if any of the orders isn't filled the whole tx will fail.

Is that really true? Arent they independently evaluated and in a chain of orders that breaks in the middle everything after the crack will be killed but all the orders before are filled.

Kill-fill flag is for ops .. not for transactiosn .. what am i missing here


Edit: ... oh .. going via temp account is a great idea .. that fixes a lot!

[abit]

I think it's even simpler than that. Just put all required orders into a single transaction and set the fill-or-kill-flag for each of them. Then if any of the orders isn't filled the whole tx will fail.

This could solve the over filling issue (I mean if there is better price than you want).
But how about partial filling?

[pc]

I think it's even simpler than that. Just put all required orders into a single transaction and set the fill-or-kill-flag for each of them. Then if any of the orders isn't filled the whole tx will fail.

[abit]

How about that:

• Move n A from user account into TEMP_ACCOUNT
• Trade A->B
• Trade B->C
• Move m C from TEMP_ACCOUNT to user

If any one of the trades is filled only partially then the next step will fail and the transaction will be rolled back.
The downside is that if the user gets a better deal than expected at some point, the TEMP_ACCOUNT will end up non-empty and the TX will also be rolled back.

Trade contains 2 steps, place order+fill order. Only place order is in transaction. You can't get another asset immediately after placed the order. So step 3 will fail.

Are you sure?

AFAICS order matching takes place during the evaluation of order_create and includes modification of the account balances. So after the evaluation of step 2 the TEMP_ACCOUNT should already have been credited with B.

It turns out that you are right. We can do it. @xeroc?

//update: I think assert operation is even better.

//update 2: best if result of an op can be used to calculate input of next op. Is it possible?

[pc]

How about that:

• Move n A from user account into TEMP_ACCOUNT
• Trade A->B
• Trade B->C
• Move m C from TEMP_ACCOUNT to user

If any one of the trades is filled only partially then the next step will fail and the transaction will be rolled back.
The downside is that if the user gets a better deal than expected at some point, the TEMP_ACCOUNT will end up non-empty and the TX will also be rolled back.

Trade contains 2 steps, place order+fill order. Only place order is in transaction. You can't get another asset immediately after placed the order. So step 3 will fail.

Are you sure?

AFAICS order matching takes place during the evaluation of order_create and includes modification of the account balances. So after the evaluation of step 2 the TEMP_ACCOUNT should already have been credited with B.

[xeroc]

BUT, in contrast to Ripple, BitShares won't be able to guarantee atomic trades across several markets. Even though you could put multiple order operations into a single transaction .. and could even use the "fill-or-kill"-flag (already available today) .. if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.

However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??

Aren't transactions all-or-nothing? In that case you'd "only" have to construct a transaction that fails in the last step if not everything went as planned. Perhaps using the assert operation? Or with the temporary account?

I'm sure there is a way to do that without a hardfork, and without additional load on the witness nodes.

Fill_order is virtual operation, which is out of the transaction's control. So I don't think assert_operation will help much here.

You can set fill/kill flag for order OPS! not for the whole transaction. That ia the issue

[abit]

How about that:

• Move n A from user account into TEMP_ACCOUNT
• Trade A->B
• Trade B->C
• Move m C from TEMP_ACCOUNT to user

If any one of the trades is filled only partially then the next step will fail and the transaction will be rolled back.
The downside is that if the user gets a better deal than expected at some point, the TEMP_ACCOUNT will end up non-empty and the TX will also be rolled back.

Trade contains 2 steps, place order+fill order. Only place order is in transaction. You can't get another asset immediately after placed the order. So step 3 will fail.

[pc]

How about that:

• Move n A from user account into TEMP_ACCOUNT
• Trade A->B
• Trade B->C
• Move m C from TEMP_ACCOUNT to user

If any one of the trades is filled only partially then the next step will fail and the transaction will be rolled back.
The downside is that if the user gets a better deal than expected at some point, the TEMP_ACCOUNT will end up non-empty and the TX will also be rolled back.

[abit]

BUT, in contrast to Ripple, BitShares won't be able to guarantee atomic trades across several markets. Even though you could put multiple order operations into a single transaction .. and could even use the "fill-or-kill"-flag (already available today) .. if someone snatches an order in an intermediate market .. you will end up with an asset that you might not have wanted.

However .. if there was a new feature (read: network upgrade, a.k.a. hardfork) .. that either executes ALL or NO operation in a transaction .. that could help .. but I don't really know if that can be easily intergrated given that you can also have partial fills etc .. @abit ??

Aren't transactions all-or-nothing? In that case you'd "only" have to construct a transaction that fails in the last step if not everything went as planned. Perhaps using the assert operation? Or with the temporary account?

I'm sure there is a way to do that without a hardfork, and without additional load on the witness nodes.

Fill_order is virtual operation, which is out of the transaction's control. So I don't think assert_operation will help much here.