Jump to content
karlos

Tell me more about "fee knobs"

Recommended Posts

As I understand, the Ripple validators are running a different code from everyone else? This gives Ripple control over the fees paid by everyone (Im assuming because they are the only true validators)..

How long before this is removed? Is there a schedule or timetable..  I don't think it sets a good example for Ripple to be putting their own personal knobs into the code when they can't fix something quickly enough. Is there someone manning this knob day and night, or could an attacker wait until everyones in bed and crash the network for 8 hours?

If there is a big problem down the track when there's 100 external validators, something like this just isn't going to work. Also in my mind it raises doubts if this is the only change made, or there are others things we don't know about..

Please dispel my (uninformed) negative opinion on this..

Share this post


Link to post
Share on other sites
  • As far as I know, the fee know was fixed at 10.000 drops, and this should make the network safe for a while (but in this way I personally burnt more than 20.000 XRP which is not a small amount).
  • None outside RL will ever know which code the validators are running. And for sure if there is something fishy they won't tell you ;)
  • This is all related to the real decentralization. And I'm worried about this since I would like to see real stress test on a real decentralized network. Otherwise Ripple is worth zero (it's a centralized ledger). I saw decent steps by the decentralization team, but I'm afraid that now they are all involved into ILP :help:

Share this post


Link to post
Share on other sites
2 hours ago, karlos said:

As I understand, the Ripple validators are running a different code from everyone else? This gives Ripple control over the fees paid by everyone (Im assuming because they are the only true validators)..

How long before this is removed? Is there a schedule or timetable..  

Parts are already merged (e.g. here). I don't have a firm date for when it will be deployed, but since it's already in develop, my guess is that it will be deployed soon.

 

2 hours ago, karlos said:

I don't think it sets a good example for Ripple to be putting their own personal knobs into the code when they can't fix something quickly enough. Is there someone manning this knob day and night, or could an attacker wait until everyones in bed and crash the network for 8 hours?

The knob simply sets the floor of the fee that the validators advertise to 1,000 drops - which is why "load_factor_net" is currently 1000 on the network right now. There's no need for anyone to "man" this knob, which also answers the second part of your question.

 

2 hours ago, karlos said:

If there is a big problem down the track when there's 100 external validators, something like this just isn't going to work.

Right. Which is why the new system - code for which I linked above - is automatic: it responds and adapts to load better and faster than the current system.

 

2 hours ago, karlos said:

Also in my mind it raises doubts if this is the only change made, or there are others things we don't know about..

In a previous post on this forum, David said: "I personally approve the code that runs on the validators, and there has never been any kind of backdoor in the code that runs on our validators or other production Ripple servers. There has never been any discrepancy in the public code and the code run on our production servers that affects how transactions are executed, what transactions are considered valid, or anything of that kind. And if there ever was such a thing, it would be easily provable since every transaction's consequences are publicly published in the ledger chain along with the cryptographically-signed transaction that justified them."

Be sure to read that statement again. Not only does David explicitly state that there has never been any discrepancy in the public code and the code that Ripple runs on our production servers that affects transaction execution, validity or anything of that sort, but he explains that the mere presence of such a change running on the validators could be proven by simply replaying a transaction using the version of the code that was running on the network at the time, and producing a different result than what was present in the ledger.

Share this post


Link to post
Share on other sites
20 minutes ago, tulo said:
  • None outside RL will ever know which code the validators are running. And for sure if there is something fishy they won't tell you ;)

The validators are running https://github.com/ripple/rippled/commits/0.30.0-hf1 with the fee knob commit (all 15 or so lines) stacked on top. I know that since I oversaw the deployment of that build.

As I mentioned in my previous post, if the validators were running code that affected transaction execution or validity, it would be a trivial matter to prove that fact.

Share this post


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

The validators are running https://github.com/ripple/rippled/commits/0.30.0-hf1 with the fee knob commit (all 15 or so lines) stacked on top. I know that since I oversaw the deployment of that build.

As I mentioned in my previous post, if the validators were running code that affected transaction execution or validity, it would be a trivial matter to prove that fact.

I don't think it would be trivial :lol:

Let's suppose for example that you want your validators to not accept a particular transaction from a certain account. What if the code of your validators is programmed that it returns a tej_max_fee_exceeded for that transaction? None will ever know if the fee paid was really low or enough for the network load.

And what about  tecINTERNAL  or  tecOVERSIZE ? You could always return this kind of error for a particular transaction and none will ever know why they failed. tecINTERNAL seems exactly an ad hoc error to cover strange behaviors :huh:

Edited by tulo

Share this post


Link to post
Share on other sites
1 minute ago, tulo said:

I don't think it would be trivial :lol:

Oh well... if you don't think so :P

 

