Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by nikb

  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/
  16. I don’t know what Stellar is doing or how they’re doing what they’re doing, to be honest. I have my hands quite full with my own work to go spelunking around other projects’ code repos.
  17. Kind of. Actually, the key insight came to me in a dream.
  18. No, they can’t. If a trust line goes into its default state, it’s automatically deleted. Since the trust line exists, it means it’s in a non default state.
  19. Yeah, it’s not easy. What would it mean to have an escrow to an account that doesn’t exist, for example? The existing code is written with the assumption that can’t happen. Allowing an account root to be deleted while still owning objects is a non-starter, in my opinion.
  20. The code is very carefully written to ensure that recreating an account is supported and will not cause any problems. It does have implications and that’s why I’m not sure if this amendment will ever gain widespread support, or if I can even get enough support to merge it into the codebase. I was thinking of making the DeleteAccount transaction require one incremental reserve (currently 5 XRP) as a fee.
  21. @Sukrim: the reason it’s there is because, without it, someone can open a trust line to you (something that you can’t, otherwise, prevent) which will make the account impossible to delete. The flag may actually evolve to do more than just prevent trust lines from being opened. Several things can create an owner directory entry. As I said, this is just something I came up with and decided to just try and implement. It’s not final by any means, and I have no idea if it will ever be merged. I didn’t intend to make this public; it was just an initial very quick implementation of an idea I had. I absent-mindedly pushed it on GitHub before calling it a day, and here we are. So, I guess, I welcome comments.
  22. The commit doesn’t introduce a new object type. It works on any account and uses regular AccountRoot objects.
  23. This is just something I did on a Friday night just because I could—and it’s not finished yet. Doesn’t mean that if will get merged or, for that matter, that the validators will vote in support of that amendment.
  24. If you previously submitted information and your validator isn’t verified, please submit again and drop me an email at nikb@ripple.com to let me know you did, so I can double-check on things! And a better verification process is coming soon; one that takes Ripple entirely out of the equation, which is great.
  25. First thing first: Dr. Atiyah is an amazing mathematician; I’m very curious to see what he has to say. With that said, we generally assume the Riemann Hypothesis to be true; if he’s proven that—and again, that’s a big if—then all is good and our understanding of mathematics will have advanced. If he can offer a counterexample to the Riemann Hypothesis, our understanding of mathematics will have advanced too, but it will mean we were wrong about some things and it will send shockwaves through the mathematical community. Either way, math will advance and we will be better for it. A counterexample will have implications about the distribution of prime numbers, which could (perhaps) be leveraged to attack cryptography that relies on the difficulty of factoring a semi-prime to its constituent primes.
  • Create New...