Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited


About EdH

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Occupation
    Code Monkey

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That's an interesting idea, but what would be the advantage for the user over grabbing the toml file over on bitstamp.com?
  2. No promises on when it'll happen, but we'll be working on getting more fee & queue info into the server stream. That's because it happens during the processing of the validated ledger, which is not necessarily tied to ledger closing. A bit. Not sure what to do about it yet, but a bit.
  3. Basically, ya. Those fields are already exported by the RPC "fee" command. Which datadump are you referring to?
  4. Close, but not quite. The "10"s are the first "limit" transactions only needing to pay 10 drops to get into the open ledger. Generally, those are coming from the queue, taking the transactions with the highest fee first, but if the queue is empty, or doesn't have enough to hit the "limit" any new transactions will also only need to pay 10 drops. * Disclaimer: Any time I say 10 drops, that assumes a standard single signed transaction. Multisigned and some other transactions have a higher base fee, so everything scales up.
  5. Predicting the fee for 100 transactions is simple math, as outlined at https://github.com/ripple/rippled/blob/master/src/ripple/app/misc/FeeEscalation.md "( lastLedgerMedianFeeLevel * TransactionsInOpenLedger^2 / limit^2 )" The limit is not fixed, though it tends to stay around 50 these days, because 50 is the target. The median fee is also not fixed, but is has a minimum of 5000. So say the median fee is 5000, and the limit is 50, the 100th transaction will cost 5000 * 100^2 / 50^2 = 20000 drops. But, you may ask, then how did the fees get into the multiple thousands of XRP? Boy, that's a great question. The answer is that the limit was much lower, because the network was performing so slowly. If it was 10, then the 100th transaction would cost 5000 * 100^2 / 10^2 = 500,000. And some nodes had waaaaay more than 100 transactions. To answer your other question, the local load is completely independent of the open ledger fee. That's the "load_factor_server" value. I generally ignore it when I'm talking about the queue, because they're independent, but strictly speaking, to be considered at all, a transaction must pay at least as much as both the load_factor_server and load_factor_fee_queue.
  6. What you're seeing in the server stream is actually very similar to what comes back from the server_state RPC command { "type": "serverStatus", "base_fee": 10, "load_base": 256, "load_factor": 132970, "load_factor_fee_escalation": 132970, "load_factor_fee_queue": 256, "load_factor_fee_reference": 256, "load_factor_server": 256, "server_status": "full" } vs { [...] "load_base" : 256, "load_factor" : 142081, "load_factor_fee_escalation" : 142081, "load_factor_fee_queue" : 256, "load_factor_fee_reference" : 256, "load_factor_server" : 256, [...] } There's a base_fee in there somewhere, too. What you're seeing with each update is the open ledger fee changing with each transaction that bumps it over the default. So your formula to calculate the open ledger fee is correct: "base_fee * load_factor / load_base". And the minimum fee to get into the queue is "base_fee * load_factor_fee_queue / load_base". As for an algorithm, if you want to get into the open ledger, pay more than the open ledger fee*. If you want to get into the queue, pay somewhere between the minimum fee and the open ledger fee. The more you pay into the queue, the more likely you'll be included in the next ledger. * There is a risk that a transaction will come in from the network and be processed before yours, in which case you'll be at or near the front of the queue. You can pad your fee to help your odds. No promises, but I'll start looking into how feasible it would be to include some of those fee factors in the stream so you could potentially pad yourself to see exactly how much you'd need.
  7. Yeah, you've pretty much nailed the problem set, and we are working on solutions now.
  8. You're welcome. It's less about who last worked on it, and more that nobody has worked on it in a while.
  9. 2c. Woops. I forgot to include the other way to get the open ledger fee. The other is to use the rippled RPC `server_info` command. If the load and/or open ledger fee are raised, then there will be one or more `load_factor` values. Multiply those values by the base fee (eg. 10 drops for single-signed). `load_factor` itself is the highest of all the values and will be most likely to get into the open ledger. `load_factor_fee_escalation` is just enough to meet the fee escalation requirement. `load_factor_server` represents the local and/or network load portion. One may be higher than the other depending on both local load, and the size of the open ledger, and you may be able to ignore `load_factor_server` if you have an admin connection.
  10. Hi, @tulo. Thanks for the questions. I'm going to skip this one, since RippleAPI is not my area of expertise. (a) The open ledger fee is calculated based the local "expected ledger size", number of transactions _currently_ in the open ledger, and the median fee of the last validated ledger (subject to a minimum). Others have posted the link to the dev documentation, but I'll include it again, because it really does go into a lot of detailed explanations of both the math and the motivations. In short, though, for the first "expected ledger size + 1" transactions, the open ledger fee is the same as the base fee (ie. 10 drops). After that, the open ledger fee is calculated as { median fee * square(current number of transactions) / square(expected ledger size) }. (b) Each node calculates its open ledger fee independently, because each node has its own open ledger. The network should _generally_ have the same open ledger across all nodes, but even under optimal conditions, there will be a few differences here and there. In particular, if an attacker launches a flood attack against a single node, that node can respond *immediately* by raising its local open ledger fee without having to wait for consensus or any other communication. This either makes the attack more expensive _quickly_, or puts the rest of the attacker's transactions into the queue, allowing _other_ transactions to continue processing. (c) There are two ways to get the open ledger fee. One is the `fee` command, which returns a bunch of stats about what's going on in the queue and open ledger. See the dev documentation for the details about each field. Note that the `drops` values are only for a reference (single signed) transaction, and that it include a minimum value - you can pay a fee between the minimum and open ledger to get into the queue, and likely into the next few ledgers (once the current issue is resolved). (a) If it pays equal or greater than the current open ledger fee, it will go into the open ledger. If it pays less, it will go into the queue. (b) Validators and non-validators behave identically in this aspect, so it makes no difference. (a) The queue is local to each node, just as the open ledger is local to each node. Optimally, since queued transactions are broadcast to other nodes, all nodes will stay close to identical. (b) If you configure your local node / validator to have different settings for the queue, then your queue and/or open ledger can diverge from the rest of the network. What happens as a result of that will depend on what you change. In your example, if you allow more transactions to queue than default, then the first 10 will be queued by other nodes, and the remainder will be dropped. However, they should stay happily on your local node unless something causes them to expire (eg. `LastLedgerSequence` passes). Eventually, sometime after those first 10 get processed by other nodes, the remainder will be broadcast, and the next 10 can get into other queues. What you describe in this question is basically an attack, so it will be treated that way. Your 0 XRP fee transactions will be almost immediately rejected by every other node on the network. In addition, if your node keeps up that behavior, your node will eventually be cut off by other nodes so you won't be able to connect and/or submit further transactions for some time. I don't know the detailed answer to this question, but in short, yes most or all of these things factor in to it. local_load and local_fee predate the open ledger fee, and are completely independent. They are another mechanism to protect an individual node from other types of attacks. I'll note that if you run your own node, and (carefully) set up an admin connection, IIRC, you can bypass the local fee restrictions. All transactions have an exact `fee` field set. The network doesn't know or care if you use a tool or service to set that fee for you, as long as the transaction is properly signed. If that fee is not enough to get the transaction validated, it's as if the transaction doesn't exist. No fee will be claimed until the transaction is validated. More likely, any nodes that see the transaction will drop or ignore it, much as described in 5. In general, there are basically only two ways that a fee can be claimed: once the transaction is in a ledger (and specifically validated) with a `tesSUCCESS` or any `tec` result, it will either claim the entire fee, or if your XRP balance isn't enough to cover the fee, it'll claim your entire XRP balance. Any other condition takes no fee, again, because there is no transaction. I can't speak to how maxFee works in RippleAPI, but I can tell you under the hood that whatever it does it's either not going to create a transaction, or it'll create one with a `fee` field, as described in 8. above. I can't answer questions about "better" for you, because that is going to depend on your specific requirements and expectations for any given transaction.
  11. Yes. You can do that now with a script submitting those same transactions to multiple nodes. However, those nodes will see your script / rippled is not behaving and will cut you off.
  12. That's basically the algorithm we used to have before fee escalation was enabled. Without going into details, it was cheaply exploitable.
  13. I can't make any promises, but what RippleAPI features are missing that you would like to see? The instructions included in the README should be fully cross-platform if you use cmake. If you don't, you'll have to adapt them to whatever you're using. We love Pull Requests! Yep! (No promises on the time frame yet, but it's near the top of my backlog.)
  • Create New...