[BUG] Transaction Processing Order.

Technical questions about the Ripple API, the protocol, etc.

[BUG] Transaction Processing Order.

Postby ripplerm » Sun Mar 15, 2015 6:06 pm

For fairness, transactions-set should be applied onto a ledger in a "unpredictable" way.

as pointed out by donch in an earlier post, the 'randomly-deterministic' rule is:
The previous ledger hash is used as a salt that gets XOR'ed with the transaction's account and this is the first key in the sort of the ordered map. Transactions with the same account are then ordered by their sequence number.

and the related code can be seen: https://github.com/ripple/rippled/blob/ ... cpp#L79-81


However, there seems to be a flaw in the LegerConsesus code, that when applying a consensus-set to a ledger,
only retriableTransactions were ordered with this rules of CanonicalTXSet.... meaning those txns who succeed during the 1st pass were being applied in exactly same order as they were in the consensus-set, i.e. only ordered by their Txn-Hash.

the flaw is heavily gamed by some trading-bots out there...
By submitting txns with lower hash, they could easily get a better placing in the queue.
Last edited by ripplerm on Sun Mar 15, 2015 6:12 pm, edited 1 time in total.
ripplerm
 
Posts: 260
Joined: Tue Jan 21, 2014 4:10 am

Re: [BUG] Transaction Processing Order.

Postby Sukrim » Sun Mar 15, 2015 6:10 pm

I personally would love to see validators simply disagreeing with each other on the ordering from time to time (if the ordering is not clear - randomize with a local RNG) and to solve this via Consensus instead of having a fancier algorithm that could be gamed.
Sukrim
 
Posts: 1810
Joined: Mon May 20, 2013 10:44 am

Re: [BUG] Transaction Processing Order.

Postby ripplerm » Sun Mar 15, 2015 6:21 pm

BTW, in seems that when creating CanonicalTXSet object of retriableTransactions , it is the hash of Consensus-set being used instead of PreviousClosedLedger.

this looks good, it makes the rule less game-able, IMO.
ripplerm
 
Posts: 260
Joined: Tue Jan 21, 2014 4:10 am

Re: [BUG] Transaction Processing Order.

Postby ripplerm » Mon Mar 16, 2015 10:05 am

ripplerm
 
Posts: 260
Joined: Tue Jan 21, 2014 4:10 am

Re: [BUG] Transaction Processing Order.

Postby ripplerm » Wed Sep 02, 2015 6:02 am

ripplerm
 
Posts: 260
Joined: Tue Jan 21, 2014 4:10 am

Re: [BUG] Transaction Processing Order.

Postby JoelKatz » Wed Sep 02, 2015 7:40 am

This is a very well-known issue at this point. Solving it is just a matter of prioritization. In a liquid market, this isn't exploitable, and on an asset with a transfer fee, this isn't exploitable. It's a bit complex to resolve because the randomization has to be based on the hash of the consensus set, and because that information isn't stored, a naive solution would make ledger replay impossible.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA

Re: [BUG] Transaction Processing Order.

Postby Sukrim » Thu Sep 03, 2015 3:34 am

This enables front-running... how is this not exploitable in a liquid market if I can squeeze in orders before bigger orders even if I send my transaction AFTER the bigger one?

Edit:

For the record, I reported this years ago:
https://bitcointalk.org/index.php?topic ... msg1830309 (April 2013!)
if you sort by hash, you again create some kind of mining as there might be different ways to construct a transaction with lower hashes.
Sukrim
 
Posts: 1810
Joined: Mon May 20, 2013 10:44 am


Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest