Jump to content

A XRPLedger system problem(bug)! (You need some programming knowledge to understand what I'm talking about).


Recommended Posts

XRPLedger system has a problem.

The orders are not being filled in order of time sequence exactly!

And somebody is taking advantage of it, cheating!

This "somebody" is r3Vh9ZmQxd3C5CPEB8q7VbRuMPxwuC634n .

I noticed something's wrong about a couple of days ago, sometimes after I bought some XRP at lowest sell price, the remain amount of the sell order didn't change at all, I went to track the transactions, turned out I bought those XRP from other account, That "other account" created its sell order at the exect same time when I created my buy order, exact same amount with a little bit lower price than exist sell order. I thought it was a coincidence but it keeps happening and very frequently! I'm sure he's using some script to track orders through XRPLedger API, when there's a new buy order, he create a sell order(same amount, a little bit lower price than exist sell order) immediately.

Here is the problem, the timestamp which XRPLedger system sort the orders with is not precise enough, sometimes the new sell order he created after my buy order is considered being created before my buy order! Then his order get filled instead of the sell order which is already exist!

This is NOT FAIR to other traders!

Check these transactions out:

1. rnAHo4WfTcmbvwKPuKRyvAFPiDEznJJSxq created a sell order(Sell 600 XRP for 471.6 USD, rate: 0.786 USD/XRP), at Jan 17, 2022, 08:07:41 AM UTC.

Here is the transaction:

https://xrpscan.com/tx/755FC98A21061783F789371D31717A015C79E59F173897F0A793867935832FE3

 

2. rNyLHfhTomKQtVqYfb15P5vgLkR5XRSGM2 created a buy order(Buying 9.498246 XRP for 7.68959 USD, rate: 0.80958 USD/XRP), at Jan 17, 2022, 08:15:02 AM UTC.

Here is the transaction:

https://xrpscan.com/tx/103DD748E2AB668D566B3FAFFEF4D6B68ACB7714CA0A3249DA19DF3C50F4A842

you can see more trading details here:

https://xrpcharts.ripple.com/#/transactions/103DD748E2AB668D566B3FAFFEF4D6B68ACB7714CA0A3249DA19DF3C50F4A842

 

3. r3Vh9ZmQxd3C5CPEB8q7VbRuMPxwuC634n created a sell order(Sell 9.498246 XRP for 7.465558 USD, rate: 0.785993 USD/XRP), at Jan 17, 2022, 08:15:02 AM UTC.

Here is the transaction:

https://xrpscan.com/tx/4CD274844035841343CD53B3528C2C8F851FD948B9838164CDAF8D46359F877D

You can see the time stamp is same as buy order above, it's not precise enough! He created this sell order after the buy order, but, because the timestamp is same, XRPLedger system mistakenly considered that his order is created before the buy order, then, his order GOT FILLED FIRST!

 

Whoever owns account r3Vh9ZmQxd3C5CPEB8q7VbRuMPxwuC634n, is cheating like that all the time! Even now! If you have a gatehub account, you can go check it out, it happens very often.

--------------------

Btw, I reported it Unusual Activity to ripple about 2 weeks ago, still no any response. Guess I'm being ignored. No idea why ripple ignore such problem.

So sad. Someday, XRPLedger trading system will be full of cheaters.

--------------------

Edit: I think I have to add this because I'm receiving many unrelated replies.

I just want to point out XRPLedger system is getting some "last come first serve" things going on, I'm not here to talk about what's wrong with the source code of XRPLedger system, or how to fix it, etc. If I want, I would post it to somewhere else for ppl who have professional knowledge. I can't stop what ppl gonna post, and I'm not attempting to, but please make sure you understand programming and how database works before you post something like that.

Edited by justfal1116
Link to comment
Share on other sites

OK, so it's just market manipulation, this happens every time (every nanosecond) in every market.

This happens to the stock market, the bullion market, the bond market, the forex market and other markets.

Link to comment
Share on other sites

When looking at the trades from r3Vh9ZmQxd3C5CPEB8q7VbRuMPxwuC634n is doesn't seem like market manipulation to me. It's just a market maker, maybe market taker, continuously providing offers in the orderbook.

Also the front-running imo is very hard to let take place on XRPLedger. Trades are not executed on the order of first offer basis. With XRPLedger transactions are gathered during a certain time window (+/- 4 seconds). After that the transactions selected to be included in that ledger are ordered according to a randomization algorithm based on the tx hashes, meaning it is very hard to have your transaction placed in front of another transaction. You can't know at which place your tx will be executed. Although I have heard from some (rubble labs?) that it would be possible. I think with some trial/erroring-playing with the tx hash value, might get you in front, but I think it's really hard.

But for this account, just check at https://xrpscan.com/account/r3Vh9ZmQxd3C5CPEB8q7VbRuMPxwuC634n I don't see that as front-running or market manipulation, just providing continuously orders to the order book based on some calculation, maybe based on a price taken from a CEX

Link to comment
Share on other sites

1 hour ago, jn_r said:

With XRPLedger transactions are gathered during a certain time window (+/- 4 seconds). After that the transactions selected to be included in that ledger are ordered according to a randomization algorithm based on the tx hashes, meaning it is very hard to have your transaction placed in front of another transaction. You can't know at which place your tx will be executed.

On top of that a single TX could be multi-hop and all hops execute in the same ledger close, along with all the other unrelated TXs included in that ledger close. There was talk about how this batch processing method, foils HFT guys a while back. 

That said, there are likely arbatrage opportunities between last/next closed ledger to sort out, but there is risk there also. They just made a change to the Pathfinding algorithm that when I read it, my first thought was that it opens the door a little bit wider for one method.

Remember the 4 second ledger close "speed limit"? You can go faster than that Routing computation. There would still be risk though.

Link to comment
Share on other sites

Well, how to take it is up to you.

A trading system should make sure the orders get filled by in order of time sequence exactly.

As I posted, before that new sell order was created, he has to get newly created buy order through API, then, he go through API again to create it(his sell order). This is NOT "At same time", a system can totally put that new sell order after buy order!

But XRPLedger system didn't. So it is a system problem.

What if it happens in rl? Somebody just take your customer over and over like that, How do you react?

 

I don't know about other markets' system, if they got same problem, means they are not doing it right too. It doesn't mean it's not bad.

Edited by justfal1116
Link to comment
Share on other sites

2 hours ago, justfal1116 said:

Well, how to take it is up to you.

A trading system should make sure the orders get filled by in order of time sequence exactly.

As I posted, before that new sell order was created, he has to get newly created buy order through API, then, he go through API again to create it(his sell order). This is NOT "At same time", a system can totally put that new sell order after buy order!

But XRPLedger system didn't. So it is a system problem.

What if it happens in rl? Somebody just take your customer over and over like that, How do you react?

 

I don't know about other markets' system, if they got same problem, means they are not doing it right too. It doesn't mean it's not bad.


Did you see the bit about hashing that means it is difficult (impossible?) to ensure you can front run?

It looks like your view was that it’s a real-time centralised exchange when actually it’s something completely different and outside your paradigm.  
 

So no, it’s not “bad”, it’s just different from a fibre connected centralised exchange.

 

Edited by BillyOckham
Link to comment
Share on other sites

There is an issue with chronologic ordering because blockchain is all public. Also the 'pending tx pool' (in ethereum sometimes called the darkpool/forest) is visible for everyone. What we are seeing now in Ethereum is that this dark pool is exploited by 'searchers', looking for an opportunity where they place a trade just in front of another trade, or right behind, or sandwich, several possibilities exists to scr*w with some of the 'honoust' transactions waiting to be included in the next block. The ultimate beneficials are the miners, because they can determine which transactions are added and in which order to the next block. As matter of fact, they are now requesting a 'bribe' from the searchers so that their transactions are included. As you can imagine, this drives in the end all the profitability to the miners. The searchers being the puppets of the miners, getting some crumbs of the leftover profit. This is what they call MEV: Miner Extractable Value.

XRPLedger does it different. First of all, not 1 miner decides on the (order of) transactions in a block, but all validators (34 currently) simultaneously. There is no cheating possible, everyone must agree on which transactions are included and in which order they are included. The order, as explained earlier, made as random as practically possible. This gives a system that, at least in my view, is more honest than e.g. the ethereum system.

A system where incoming transactions are taken based on time would be maybe even more honest, but that is practically very difficult to achieve in a decentralized world, as not all nodes in a blockchain have the same time, network might be slow in certain parts of the network, etc.. 

Link to comment
Share on other sites

16 hours ago, BillyOckham said:


Did you see the bit about hashing that means it is difficult (impossible?) to ensure you can front run?

It looks like your view was that it’s a real-time centralised exchange when actually it’s something completely different and outside your paradigm.  
 

So no, it’s not “bad”, it’s just different from a fibre connected centralised exchange.

 

A no for you. It is in my paradigm, I am a senior system engineer, I know how it works.

Base on what you wrote in your comment, I guess you don't have any knowledge about how a system works. It's outside your paradigm on the contrary.

Real-time centralized exchange? Fiber connected centralized exchange? Come on man, we are talking about XRPLedger system itself, it's like how did you come up with those things.

Anyway, I'm not having a argument with you about it, I'm telling you it is XRPLedger system's bad.

I see you still think it is impossible to sort those 2 orders in chronological order(guess you didn't read my comment carefully). As a system engineer, I can tell you it is definitely possible, not difficult at all(I've explained why). XRPLedger system is just using a imprecise timestamp.

PS: I think it is not necessary to talk about that "last come first serve" thing, I suppose you know it is bad too.

Edited by justfal1116
Link to comment
Share on other sites

16 hours ago, jn_r said:

There is an issue with chronologic ordering because blockchain is all public. Also the 'pending tx pool' (in ethereum sometimes called the darkpool/forest) is visible for everyone. What we are seeing now in Ethereum is that this dark pool is exploited by 'searchers', looking for an opportunity where they place a trade just in front of another trade, or right behind, or sandwich, several possibilities exists to scr*w with some of the 'honoust' transactions waiting to be included in the next block. The ultimate beneficials are the miners, because they can determine which transactions are added and in which order to the next block. As matter of fact, they are now requesting a 'bribe' from the searchers so that their transactions are included. As you can imagine, this drives in the end all the profitability to the miners. The searchers being the puppets of the miners, getting some crumbs of the leftover profit. This is what they call MEV: Miner Extractable Value.

XRPLedger does it different. First of all, not 1 miner decides on the (order of) transactions in a block, but all validators (34 currently) simultaneously. There is no cheating possible, everyone must agree on which transactions are included and in which order they are included. The order, as explained earlier, made as random as practically possible. This gives a system that, at least in my view, is more honest than e.g. the ethereum system.

A system where incoming transactions are taken based on time would be maybe even more honest, but that is practically very difficult to achieve in a decentralized world, as not all nodes in a blockchain have the same time, network might be slow in certain parts of the network, etc.. 

Well, for ppl who don't know how a system works, it is difficult to understand though.

It's very simple actually.

I'm not going to repeat what I said in my last comment. Forget about everything you thought about, just make that timestamp precise enough, boom, problem solved.

Edited by justfal1116
Link to comment
Share on other sites

  • justfal1116 changed the title to A XRPLedger system problem(bug)! (You need some programming knowledge to understand what I'm talking about).
50 minutes ago, justfal1116 said:

Well, for ppl who don't know how a system works, it is difficult to understand though.

It's very simple actually.

I'm not going to repeat what I said in my last comment. Forget about everything you thought about, just make that timestamp precise enough, boom, problem solved.

Since you are a senior system engineer, why not check out the code and make a PR or an issue? Turns out you're not the only one working on the topic of transaction ordening. Although not working on a chronological tx ordering as you wished, but maybe a good starting point: https://github.com/ripple/rippled/pull/4077 Maybe you can chip-in, or otherwise get more acquainted with the why's and the how's and the why not's of XRPLedger.

edit: also a good source for documentation: https://xrpl.org/transaction-queue.html#order-within-the-queue

edit2: a must read if you really want to know how the consensus works: https://xrpl.org/consensus.html

Edited by jn_r
Link to comment
Share on other sites

 

2 hours ago, justfal1116 said:

I'm not going to repeat what I said in my last comment. Forget about everything you thought about, just make that timestamp precise enough, boom, problem solved.

Easier said that done? Not every validator is going to record the same timestamp for various reasons. Speed of light being one. Any alternative system would require a single centralized timekeeper or 100% honest actors, and that's not ideal for a bunch of reasons.

Link to comment
Share on other sites

5 hours ago, justfal1116 said:

I'm not going to repeat what I said in my last comment. Forget about everything you thought about, just make that timestamp precise enough, boom, problem solved.

You're quick to discount everyone else's input, without providing your own suggestions. Just saying "make the timestamp precise enough" isn't a solution, rather it's a lofty goal. Can you suggest even at a high level how you'd consider implementing it, in a decentralized system?

The timestamp reported in your transactions isn't intended to represent the time that the transaction was submitted, it's the timestamp of the ledger close. The transaction could even have been submitted during previous ledgers, so the timestamp could be off by 4 or 8 seconds, or more. So that timestamp isn't really relevant in the ordering at all, except to distinguish between ledger close times.

Link to comment
Share on other sites

On 1/22/2022 at 7:12 PM, justfal1116 said:

As I posted, before that new sell order was created, he has to get newly created buy order through API, then, he go through API again to create it(his sell order). This is NOT "At same time", a system can totally put that new sell order after buy order!

You realise don't you that the various servers hosting the API are distributed, under the control of different organisations, and not necessarily trusted to report the correct time of submission?

Link to comment
Share on other sites

Its a shame you seem so keen to make assumptions about other peoples competence but that’s your own affair and I’m not interested in trying to fix it.

 

7 hours ago, justfal1116 said:

Real-time centralized exchange? Fiber connected centralized exchange? Come on man, we are talking about XRPLedger system itself, it's like how did you come up with those things.

I agree.  That paragraph of mine was clunky.  I was trying to mention some of the confounding factors that make your belief inappropriate for a blockchain DEX.  

The “fibre” word for instance was there to try to imply the timing issues that arise and perhaps jog a memory of the thousands of loops of fibre in the building next to the stock exchange whose only purpose is to slow down comms to stop front running and allow for fair exchange.  Such timing issues and intervals are not appropriate in a granularity of multiple seconds per block.

“centralised” was necessary to show that these two different types of exchanges have completely different opportunities and problems.


A number of very knowledgeable people have tried to help you see the reasons for the way things are but your input filter seems to block you from absorbing it.

 I agree with this portion of a statement of yours…

7 hours ago, justfal1116 said:

Anyway, I'm not having a argument with you about it

So don’t bother showing me how dumb I am…  I already know and I won’t be coming back to this now pointless thread.

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.