Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


nikb last won the day on November 27 2017

nikb had the most liked content!

About nikb

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Las Vegas, NV
  • Occupation
    Software Engineer

Recent Profile Visitors

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

  1. Karlos is entitled to run his validator any ways he sees fit, however, I think that decisions on amendments require a modicum or technical understanding, since every amendment has implications and every amendment that activates imposes some cost to the network. Asking on a forum with open registration about which way to vote seems, to me anyways, to be a poor way to do this. I’d never run my validator in such a fashion, but as I said, to each their own.
  2. A laptop is just a computer you can easily move. You should be able to run a validator on a recently modern machine. Up until recently, I’d spin up a rippled instance on a first generation 2013 ThinkPad Carbon X1 with 8GB of RAM on a regular basis. You may find the following useful: https://xrpl.org/install-rippled.html
  3. I normally wouldn’t dignify this tripe with an answer, but I feel compelled to: You must lack in imagination.
  4. Hop on the devnet or the altnet and have a blast. There’s no need for coordinated action either: two accounts should be enough.
  5. Good for them. If they have concerns or they want time to evaluate the amendment on the devnet, or even the code itself they should absolutely veto it. Notice too that Alloy says “at this time” which suggests to me that he wants the time to investigate this code and understand it and its implications. I’d never more concerned if they blindly rubber-stamped code changes than I am by Wietse’s and Alloy’s choice to veto the amendment. They are stewards of the XRP Ledger and should be careful about and weary of changes. Any change we make is a change that we are stuck with, potentially forever. For some details about this amendment, check out my twitter thread:
  6. Great! We are working on improving the insights module with rippled which can be used to export various metrics using the statsd protocol; empowering administrators to collect and plot performance/usage data from their running instances should prove helpful in identifying bottlenecks, areas of improvements as well as in spotting trends.
  7. We do have some insights into the increased resource, but they are insights; we need data and metrics that we can monitor over time to allow us to spot trends. Ripple, like any other operator of servers with a large number of client and server connections, can observe the servers it operates, examining things like memory, CPU and bandwidth usage and trends, and use that information along to extrapolate on future requirements. And like any other operator, it isn't clairvoyant, so it's predictions about hardware requirements may be off. As for reserves, my gut says it's not a good idea to tie them to amount of RAM or CPU. But perhaps I'm wrong. Curious to see what others think.
  8. Naively, it seems that we could just make the Fee field be a maximum. So you can set it to the maximum you want to pay, but you’re charged less (e.g. the median fee of txs in the ledger). But that’s not as easy as it sounds and there’s a ton of game-theoretic concerns.
  9. Recommending hardware for production use is always tricky and one needs to balance a number of factors. Let’s say that 8 GB of RAM is enough today. How long will it be enough for? Will it be enough if there’s a sudden spike of volume? Will boxes be under memory pressure 3 or 6 months from now? The cost of RAM is cheap and it’s better to be conservative and allow a big buffer, than to end up under memory pressure at an inopportune time. To be clear, I’m not opposed to your comments about defining a target re: resources and then trying to hit it. But I also don’t think it’s realistic to target a Raspberry Pi or to recommend hardware that has enough capacity for “today” but not for “tomorrow”.
  10. The ship has most certainly not sailed. Don’t be discouraged by the work that Xpring is doing. There is no good reason to have only one library by Xpring and nothing more. In fact, the more high quality libraries we have the better. Some will be higher-level and abstract a lot away and some will be lower-level and allow the user more control. I strongly urge you to continue building your library; if you want, I’m happy to connect you with the developers on the Xpring side so that you can see if there are opportunities for collaboration or sharing and reuse of common code.
  11. I appreciate the kind words, but most of the "deep 'scenario' thinking" is by my coworker, Scott Schurr.
  12. Yes, there are "creative" ways to prevent an account from being deleted—at a cost. It's an unfortunate reality. There are potential workarounds, but it's a cat-and-mouse game which, ultimately, affects usability.
  • Create New...