4 minutes ago, tulo said:

Let's suppose for example that you want your validators to not accept a particular transaction from a certain account. What if the code of your validators is programmed that it returns a tej_max_fee_exceeded for that transaction? None will ever know if the fee paid was really low or enough for the network load.

You're wrong on multiple counts. If nothing else, tej_max_fee_exceeded is not returned by RippleD; I believe it's returned by ripple-lib.

Share this post


Link to post
Share on other sites
6 minutes ago, nikb said:

You're wrong on multiple counts. If nothing else, tej_max_fee_exceeded is not returned by RippleD; I believe it's returned by ripple-lib.

Yeah sorry that is ripple-lib but what about the other:  tecINTERNAL  or  tecOVERSIZE  (I edited).

And I can add 

tecFAILED_PROCESSING 105 An unspecified error occurred when processing the transaction.

An unspecified error can be anything, that includes: "RL doesn't want this transaction" :)

Edited by tulo

Share this post


Link to post
Share on other sites

tec codes are listed in the ledger. There would be cryptographic proof that the validators encountered an internal error or the metadata was oversized while processing this transaction.

To prove there was mischief, all you need is to compile a server with the version of the publicly available code that the validators claimed to be running, and attempt to replay the ledger that includes the transaction using the code you just compiled. If the transaction succeeds on your server - or produces a different result - then that proves there was a transaction processing difference between the version running on the network and the version you compiled. Q.E.D.

Share this post


Link to post
Share on other sites
5 minutes ago, nikb said:

tec codes are listed in the ledger. There would be cryptographic proof that the validators encountered an internal error or the metadata was oversized while processing this transaction.

To prove there was mischief, all you need is to compile a server with the version of the publicly available code that the validators claimed to be running, and attempt to replay the ledger that includes the transaction using the code you just compiled. If the transaction succeeds on your server - or produces a different result - then that proves there was a transaction processing difference between the version running on the network and the version you compiled. Q.E.D.

Nope, because oversized metadata depends on current ledger, so you can't reproduce it after it was rejected, because the ledger would change and the metadata too.

Moreover I believe tecINTERNAL or tecFAILED_PROCESSING can mean everything, from hardware failures to any kind of error not related to rippled only (maybe in my validator I run other processes and I run out of memory, or whatever). I would need an exact copy of the hardware and software. Not so easy :P

Share this post


Link to post
Share on other sites

 

32 minutes ago, tulo said:

Nope, because oversized metadata depends on current ledger, so you can't reproduce it after it was rejected, because the ledger would change and the metadata too.

You are wrong: if you are replaying the ledger, and the validators claimed that processing the transaction produced tecOVERSIZE but your replay produces, say, tesSUCCESS or some other error (e.g. tecFLUX_CAPACITOR_FAILURE) then you know that there is a transaction processing difference between the code running on the validators and your server - it may be in this transaction or it may be in a previously processed transaction in the same ledger, but there is a transaction processing difference. 

 

32 minutes ago, tulo said:

Moreover I believe tecINTERNAL or tecFAILED_PROCESSING can mean everything, from hardware failures to any kind of error not related to rippled only (maybe in my validator I run other processes and I run out of memory, or whatever). I would need an exact copy of the hardware and software. Not so easy :P

I'm uninterested in what you "believe" and I would prefer it if we stuck to the facts instead. Remember what we're trying to test here: you wanted to determine whether validators can be coded to reject transactions by a particular account in an undetectable way. So simply replay a ledger and if you can produce different results, you've proven there's a transaction processing change between the code that was running on the network and the code you're running.

Let's look at your comments one at a time:

tecINTERNAL is produced if an exception is generated during offer crossing. For the validators to vote the transaction in with tecINTERNAL as the result, it means that a majority of them thew a C++ exception processing the transaction. It's exceedingly unlikely that a majority of validators would suffer such failure while they were processing the exact same transaction, unless that failure was reproducible.

tecFAILED_PROCESSING is, similarly to tecINTERNAL, generated when the server encounters unexpected situations while it attempts to apply a transaction. For example, it can happen if we try to call a function which transfers XRP between accounts, and the amount being transferred would leave the sender with an negative XRP balance, or when offer crossing returns a failure. There's nothing magic about the code itself, nor can servers just generate it magically just because they feel like it. You are reading too much in a description (you cite it as "An unspecified error occurred when processing the transaction." but it has been changed to "Failed to correctly process transaction.") meant for humans.

Let's recap: if the validators claim to be running version a.b.c.d and you can find a transaction which, when replayed, generates a different result while running version a.b.c.d from the public GitHub repo, then get back to me.

Share this post


Link to post
Share on other sites

