Jump to content
Professor Hantzen

Transaction failed with terPRE_SEQ but still executed

Recommended Posts

I made a send recently that had the incorrect sequence number.  It failed with "terPRE_SEQ", as it should have.  I then corrected the mistake, and signed and submitted a new transaction.  This transaction returned "tesSUCCESS".

I then checked my balances.  Two sends occurred.  My second send occurred in ledger_n, and the first (supposedly failed) send occurred in ledger_n+1.

My methodology for sending in this case was vary basic - I literally did these by hand.  I wrote JSON then signed using ripple-lib.  I then copied and pasted the tx_blob into  websocket.org/echo.html connected to wss://s-west.ripple.com:51233, with the command {"command" : "submit","tx_blob" :[tx_blob]}

Is this normal behaviour for the ripple network?  I'd have expected a submitted transaction failing with terPRE_SEQ to not propagate any further - as this one seems to have done.

Share this post


Link to post
Share on other sites

ter Codes

These codes indicate that the transaction failed, but it could apply successfully in the future, usually if some other hypothetical transaction applies first. They have numerical values in the range -99 to -1. The exact code for any given error is subject to change, so don't rely on it.

For your particular ter, if you submitted with a sequence higher than the current and then you reach that sequence it can get executed I think.

Edited by tulo

Share this post


Link to post
Share on other sites

The transaction didn't fail, that particular submission of the transaction failed. A submission can fail for lots of reasons, including that the transaction has already been successfully applied or that a prior transaction hasn't (yet) been applied.

A transaction has not definitively failed until either:

1) You determine that it is malformed.

2) You see a transaction from the same account with the same sequence in a fully validated ledger, or

3) You see a fully validated ledger with a sequence number equal to or greater than the last valid ledger sequence for that transaction and that transaction is not contained in that ledger or any prior ledger.

 

Share this post


Link to post
Share on other sites

Thanks all! I've got a better understanding of this now (and had a read through the documentation).

I wonder - how long could a transaction of this kind (eg, with a sequence 1 or more too high) be reasonably expected to "hang around" on the network?  Is this a potential attack vector in terms of spam?  I'm presuming that had I not submitted the second transaction (and ultimately therefore caused the terPAST_SEQ to become final), could it be assumed the firsts fee would not have been consumed?  If so - what's to stop a malicious actor from sending thousands of such transactions at no expense?

Share this post


Link to post
Share on other sites
18 hours ago, Professor Hantzen said:

Thanks all! I've got a better understanding of this now (and had a read through the documentation).

I wonder - how long could a transaction of this kind (eg, with a sequence 1 or more too high) be reasonably expected to "hang around" on the network?  Is this a potential attack vector in terms of spam?  I'm presuming that had I not submitted the second transaction (and ultimately therefore caused the terPAST_SEQ to become final), could it be assumed the firsts fee would not have been consumed?  If so - what's to stop a malicious actor from sending thousands of such transactions at no expense?

There are many transactions that you can submit to a server and get it relayed to the peers in the network (so it can be used as spam for the whole network without spending XRP), but the servers COULD (as nikb said) drop the transactions or "ban" the malicious user and stop relaying the transaction. But as far as I know there is not such defense implemented...

Share this post


Link to post
Share on other sites
10 minutes ago, tulo said:

There are many transactions that you can submit to a server and get it relayed to the peers in the network (so it can be used as spam for the whole network without spending XRP), but the servers COULD (as nikb said) drop the transactions or "ban" the malicious user and stop relaying the transaction. But as far as I know there is not such defense implemented...

If it's an issue or a threat, than why didn't this happen yet? 
 

Share this post


Link to post
Share on other sites
22 minutes ago, tulo said:

There are many transactions that you can submit to a server and get it relayed to the peers in the network (so it can be used as spam for the whole network without spending XRP), but the servers COULD (as nikb said) drop the transactions or "ban" the malicious user and stop relaying the transaction. But as far as I know there is not such defense implemented...

Ok, well if that's the case - it really has to be.

8 minutes ago, kanaas said:

If it's an issue or a threat, than why didn't this happen yet? 
 

I'd suspect that at the moment Ripple isn't popular or valuable enough to anyone who'd be inclined.  But as soon as it starts carving out of someone else's crypto pie, it likely will be attacked, and if this vector is open it will be used.   Given leveraged derivatives to trade, it becomes attractive even without that motive.  This happened to Ethereum in recent months, spam attacks brought the network to it's knees for several weeks, whilst much was raked in shorting ETH - it had an impact on development, the eco-system and of course, the price.

Share this post


Link to post
Share on other sites

A server will not relay a transaction unless it determines that the transaction is likely to claim a fee. The server cannot make this determination if there is a missing prior transaction because it has no idea how much XRP the account would have left after that transaction. So it will not relay a transaction under those circumstances.

Share this post


Link to post
Share on other sites
4 minutes ago, JoelKatz said:

A server will not relay a transaction unless it determines that the transaction is likely to claim a fee. The server cannot make this determination if there is a missing prior transaction because it has no idea how much XRP the account would have left after that transaction. So it will not relay a transaction under those circumstances.

Do I read this that you do not judge this issue as a potential vector?

Share this post


Link to post
Share on other sites
5 hours ago, JoelKatz said:

A server will not relay a transaction unless it determines that the transaction is likely to claim a fee. The server cannot make this determination if there is a missing prior transaction because it has no idea how much XRP the account would have left after that transaction. So it will not relay a transaction under those circumstances.

So why the first transaction of Professor Hanzen succeeded? I think it is fair to relay those kind of transactions...imagine an account at sequence N, sending for some reason a transaction with sequence N+1 to server A and N+2 to server B. Both are valid and could claim a fee. If server B doesn't relay the transaction and just drop it (because it didn't receive yet transaction N+1 from server A) it's a lost valid transaction.

BTW I think it is not a good idea discuss on a public forum on possible attacks to the network, even if they are absolutely not a threat.

Share this post


Link to post
Share on other sites
15 hours ago, JoelKatz said:

A server will not relay a transaction unless it determines that the transaction is likely to claim a fee. The server cannot make this determination if there is a missing prior transaction because it has no idea how much XRP the account would have left after that transaction. So it will not relay a transaction under those circumstances.

So how long will a server persist such a transaction, waiting for the missing prior transaction(s), if - as in this case - the transaction in question has no LastLedgerSequence provided?  And what affects rippled's choices in this - is it load-dependent, for instance?
 

9 hours ago, tulo said:

So why the first transaction of Professor Hanzen succeeded? I think it is fair to relay those kind of transactions...imagine an account at sequence N, sending for some reason a transaction with sequence N+1 to server A and N+2 to server B. Both are valid and could claim a fee. If server B doesn't relay the transaction and just drop it (because it didn't receive yet transaction N+1 from server A) it's a lost valid transaction.

I think the first transaction succeeded because after being held for one ledger, the second transaction applied, making the first no longer a "terPRE_SEQ" transaction, and so would have been relayed and confirmed when that state changed - in this case, in the subsequent ledger.  As for the second suggestion - exactly - it would be trivial to set this up.

Share this post


Link to post
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

×