Jump to content

JoelKatz

Ripple Employee
  • Content Count

    851
  • Joined

  • Last visited

  • Days Won

    81

Everything posted by JoelKatz

  1. I'm pretty sure that's just looking at the price some fixed time in the past compared to the current price.
  2. Most crypto markets are open 24/7/365. There is no special time that things happen. But have a look at this page: https://coinmarketcap.com/currencies/ripple/#markets This shows volume and price by market. You'll notice that the top three markets have XRP trading against KRW. They'll be the most active during the times Koreans are most likely to be trading.
  3. Awesome, so it's in there: ... "reserveBaseXRP": "20", "reserveIncrementXRP": "5", ...
  4. I'm not sure what API you're using exactly, but you should have either fields like: "reserve_base_xrp" : 20, "reserve_inc_xrp" : 5 or "reserve_base" : 20000000, "reserve_inc" : 5000000, The top is in XRP, the bottom in drops. The reserve base is the minimum reserve for every account. The reserve increment is the additional amount for each owned object. You can find an account's number of owned objects with whatever version of the "get account info" API you have access to. You should have an "OwnerCount" field that will tell you how many objects that account owns. If all else fails, you can query ledger state entry 4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651 which has the current network fee settings. Some version of this: { " command" : "ledger_entry", "ledger_index" : "validated", "index" : "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651", "binary" : false } Will produce this: "node" : { "BaseFee" : "000000000000000A", "Flags" : 0, "LedgerEntryType" : "FeeSettings", "ReferenceFeeUnits" : 10, "ReserveBase" : 20000000, "ReserveIncrement" : 5000000, "index" : "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651" }
  5. Right, but then you won't see real spikes in traffic level. Maybe you don't want to and would prefer to see more of an average measure. It looks more impressive with larger spikes. Update: Turns out it's a small bug that permits a division by zero to slip through in rare cases. A fix is being tested.
  6. I wonder if they're calculating the TPS rate by looking at the number of transactions in a ledger and the wall time since they saw the last ledger. If you do that, and you happen to get slightly out of sync such that you see two ledgers fully confirm at the same time, you might compute an infinite TPS. There's a trade-off between being as responsive as possible to quick changes in TPS rate and giving accurate values that aren't super-sensitive to precisely when you happened to see a ledger (which isn't really a measure of the network's traffic level). But regardless, suppressing obvious nonsense values is probably a good idea.
  7. In one atomic transaction that both pays and settles, bank A would transfer ownership of the SGD from the sender, bank B would transfer ownership of the THB to the recipient, and the recipient of the SGD would make an XRP payment to the provider of the THB. The party that winds up with the SGD may or may not be the sending bank. The party that previously owned the THB that the recipient now owns may or may not be the receiving bank. The party that provided the XRP was wiling to do so in exchange for ownership of SGD at the sending bank. The party that provided the THB already had THB at the receiving bank that they were willing to sell for XRP. (Or, at least, very "near" the sending/receiving banks.) If the bank is the party providing or accepting the XRP, they are netting out a number of payments and can be periodically rebalancing by buying/selling XRP. It can also be market makers who do the SGD/XRP and XRP->THB conversions. You can imagine a consortium of banks that handle SGD that use domestic settlement between them and have a common path to/from XRP that they use to settle with similar consortia elsewhere. Banks can also just hold XRP and hedge the fluctuation risk. But that's probably not going to be the cheapest solution in the short term.
  8. That's great. Ripple is doing all of those things because they are necessary pre-conditions for Ripple's XRP strategy to work. The more fast and efficient payments are, the more demand there is for rapid settlement. The innovation behind XRP is XRP. Another token would just be another private banking token -- exactly what banks use today, and settlement takes days.
  9. Someone could kidnap my wife and try to compel me to sabotage the lock up in some way. But without knowing the exact time, they'd have to kidnap my wife for months. Best of luck with that.
  10. Thanks. I mean, I don't really need any sleep. Sleep is for the weak.
  11. So there is some seriously horrible code, but it actually works, to analyze the fees transactions are paying. The code is here: https://github.com/joelkatz/rippled/commits/tx_track It's a branch under development, so at times it might not work. But 892a4978b21e4a453742358e3c631de1cfc1854e seems to work. You need to compile and run it, let it sync to the network, and wait about five more minutes for it to gather data. Then issue a "fees" RPC command. You will get additional output like this: What this shows is that we have good data on transactions paying fees from 11-19 drops and they're getting in within 2 ledgers and 6 seconds (from time the transaction is first seen to time it's seen in a fully validated ledger). You can see that 10 drop transactions are confirming in about 6 seconds while 50-99 drop transactions are averaging around 3 seconds. It will produce much better data once we get a "beacon" running. Currently, there aren't that many 10 drop transactions with wide enough validity windows to ensure good data. Anyone should be able to send a stream of 10 drop transactions (say one every 10 seconds) with a ledger validity window of at least 10, ensuring the tool can always accurately measure what happens to those transactions. The counts are low because it only counts "pure" transactions that won't have unusual reasons they might fail. And most 10 drop transactions seem to have very tight ledger validity windows.
  12. This would be the ideal case for XRP as a bridge asset. You don't necessarily need to use XRP as any asset will work as the bridge asset in theory. But there are good reasons why you'd want a single asset to focus the liquidity. There are good reasons that asset should be a digital asset rather than a particular country's fiat. And good reasons XRP should be that asset including its performance, latency, design, and the fact that there's a company with a unique revenue model working to position it that way.
  13. Most validators are still running the old code without the fix. But it doesn't matter. The problem resulted in transactions not getting to the validators and there are now sufficient good paths that the problem could only manifest locally if a single server were jamming. But we've seen no jams on any servers since we cleared the big one. We tend not to upgrade our own validators with new code unless it's absolutely necessary, nor do we recommend others do so until extensive testing can be completed. This is to ensure the stability of the network. The fixed build is still undergoing extensive quality assurance to be absolutely certain it won't harm network stability. Until that's complete, we won't upgrade any more of our own validators, or advise anyone else to upgrade their validators, unless there's some pressing need to do so. Fortunately, this fix doesn't require validator upgrades.
  14. I haven't been watching it very thoroughly, but since we fixed the transaction jam issue, I've seen the TPS rate usually between 8 and 25 and typically hovering around 10-13. Massive spikes are unsurprising though and minimum fee transactions do still get in, usually within 20 seconds or so.
  15. At first, I believed that we had captured enough information from the servers to recover more ledgers. But our recovery efforts stalled at ledger 32,570. Careful analysis of the captured data by both myself and several other people (we made the data public) failed to recover any more ledgers. It's a lot more difficult to recover ledgers than you might think because the only way to know that you accurately recreated a ledger is to check its hash, but that requires the hash of the ledger before it because that goes into the hash.
  16. Great, so now you own some XRP. That's too bad. That means your XRP are now worth less than they were before. Where did the 317 come from? If you bought 281 or 282 XRP, you should still have the 281 or 282 XRP that you bought. I'm not quite sure I follow you. Is XRP now worth more or less than it was worth when you bought it? Are you sure you actually bought XRP and aren't holding a EUR balance at Bitstamp? If you bought XRP and its value when down, you have a loss. Your XRP is now worth fewer EUR than you paid for it. If you held a EUR balance at Bitstamp and the price of XRP went down, you can now buy more XRP for the EUR than you could before. But until you trade, you are holding Euros.
  17. There still might be short term escalations of the fee on a few servers, but overall the network behavior should be normal. The fixed build will be available very shortly and those running the fixed build and submitting to their own servers should be fine. Everyone submitting transactions via any automated process should set a fee limit. You do not need to pay the open ledger fee to get a transaction in -- you can pay a lower fee and it will likely only take you one or maybe two more ledgers for your transaction to get in. The network has sufficient capacity that at least a few minimum fee transactions (10 drops) should get into pretty much every ledger. I would suggest anyone submitting bulk transactions to client handling servers run by Ripple hold off just a bit longer before resuming. It will probably be okay, but there is a small chance that you could wind up causing fee elevation on the server you're submitting to if it hasn't been upgraded yet. Similarly, others might see fee elevation on that server if someone else is submitting heavily to that server.
  18. The rippled server makes outbound connections two ways. One way is based on its configuration. You can configure rippled to prefer to make connections to particular IP addresses and you can configure rippled to insist on making connections to particular IP addresses. The second way is dynamically -- rippled keeps track of servers that it has had stable connections to and will retry those. Since rippled will cut connections to server that send it junk or abuse it, a server that it has remained connected to for a long time is likely to be reliable and stable. Ripple servers aren't that vulnerable to Sybil attacks because the server knows what it's looking for. What it's looking for can't be forged because it's timestamped and signed. And if a server isn't getting what it needs, it will know it. Transactions are currently flooded on the network. That means that if a server sees a transaction it has not seen before that it thinks is likely to claim a fee, it will send that transaction to every server but the one(s) that sent that transaction to it. If you don't allow inbound connections, you will be consuming other server's inbound connection slots while not adding any to the network yourself. This will reduce the network's supply of inbound connection slots. We're a very long way from that being an issue though as there are quite a few "hub" servers that are well-connected and offer enormous numbers of inbound slots. An inbound connection might help you by giving you faster and better access to network information. But if you're poorly or marginally connected, you're probably not helping anyone. By adding traffic to your link, you're probably slowing yourself down and by sending someone else information slowly, you'll probably give it to them after they already have it. Worse, you'll wind up sending them the same information they're sending you and having the same messages cross in flight. We have a proposed design for selective relaying suppression to improve this. The idea is that if you have a peer who always sends you information after you already have it, you squelch them, and they stop sending you stuff. If you ever don't get the information you need, you unsquelch them. This helps to preserve everyone's bandwidth, allowing servers to have many more connections. There are a few technical snags with getting this working well though and we haven't done much work on it in several months.
  19. A server will calculate the open ledger fee based on the number of transactions in the open ledger and metrics based on network performance from the consensus process. It will elevate that fee if it is locally overloaded, but it has no choice in that case. If you are handing it more transactions than it can handle, it has to limit you somehow. That mechanism probably doesn't make much sense anymore. If it's overloaded with valid transactions, the open ledger fee will shoot up anyway. If it's overloaded with invalid transactions, raising the fee won't help since an invalid transaction never pays a fee anyway. In fact, I'm not sure this mechanism still exists in the code. It might have been removed with the fee queue changes.
  20. Your server will only relay a transaction that is likely to claim a fee, unless you modify it to relay "junk". If a server sends too much junk, other servers will close their connections to it. You can still make outbound connections, of course, but servers will limit their inbound connection slots aggressively and drop inbound junk senders very quickly. A validator should not accept inbound connections from unknown sources, so the only way to send it junk is to wait for it to connect to you and send it junk -- but then it will just close the connection.
  21. The theory is that all servers should be seeing substantially the same transaction flow and thus should have fairly consistent open ledgers and thus fairly consistent open ledger fees. We use the flow of transactions that pass consensus, which should be known by every server, as the source of fee metrics. But this event has demonstrated that keeping the open ledgers fairly consistent is not as simple as it seemed. We really want the open ledgers to be consistent for other reasons too (it's essential for consistent relaying and fee replacement) so I think the better plan it work to improve open ledger consistency across the network. That will fix the fee problem and the inconsistent relaying problem. Imagine if some magic made all open ledgers identical across the network. That would mean identical open ledger fees, of course. But it would also mean: 1) Less disagreement for the validators to resolve and thus faster consensus. 2) Consistent transaction relaying as a transaction either would or would not go into everyone's open ledger. 3) Querying the open ledger on any server would give you good idea what the next ledger will look like so you can form payments and offers sensibly. Given these benefits, it's worth putting more effort into getting the open ledgers consistent. We expected the fee queue to do that, and it did until this event happened.
  22. You should keep in mind that this attack vector is only possible on your own validator. You can't launch such an attack on anyone else's validator because you'd have no way to give it transactions that cannot claim a fee. For example, there is no way to get such a transaction to any of Ripple's validators -- they are only connected directly to servers under Ripple's control and they won't relay transactions unless they are likely to claim a fee. You can get similar protection without running additional servers by permitting your validator to only make outbound connections to other servers. Rippled will already sever connections that consistently send you junk.
  23. We now think we understand to root cause of the problem and are finalizing a fix. It's actually kind of an amusing unforeseen chain of things that cause other things to happen and ultimately form a closed loop that can lock the network in a state where very few transactions confirm because very few transactions are confirming. The root cause of the problem appears to be the way the network recovers disputed transactions (ones that were candidates during consensus but didn't garner a majority in the round). The disastrous consequence appears to be servers with large numbers of low-fee transactions in their open ledgers and not in the open ledgers of other servers. This causes inconsistent transaction relaying and artificially high fees.
  24. The short answer is that it's not efficient to settle small payments directly on a public ledger anyway, at least not with today's technology. So they'll use things like payment channels or off-ledger transactions to move the XRP. This is why ILP is such a big part of Ripple's strategy -- there needs to be some way to coordinate transactions that take place on different ledgers to ensure that either everyone gets paid or nobody does. That permits parties that don't trust each other to facilitate each other's payments.
  25. The problem is not the fee level. The fee level is a symptom. There's no evidence that the problem is the result of an intentional attack. It does seem to have been triggered by a recent change in transaction patterns, but there's nothing apparently nefarious about the transaction patterns, they just happen to trigger emergent bad behavior. I'm going to have to be a bit indirect just in case there's anything exploitable here (though I don't think there is) but it seems to be the result of a design decision I made quite some time ago. It was intended to give transactions more equal treatment regardless of where in the consensus timing cycle they were received, but it caused an unexpected problem that results in the network's open ledgers diverging, causing inconsistent transaction propagation. Conceptually, it's easy to change this behavior, it's an "instead of X, do Y" thing, it just happens to be a bit awkward to connect the pieces together in the code. (And our fees expert is still dealing with hurricane effects.)
×
×
  • Create New...