Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


nikb last won the day on October 13

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. I can tell you that setting the MessageKey on your account should not impact your account's security: the current rippled code doesn't use it for anything; it just stores it. I can even tell you that unintentionally compromising your account your account by setting the MessageKey field is so unlikely that it is, effectively, impossible. But I can't guarantee you that it's actually impossible for you to mess it up. Nothing and nobody can prevent you from shooting yourself in the foot and since I don't know your intentions and can't control your actions I cannot and will not guarantee that
  2. Ahh, that was a wonderful video from the old days. I wish we could redo it and expand it. It's a wonderful high-level description of consensus. Q1: Is this new proposal sent to all servers or only UNL? Proposals are propagated throughout the network. Q2: What happens then with this proposal? Is it used in the same round (before next ledger)? Proposals come in "rounds", and typically it takes multiple rounds for enough proposals to converge, so that one set of transactions gains enough support for servers to declare consensus, and for validators to then publish a validation.
  3. @tulo basically nailed it. One small clarification: basically, once consensus determines the set of transactions, the set is placed in a deterministic (but very hard to predict) order. This is done by sorting transactions based on the hash of the consensus set (which is, for our purposes, effectively random), their transaction IDs and their sequence numbers. You might find https://xrpl.org/consensus.html to be useful.
  4. livenet.xrpl.org tracks the network locally, so when you first load up the website it's possible that it will take a few ledgers for it to catch up. It's also possible that connectivity issues on your end could cause some validations to be missed or arrive late. It looks good from my end.
  5. There are 38 validators on Ripple's recommended UNL. You can see them at https://vl.ripple.com (the raw data) and https://livenet.xrpl.org/network/validators (a nice, decoded view). The xrpcharts website is deprecated and relies on the DataAPI, which has issues that prevent it from tracking validators that use the new manifest-based domain verification at this time. I hope this helps.
  6. Please elaborate? Also, to be very clear the rippled-specs repo contains no code: just drafts of documents we are preparing that are intended as specs but which we don't feel meet the high bar we set for ourselves. For example the "negative UNL" documentation that now lives in `rippled` repo, under docs/0001-negative-unl began life in the rippled-specs repo, where it was reviewed and refined by my colleagues, prior to being made public.
  7. The bug that caused this issue has been fixed (I linked some of the relevant commits earlier). It’s unlikely to occur again because of that bug (since it’s been fixed) but I can’t definitively say it won’t happen again: code is a living thing, and humans are imperfect, so maybe something was missed or some future change will introduce a similar bug. I hope the Foundation will have a hugely positive impact but, ultimately, what it boils down to is people and engagement. The strength of an open-source project is the community around it.
  8. That repo is a bit of an experiment for our team and is meant to hold our "work in progress" drafts for things we're brainstorming and/or that we aren't ready to propose or publish for everyone to comment. It contains no "private" information as such and there's nothing magical in there that contains "secret sauce" that only the Ripple team is privy to. You may feel that's not being transparent, but I wouldn't agree; it's reasonable for our team to have a place where we can internally collaborate on specs or brainstorm on ideas before we are ready to publish something to the community.
  9. It's not personal at all. Yes, I'm still with Ripple and still leading the C++ team.
  10. Good question. I wish I had a better answer for you, but it boils down to this: The company was using JIRA for everything else, and management wanted to be able to monitor the work we were doing on JIRA instead of having to rely on a separate thing, so we ended up migrating away from GitHub and onto JIRA. The original JIRA tracker was public, and the company maintained a private JIRA for the other closed-source software being developed. But having two trackers, one public and one private caused both confusion and managerial nightmares. Also, people were concerned about security and a
  11. You're welcome. It'd be awesome if FlashFX were running a validator; if they are they ought to make it public.
  12. While some exchanges operate validators, most aren't (or if they are, they haven't chosen to make that fact public). I don't know of any other commercial users who are running validators; while my permission to do that isn't required and it's possible that they could be without me knowing and opting to remain anonymous, I think it's probably safer to assume that they aren't. As for improved monitoring, I honestly don't think that the solution is to ask more of Ripple. First, you don't really know what kind of monitoring infrastructure Ripple already has in place, both for its own servers
  13. Fair criticism, and the only thing I can say is mea culpa! Honestly, I hadn't seen this thread, but that's hardly an excuse. During the incident, I was more focused on figuring out what happened and the immediate next steps needed. Those were days with very little sleep; I think I personally went for almost 5 days, on maybe 30 minutes per day. We kept monitoring the network closely, while working on a post-mortem, and the longer-term fixes necessary. And there also the other million other things I had on my plate, and so. So, the answer is, it just kind of got away from us. Once it r
  14. I think that everyone that relies on the XRP Ledger ought to be an active and engaged participant. That can take many forms, and operating a validator is only one thing they could do. But let's talk about validators, since you specifically asked about that. Should everyone run a validator? In an ideal world, everyone would be willing to, but I don't think that everyone should. Only those that are able to commit the resources to do it well should, and everyone should be keeping an eye on those that are to ensure that they are doing a good job. I strongly believe that anyone building a busi
  15. I think that a project to monitor and archive proposals and validations would be awesome! The newer versions of rippled should make it easier to achieve, because they will, by default, forward all validations as opposed to only trusted validations. It isn't really a big undertaking if you look at it from a code perspective. But it is much larger if you look at it from the perspective of maintaining the archive, which will grow fast. I would be hugely supportive of anyone choosing to undertake such a project and making the dataset public.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.