Professor Hantzen

Transaction failed with terPRE_SEQ but still executed

23 posts in this topic

On 12/26/2016 at 5:42 PM, 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.

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.

No, both couldn't claim a fee. N+2 cannot, since N+1 hasn't been seen yet. The server will hold on it, because, for all it knows N+1 is coming. In your example, that's exactly what happens: N+1 comes in, and as soon as that's in a ledger, N+2 can apply, so the server that has it puts it in its candidate set, and the transaction is distributed across the network.

tulo likes this

Share this post


Link to post
Share on other sites
10 hours ago, nikb said:

No, both couldn't claim a fee. N+2 cannot, since N+1 hasn't been seen yet. The server will hold on it, because, for all it knows N+1 is coming. In your example, that's exactly what happens: N+1 comes in, and as soon as that's in a ledger, N+2 can apply, so the server that has it puts it in its candidate set, and the transaction is distributed across the network.

So all transactions with ter failures are just kept by the server that received it and not relayed to the network? And as soon as the condition to succeed is met, the transaction is relayed. For how long the transaction is kept? How long is the "buffer" for this kind of transactions, i.e. how many transactions as this can be saved waiting for the condition? Is this "buffer" shared with the queue for the new fee system?

Is it legal to setup an "attack" to the RCL by just spamming transactions, only for scientific tests? :)

Share this post


Link to post
Share on other sites

Is it legal to setup an "attack" to the RCL by just spamming transactions, only for scientific tests?

Why not? It sure is not fraud or stealing / just a very special stresstest. Ripple should rather support it as long as RCL is a de facto testing environment



Verzonden vanaf mijn iPhone met Tapatalk

Share this post


Link to post
Share on other sites

The general assumption is that there's somebody who cares about a transaction and will make sure it succeeds. If not, then nobody particularly cares and it doesn't matter whether it succeeds or not. Relaying a transaction if we are not confident it can claim a fee creates an attack vector. Storing a transaction does not, so long as we are free to drop it. Within these bounds, service is best effort.

If you submit a transaction with sequence N+1 to one server and one with N+2 to another server in rapid succession, the submission of N+2 will ter. It is your responsibility to resubmit the transaction if you care about it, though the server will make an attempt to hold it and relay it when it sees the prior transaction if it can. But you should not rely on other people to pick up your slack.

nikb and Professor Hantzen like this

Share this post


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

The general assumption is that there's somebody who cares about a transaction and will make sure it succeeds. If not, then nobody particularly cares and it doesn't matter whether it succeeds or not. Relaying a transaction if we are not confident it can claim a fee creates an attack vector. Storing a transaction does not, so long as we are free to drop it. Within these bounds, service is best effort.

If you submit a transaction with sequence N+1 to one server and one with N+2 to another server in rapid succession, the submission of N+2 will ter. It is your responsibility to resubmit the transaction if you care about it, though the server will make an attempt to hold it and relay it when it sees the prior transaction if it can. But you should not rely on other people to pick up your slack.

sound reasoning!

Share this post


Link to post
Share on other sites
On 12/27/2016 at 3:29 AM, Professor Hantzen said:

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?
 

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.

I don't know for sure, but my understanding is that rippled caches a small number of transactions that failed with retriable errors (ter* codes) to be reused later. I suspect it's a fixed-size cache so rippled just drops them freely if the cache fills up, according to some simple heuristic like keeping the most recent ones. And of course it doesn't relay the transactions to the network while they're being held in the cache, but it does relay them if they succeed on the retry. So the worst you can do is force other people's temporarily-failed transactions to get dropped from the cache, which is at most a minor inconvenience, and it only affects people using the same rippled server as you. So either you deal with this possibly happening on a shared server, or you run your own rippled and don't have this problem anymore.

The reason this feature exists is to make transaction submission easier for pretty much exactly the case you encountered, except also including the version where constructing and submitting the transactions is done by some automated system instead of by hand. Maybe you have some system that wants to create several transactions from a specific address, and something gets shuffled around so several transactions get submitted out of order but right after one another. (Maybe the http connection for one of them randomly drops and reconnects; maybe you construct the transactions in parallel and one of the earlier ones takes longer -- it doesn't really matter.) If you're running your own rippled server, you don't have to worry about the exact order since it should "just work" if you submit them around the same time.

Professor Hantzen likes this

Share this post


Link to post
Share on other sites
On 12/28/2016 at 11:00 AM, tulo said:

Is it legal to setup an "attack" to the RCL by just spamming transactions, only for scientific tests? :)

Is it legal? Yes, of course. Is it good manners? Certainly not.

I think it's something like banging your fist on shatterproof glass just to test that it's shatterproof. You probably won't break it, but the people nearby still won't be happy that you're going around banging on their windows.

P.S. if you really insist on testing the stability of the network, you should try spamming the testnet first, and publish the schedule of your "attack" in advance. That's at least closer to good manners.

Share this post


Link to post
Share on other sites
On 1/10/2017 at 9:11 PM, mDuo13 said:

I don't know for sure, but my understanding is that rippled caches a small number of transactions that failed with retriable errors (ter* codes) to be reused later. I suspect it's a fixed-size cache so rippled just drops them freely if the cache fills up, according to some simple heuristic like keeping the most recent ones. And of course it doesn't relay the transactions to the network while they're being held in the cache, but it does relay them if they succeed on the retry. So the worst you can do is force other people's temporarily-failed transactions to get dropped from the cache, which is at most a minor inconvenience, and it only affects people using the same rippled server as you. So either you deal with this possibly happening on a shared server, or you run your own rippled and don't have this problem anymore.

The reason this feature exists is to make transaction submission easier for pretty much exactly the case you encountered, except also including the version where constructing and submitting the transactions is done by some automated system instead of by hand. Maybe you have some system that wants to create several transactions from a specific address, and something gets shuffled around so several transactions get submitted out of order but right after one another. (Maybe the http connection for one of them randomly drops and reconnects; maybe you construct the transactions in parallel and one of the earlier ones takes longer -- it doesn't really matter.) If you're running your own rippled server, you don't have to worry about the exact order since it should "just work" if you submit them around the same time.

Thanks, that all makes a lot of sense.

It might therefore be possible to spam all ~100 servers with transactions such as these, and if the rate was constant enough, ter-class transactions could be continually flushed from the network-wide cache(s) for as long as that continued?

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