Jump to content

nikb

Ripple Employee
  • Content count

    798
  • Joined

  • Last visited

  • Days Won

    23

nikb last won the day on November 27 2017

nikb had the most liked content!

About nikb

  • Rank
    Veteran Member

Contact Methods

  • Website URL
    https://ripple.com

Profile Information

  • Gender
    Male
  • Location
    Las Vegas, NV
  • Occupation
    Software Engineer
  1. Thanks for sending your resume in. I don’t know the details of the internal process that or recruiting folks follow once a resume comes in, but please don’t think that a lack of response is indicative of anything other than a backlog as a result of a massive amount of applications coming in. At the very least, our system should issue an automated “thank you” e-mail. If it doesn’t, that’s a mistake on our part and one I will ask to have corrected.
  2. Amendments weren't available at the time. The code was finished and enabled in commit https://github.com/ripple/rippled/commit/ce31e26f580044f89b960d76e12f39674e577ea0 which made it in on February of 2016. Also, please note: issuers of IOUs could (and can continue to) choose to not honor their obligations; the only recourse users had was either public shaming or legal action against the gateway. This is true whether the Freeze feature was implemented or not. The introduction of Freeze didn't change any of that. The only "change" was that issuers could freeze an IOU such that it couldn't be traded or used in any way other than having it returned to them.
  3. To be perfectly clear, I think that any such change would be ill-advised if not down right stupid and that it would never happen; anyone proposing it would be laughed out of the room. But let's think outside the box. After all, code can always be changed and no mechanism could ever prevent that. I'll start by pointing out that this isn't unique to Ripple; Bitcoin's 21 million BTC limit could be raised by changing the code too. The code inside a pacemaker could be changed to shock your heard to the tune of "Ice Ice Baby". The "the code can be changed" attack just doesn't carry a lot of weight with me. Sure, it can. But that doesn't mean it will. What if it did happen? The ultimate safeguard in these systems are people; the people who maintain the code, the people that operate servers and, ultimately, the people that use the system. Let's look at those groups, one at a time: First are the people who maintain the code. I can tell you I would not write code to increase the amount of XRP and I would not allow such code to merged into the code base while I am responsible for it. I'd resign, if it came to that. Which brings us to the people who operate servers: they choose which version of the software to run and can't really be forced to run it. Would they agree to upgrade to code that changes one of the core invariants of the system? My bet is that they would not. Lastly, there are the users; the last line of defense. If the system changes from under their feet, then will they continue to use it? Users value stability and they don't want a system that changes from under them in ways that contradict the system's core principles. If the amount of XRP was increased, what would those users do?
  4. Payment channels are NOT limited in any way. When you create a payment channel you pay a small fee (currently, 10 drops or 0.00001 XRP is sufficient). When you close a payment channel and settle it, you pay another small fee (again, , 10 drops or 0.00001 XRP is sufficient). Once the channel is setup you can operate the payment channel off the ledger, limited only by your CPU and the connectivity of the two endpoints. This part happens off the ledger, so it's not bound in any way by the 1,500 tx/sec figure and there are NO fees associated with these off the ledger messages. As for speed, according to https://ed25519.cr.yp.to/ed25519-20110926.pdf, an average quad-core CPU should be able to do over 100,000 Ed25519 signature operations per second. This figure will, obviously, only get better as CPUs get faster. Obviously, at 100,000 sigs/sec, the bottleneck isn't the signing, but the networking between the two endpoints.
  5. Yeah, the node_size can have a dramatic impact on RAM. It's almost always better to leave that value to "tiny" or "small"
  6. Interesting. We appreciate the feedback and will look at the increased I/O.
  7. Of 764434096B4BAE921F89F2ABB2481BE062BB9B633C182039296A7DF3CDA44028? I don't think anything about it really. According to XRP Charts it's a payment for a little over 1 billion XRP.
  8. It's just the version number of the client being used.
  9. This transaction mean anything?

    This is just someone using version 1.4.3 of a client. You guys are trying so hard to read between the lines, you didn’t notice that there are no lines to read between.
  10. The “client” doesn’t mean this went to a client. It’s just a memo field, of type “client” with the value “rt1.4.3-13-g582a3a5”
  11. Rippled on NUC

    I'm running a rippled node for dev purposes on a similar setup: a Gigabyte Brix with 16GB of RAM. Your NUC should be fine. I agree with you about hardware specs for running rippled. We are working on it, and will be publishing recommendations for cloud providers and bare metal machines over 2018.
  12. fillOrKill flag not working??

    My mind is blown. That is actually brilliant!
  13. The network will always have the concept of “trusted” validators. It’s the literal core of the system’s security model. Each server just chooses who to trust. As we progress, you may choose to trust list publishers—entities that will publish lists of validators they claim won’t collude—and then your rippled can select a subset of those. We may even get to the point where you can specify a policy file, and rippled will select a random set of validators that meet that policy and treat them as trusted. But the concept of trust isn’t going away, and that doesn’t really affect centralization. The company is actively looking to divest itself of control, a fact that previous posters have highlighted repeatedly. That hasn’t changed and we are still on track for that.
  14. Transaction time and 5G

    Ripple operates at the TCP/IP layer. 5G stuff operates at a way lower level. When 5G becomes widely available, Ripple will be able to use it without any special effort. If the bandwidth promises happen, then that will be very cool.
  15. fillOrKill flag not working??

    Good idea. But unlikely to change now.
×