Jump to content

nikb

Ripple Employee
  • Content count

    661
  • Joined

  • Last visited

  • Days Won

    19

nikb last won the day on September 10

nikb had the most liked content!

About nikb

Contact Methods

  • Website URL
    https://ripple.com

Profile Information

  • Gender
    Male
  • Location
    Las Vegas, NV
  • Occupation
    Software Engineer
  1. Something Shiny Comes This Way...

    I'm in for a gold coin! Actually, I'd really love a large triple-struck proof round, between 2 and 4 troy ounces of .9999 gold, with the triskelion in high relief on the obverse and something more abstract struck on the reverse. Jus' saying, if you want to take my money, that'd be a good way to go about it.
  2. I wasn't active on the network at the time (although I was aware of Ripple) and have no data to contribute to the effort, but I'd love to see the lost ledgers recovered.
  3. I haven't looked much into compression for many years; last thing I did involved differential PCM compression algorithms as well as wavelet-based compression while I was an undergrad, so quite a long time. No doubt, interesting technological advances have since been made, and maybe throwing a compression engine in front of the link makes sense, even if only a "naive" one without fancy specialized per-segment compressors. But, I suspect that there are more and better gains to be had elsewhere.
  4. Once we upgrade to the latest version of Beast, we'll be able to websocket compression. As for whether it makes sense to compress the data for peer-to-peer links... perhaps. The calculus isn't clear on whether it'd be a gain or a loss. We'd need to test.
  5. Quick question for the og zerpers

    We’re a community. Thanks to all of you!
  6. Nothing yet; have been busy with other things, but the ball is a’rollin!
  7. Questions on fees

    I asked our resident fee expert, @EdH, to stop by and answer some of these questions. Also, another awesome member of the rippled C++ team, @wilsonianb, who also has a lot of experience with the Ripple API will be tackling the other questions. Thanks for your patience.
  8. Are we really decentralised?

    I'm torn on the whole automatic updates thing, @JonHolmquist. On the one hand, it's helpful and reduces the workload associated with operating a validator, on the other hand, I'd rather have an admin that is more involved; after all, new updates might include things like amendments, and I'd rather have people make conscious decisions about those. The thing about CCleaner that broke today, which @Sukrim mentions, also shows why automatic updates can be a problem. Ultimately, I don't think that not having automatic updates solves it; in fact, even compiling from source may not. But it could certainly complicate things. I'll try to write a blog post that explains the security setup I have for my validator in depth. I already incorporate a lot of these practices and maybe once I write them all down, with your help, we can refine them and list the document as the community-recommended "best practices" when running a validator.
  9. Well... the truth is I I don't know what Satoshi was thinking or what he knew or didn't know. And I don't think anyone else does either—except Satoshi. I know people might argue that this imparts quantum resistance to Bitcoin and, thus, Satoshi's goal was quantum resistance. I'm not sold. Ultimately, I think that Satoshi felt he was doing something unique—something for which there wasn't a lot of literature out there—and I suspect that this "double hash with two algorithms" scheme was his attempt at over-engineering this to ensure it was going to be right.
  10. Interesting question, that takes us down a bit of a rabbit hole. First things first: Ripple uses the same algorithm as Bitcoin to generate an account address from given a public key (almost: we use a different dictionary in the base 58 encoding step, hence addresses start with r but the actual algorithm is the same). So that method is to do SHA-256 followed by RIPEMD-160. So why use this curious construct, instead of say a single SHA-256? Or double SHA-256? Well, the original authors of Ripple made a conscious choice to use the same algorithm as Bitcoin. This gave people examining Ripple one less thing to worry about and one less thing that they could use to argue that Ripple was, somehow, less secure than Bitcoin. In 2017 that may seem like a somewhat silly concern, but back in the early days it wasn't a silly concern at all. So the question morphs to why did Bitcoin use RIPEMD-160? I'm not sure, but I suspect that the answer is that Satoshi wanted addresses to be as short as possible, and he felt that 128 bits were too little and 192 or 256 bits were too much. Hence 160 bits. And at 160 bits, RIPEMD-160 is the only hash algorithm that cryptographers currently consider "safe". But then why hash twice and with two different algorithms? Again, I think that Satoshi thought about a number of options and opted to use a construct that reduced Bitcoin's vulnerability to certain kinds of attacks.
  11. Are we really decentralised?

    I think that simply running a validator contributes to the network; here's my rationale: ultimately, the Ripple security model isn't to trust individual validators per se. Rather it's to trust that a given set of validators don't collude with each other. By way of slightly far-fetched example: if both North and South Korea ran validators, I may be willing to put both of their validators on my UNL, since I find it highly unlikely that they would collude on anything. The more validators are available, representing distinct and (hopefully) diverse interests, the better off we will be in the long term. Having your validator verified simply means to publicly associate it with some Internet identity. It both does and doesn't help. It doesn't make any technical difference as far as the protocol itself is concerned; there's no indication in the protocol if a validator is verified or not. But it does help people make decisions about which validators to choose for their UNL. For example, I am more likely to choose a validator operated by, say, AT TOKYO than an unidentified one that some guy named Bob who runs a taxidermist shop has claimed to be running from his home. At this time, I would really not recommend that you diverge from the recommended UNL (except by maybe replacing one server). Instead, I believe that you should allow Ripple to take the steps that we have planned. On that topic, coming very soon, is a blog post detailing our plan, followed quickly by the first step in the process. Once that plan is in motion, I think you'll see things move faster. But I also think that as Ripple takes those steps to decentralize the network, the community needs to start thinking about decentralization too, because we should be ready for it to happen before it does. So, we need to start thinking about community focused efforts to build up a network of validators. We need to think about entities other than Ripple that will publish curated validator lists. We need to think about offering services similar to the "validators" page on ripplecharts, that track long-term performance trends for all validators.
  12. Are we really decentralised?

    What exactly would you like to see written? I can write one up.
  13. Typically, the new algorithm would require a new keypair; so in a way you'd need to change both. When we added ed25519 support to rippled, you couldn't just up and use a secp256k1 key to do ed25519 signing, for example. But you could set your account's regular key to a shiny, new ed25519 and disable the master key and tada!
  14. I agree with you. We've made tremendous progress and we will, no doubt, continue to do so. I am sure that the future will be magic because of our advanced technology. I know that today's tech will be rapidly antiquated. This applies to encryption theory as well. But I seriously doubt that we'll see the kind of break that would make what's being discussed in this thread possible. With that said, it's possible a breakthrough attack could be found, but it would have to reduce complexity dramatically—by over 2^128—to make brute forcing the rest of the keyspace viable. But although I can't dismiss such a breakthrough attack completely, but I am almost certain it won't happen and, if it does, it won't just land overnight. If crypto moves ahead and we discover the security of these algorithms are less than we expected or that they are weakening at a rapid pace, we can always change the cryptography.
  15. As a retired engineer, I'm sure you'll appreciate the very physics heavy excerpt in the post I linked. To reiterate: brute-forcing of 256-bit keys is simply not going to happen until computers are made from something other than matter and occupy something other than space. Is it possible some completely novel, yet to be devised attack will be faster than brute force? Perhaps. But it would have to be unfathomably faster to alter the calculus. I'm not holding my breath.
×