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. Ha! I was thinking about using identicons too. It’s a rather neat idea, actually.
  2. While this can be useful (e.g. in a transaction analyzer to shorten account IDs to, say, rABC..XYZ and detect collisions) I share some of Sukrim’s concerns.
  3. The domain verification bit is, actually, unrelated. Let me kick the bot to reverify.
  4. While I think there’s merit in a third-party “naming” service (perhaps a collaborative effort), I don’t think that the toml file is the right place to report this information. I agree that a section allowing a domain to specify websocket and peer connection endpoints is a good idea.
  5. Thanks! Apologies for the inconvenience. With 20/20 hindsight, a hotfix addressing this issue would also have been appropriate. But you know what they say: you live, you learn.
  6. The behavior you describe is definitely a bug. The server should automatically refresh the lists that are defined in the configuration. The bug was recently discovered and a fix has already be made and will be included with the 1.2.0 release of rippled, which should be finalized early next week.
  7. Almost right! If you’re autobridging and you cross your own offer it has to be taken, rather than just cancelled. The reasoning is subtle; for some hints check out https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Taker.cpp#L408 (which is remarkably well-commented). If people still have questions, I’m happy to elaborate.
  8. What @Sukrim said! Just set a regular keys, verify that it works and then disable the master key. Minimal cost—just tx fees.
  9. When we started developing the SHAMapV2 code, our goal was to have it voted on and enabled ASAP. But, unlike every other amendment that have been activated to date, SHAMapV2 makes a radical change in the core data structure of the ledger: the SHAMap. At the time of activation, the network would have to halt, as it converted the V1 maps to V2, before continuing. And, of course, this would be non-reversible (without another amendment and another conversion). This was a serious concern, so we kept putting off voting for the amendment. Throughout this time, we’ve implemented a lot of incremental improvements to the V1 maps to the point that the additional improvements that V2 offers are, simply, no longer big enough to justify activating this amendment, especially considering the costs & risks activation entails. My preference would be to withdraw this amendment and remove the SHAMap V2 code from the codebase.
  10. Of primary concern for me is a demonstrated technical ability to operate servers reliably securely and a commitment to operating the validator for at least two years. Being involved in this space is also important (think people like @Rabbit_Kick_Club, @karlos and Wietse Wind). The basic metrics, in my opinion, are pretty objective and surface candidates for inclusion. Server stats, connectivity, security, performance, commitment. Unless there’s “room” for all candidates (and we can’t just add 10 servers at once!), then selecting amongst them can become a bit subjective. At the very least, there’s a “value judgement” about which one “helps” more right now. For example, given two equally qualified candidate validators other things become a factor; a validator in, say, South Africa may be preferable to another US validator. But maybe the US one is operated by an exchange and the South African one by an individual which alters the calculus a bit. Or perhaps one candidate is an AWS instance and the other on Azure, and there are already other validators on AWS. I could go on, describing all sorts of situations. Why X and not Y? Why Y and not X? Why not Z? Ultimately any decision will be seen as subjective by someone; someone will disagree and someone else won’t. It’s just how these things go and that’s not surprising.
  11. I supported having alloy.ee on the default UNL, despite their “short” track record bevause: - Their business revolves around providing hardened hosting services; that experience bodes well for a validator operator. - They have more than one data center and high redundancy & reliability setups. - They chose not only to run a validator but to publicly commit to continue doing so for the long term. - They add important geographic diversity (Finland and Germany). - They are members of the community; I’m not going to name-call them here—they can introduce themselves if they desire. Maybe you disagree with the decision to add them. That’s fine. The important fact, which shouldn’t be lost one anyone, is that the XRP Ledger has a robust and diverse validator ecosystem.
  12. A destination tag doesn’t have a “balance”. It’s not a “subwallet” within a wallet. It’s just a number that can be used by the recipient. Many exchanges use destination tags for deposits so that they don’t need a separate deposit address (aka wallet) for each user. But any funds sent to that destination tag are stored inside the wallet itself, and the destination tag is not attached to them in any way; it is only visible in the transaction. At best, what you can do is walk back all transactions made against a given account and see how many of them specify a destination tag.
  13. Mostly because the code doesn’t support Ed25519 validator keys. There is an open PR (#2647) to allow validators to use Ed25519 to sign and it will get merged. To answer your question a little more broadly: a conscious decision was made to use the same algorithm as Bitcoin. But beyond just that, remember that the paper by Bernstein, Schwabe, Lang and Yang only got published around the end of 2011, so Ed25519 would have been way too new to seriously consider using at that point.
  14. To elaborate on what Sukrim said: a stock server does everything a validator does except sign and publish its own validations.
  15. nikb

    Ripple contact

    The best option for getting in touch with the right people is via https://ripple.com/contact/
  • Create New...