@nikb thanks for the reply, its making more sense now.. I guess the question I have is, are there ANY other code differences apart from the one we now know about?

I understand that theres none that affect transaction execution/ validity etc which is good. The reason I ask is that if Ripple validators are running different software from everyone else, it can give the impression they might have more influence (which looks bad) or makes the public version seem deficient..

 

Share this post


Link to post
Share on other sites
26 minutes ago, nikb said:

tecINTERNAL is produced if an exception is generated during offer crossing. For the validators to vote the transaction in with tecINTERNAL as the result, it means that a majority of them thew a C++ exception processing the transaction. It's exceedingly unlikely that a majority of validators would suffer such failure while they were processing the exact same transaction, unless that failure was reproducible.

tecFAILED_PROCESSING is, similarly to tecINTERNAL, generated when the server encounters unexpected situations while it attempts to apply a transaction. For example, it can happen if we try to call a function which transfers XRP between accounts, and the amount being transferred would leave the sender with an negative XRP balance, or when offer crossing returns a failure. There's nothing magic about the code itself, nor can servers just generate it magically just because they feel like it. You are reading too much in a description (you cite it as "An unspecified error occurred when processing the transaction." but it has been changed to "Failed to correctly process transaction.") meant for humans.

Let's recap: if the validators claim to be running version a.b.c.d and you can find a transaction which, when replayed, generates a different result while running version a.b.c.d from the public GitHub repo, then get back to me.

Well, tecFAILED_PROCESSING can occur if RippleCalc is taking too many passes to find the payment path, so if you tuned  PAYMENT_MAX_LOOPS (as the fee are tuned differently) it may occur than all RL servers return tecFAILED_PROCESSING while my validator with different parameters accept the transaction.

This is just an example, but I'm not very expert, but I'm sure there are conditions that are hardware-dependent, fee-dependent or parameters-dependent that can justify an apparently failed transaction. So not reproducible by just replaying ledgers and transactions.

Share this post


Link to post
Share on other sites
1 minute ago, tulo said:

Well, tecFAILED_PROCESSING can occur if RippleCalc is taking too many passes to find the payment path, so if you tuned  PAYMENT_MAX_LOOPS (as the fee are tuned differently) it may occur than all RL servers return tecFAILED_PROCESSING while my validator with different parameters accept the transaction.

Right - but that would be a would be a transaction processing change. You can't be surprised if you edit the code code to make transaction processing changes and then transactions are processed differently.

 

5 minutes ago, tulo said:

This is just an example, but I'm not very expert, but I'm sure there are conditions that are hardware-dependent, fee-dependent or parameters-dependent that can justify an apparently failed transaction. So not reproducible by just replaying ledgers and transactions.

So... one of the developers of RippleD is telling you that if the validators running version, say, 0.30.0-hf1-private produced ledger X and you attempt to replay that ledger on a server you compile with the publicly available version 0.30.0-hf1 and get different results for transactions, this indicates that there is a transaction processing change between 0.30.0-hf1 and 0.30.0-hf1-private.

And you - by your own admission a "not very expert" - reply that you're sure that that's wrong.

Uhm... I'm just not sure how to respond to that.

Share this post


Link to post
Share on other sites
16 minutes ago, karlos said:

@nikb thanks for the reply, its making more sense now.. I guess the question I have is, are there ANY other code differences apart from the one we now know about?

I understand that theres none that affect transaction execution/ validity etc which is good. The reason I ask is that if Ripple validators are running different software from everyone else, it can give the impression they might have more influence (which looks bad) or makes the public version seem deficient..

 

With the exception of the fee knob - which is a tiny and trivial patch - the validators are running the same code that is available on the Ripple public GitHub repo. As of the time of this writing, the code is available at https://github.com/ripple/rippled/tree/release and is version 0.30.0-hf1.

Share this post


Link to post
Share on other sites
1 hour ago, nikb said:

So... one of the developers of RippleD is telling you that if the validators running version, say, 0.30.0-hf1-private produced ledger X and you attempt to replay that ledger on a server you compile with the publicly available version 0.30.0-hf1 and get different results for transactions, this indicates that there is a transaction processing change between 0.30.0-hf1 and 0.30.0-hf1-private.

And you - by your own admission a "not very expert" - reply that you're sure that that's wrong.

Uhm... I'm just not sure how to respond to that.

I'm making question exactly because I'm not an expert.

So I can learn more ;). Now everybody reading this topic knows more about rippleD....

Another question @nikb: searching in tec errors I noticed there is not an error for a fee that is too low. This make me think that once the transaction is relayed from a local node (so with that node policy for the fee and load) to the network, the consensus can't block the transaction for the fee too low. Can you say a few words about this? Is the fee escalation only local?

Edited by tulo

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

×
×
  • Create New...