No sorry this is the price you have to pay to use a decentralized exchange, you always have to wait for the block to be confirmed first. Although I'm not sure if you can broadcast another message to cancel the transaction from being put in a block before the 3 seconds (1.5 sec average) have passed
One could argue that this feature is not useful or it is unnecessary. But i think there is a way to not pay this price.
If there is a cancel_order_by_transaction_id, then it no longer depends on the order id to cancel (which has at least 3 sec delay), since the transaction id is known to the user before he/she sends the transactions.
The chain could have forks, then the order might have different order id in different fork, canceling an order id might not be applied in the end. Cancel_by_transaction_id could in deed complete the cancel in this situation.
It's technically possible to implement, however, not easy based on current infrastructure.
* It's expensive (read: slow) for nodes to undo just one or a few transactions, if there were a lot of transactions in the queue;
* nodes need to make sure the cancellation is requested by the original signer, that said, the cancellation should also be signed, thus need a new verification process.
About usability, due to the 3s block time, it's likely that success rate of cancellation will be low. The cancellation request need to be transmitted through the p2p network, it need time to reach the next block producer. For slow blockchain like bitcoin, such feature would make much more sense.
About security, if this mechanism is in place, it can be used to spam/attack the network with zero cost.
For me, the gain doesn't worth the efforts/risks. Just my own opinion though.
Topic: Cancel a transaction (Read 2472 times)
