nikb

Ripple Employee
  • Content count

    589
  • Joined

  • Last visited

  • Days Won

    18

nikb last won the day on March 13

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. There's 100 blockchain companies? What a world we live in...
  2. The answer to "would it be possible" is almost always "yes, it would." And it's almost always followed by "But..." Here are some comments: (1): zk-SNARKs are interesting and novel (also sloooooow). Adding zk-SNARKs is a means to... what? What exactly do we aim to achieve? (2): Again, the question becomes what do we want to achieve by adding ring signatures? (3): You could certainly do something like that over Interledger.
  3. If anyone is interested in seeing the nitty-gritty of invariant checking, it's here: https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/InvariantCheck.cpp The first checker in that file, for example, ensures that XRP cannot be created or destroyed by a transaction. As you can see, the checkers are very simple, most being less than 15 lines of codes, and fairly straightforward to read (much more straightforward when compared to transaction processing code). We're excited that this is live on the network, which is a bit weird, considering that it's something that should never trigger. It feels good to be proactive and to be able to spend the time and resources to implement these defense-in-depth checks. And we have more coming!
  4. I do not have this information available. I'm sure more details will be published.
  5. Stand by on that - there's new code being added to allow servers to easily publicize their UNL.
  6. At least you have a good sense of humor. It's a requirement for crypto!
  7. I said what I wanted to say. I'll wait and see what happens, but I'll get great pleasure out of seeing you stick your foot in your mouth.
  8. I guess you either missed the last sentence in the article, or you're trolling. To keep the FUD from spreading, let me be very clear: Yes, up until now, Ripple servers have only trusted validators under Ripple's operational control. But that was never supposed to be permanent and will be changing now that a wide and more diverse network of robust validators is online. This is not new: Ripple had previously committed to trusting external validators and today we reiterated that commitment. As I'm sure you know, we have a track record of following through on our commitments and this will be no different. You can expect to see the final part of our decentralization efforts begin by having Ripple-operated servers trust two external validators.
  9. Thanks for the feedback. Those are some great points! I'll pass them on to the right people on the marketing and UX teams.
  10. A transaction is a transaction; why exclude them? In fact, some of the transactions you describe require more "work" to process than a simple XRP or IOU payment. In other words, if we only did simple only XRP and IOU payments during the benchmark, the results would likely be a little better. The figure is meant to be representative of the headroom that the live network has. Lots of small things: some work on refining locking and reducing contention, optimizing certain "hot spots" we found through profiling, refactoring existing code. Just a lot of hard work by the C++ team.
  11. Huh... Even if they really aren't convinced from the white paper, I think that after four years of continuous running and 30+ million ledger closes, it's clear that the algorithm does, indeed, work as advertised. With that said, I'd be interested in hearing what, specifically, they felt was missing, but this kind of discussion can't happen via proxy and forum cut-and-pastes.
  12. Hard to know why some projects pick up steam and others don't, but I think that trust likely is a huge factor. It sucks that you put in a lot of effort and not much came of it. I agree that open-sourcing the code is a step in the right direction, and getting eyeballs on it (especially the eyeballs of trusted members of the community with the technical "chops" to review the code) would make a world of difference.
  13. I agree with you. I'd love a proper engineering blog, where technical content can be discussed.
  14. I have no idea what this is about and am somewhat skeptical about whether it's legit or not. Be careful.