nikb

Ripple Employee
  • Content count

    335
  • Joined

  • Last visited

  • Days Won

    14

nikb last won the day on December 29 2016

nikb had the most liked content!

About nikb

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    https://ripple.com

Profile Information

  • Gender
    Male
  • Location
    Las Vegas, NV
  • Occupation
    Software Engineer
  • Country
  1. Go Beast!
  2. I can't go into any detail about the security measures Ripple has in place in production, but I will say that the machines and the sensitive cryptographic material they contain are well-protected. Now, let me do the next best things and tell you how I protect the keys to my own validators: My validator machines are in a secure facility and are physically located inside an alarmed, tamper-evident enclosure, that is, itself, located inside a cage. They are both running a hardened operating system and using full disk encryption on all disks. A password is required to unlock the disk and boot the machines. The machine's TPM is used to measure the boot sequence, ensuring that the BIOS, bootloader and kernel are not tampered with. The validators run as processes inside a VM guest running a minimal version of Linux. No incoming connections are allowed on those VMs. A separate firewall device (configured as a transparent bridge) sits between the machine and the Internet, as additional protection. Note validator manifest support is going to be a big plus: it will allow validator operators to easily and seamlessly rotate validator keys on a regular basis without disrupting the network or requiring those who trust the validator to make any change.
  3. The odds of randomly selecting colluding servers from a set of N choices, given how likely collusion is between servers can be easily quantified. Random choice isn't as bad as it first sounds.
  4. It's not: all you need is validators that won't collude. But we have a plan that will make selecting a UNL a thing of the past.
  5. Pick at random. You just need validators that won't collude to defraud you.
  6. I'm not going to address all the points exhaustively, one by one, but let me respond to a couple of them really quickly. This is a flat out lie. Our version-setting commits (in other ways, the tip of each repo) are all signed by rippled developers. Anyone downloading the code can verify that what they downloaded has not been tampered. See: https://github.com/ripple/rippled/commits/0.50.0 Additionally, our release announcements (served over https) link to RPM packages that are signed by Ripple and cannot be tampered (and yes, the built process verifies that the code it builds from is signed by an approved developer key) and the md5sum of the rpms and the commit id at the tip of master is included in the announcement text as well. See: https://ripple.com/dev-blog/rippled-0-50-0/ This is just plain silly. The caliber of people at Ripple is top notch, and the code we produce is a testament to that. Huh? What does the ripple website have to do with anything? Surely if they're that frequent, it should be no trouble at all to point to such changes in core consensus code. I'm not sure how to take this "criticism"... of course if an amendment is proposed and the network, collectively, accepts it, then nodes that veto it or don't support it can't continue to process transactions and become amendment blocked. What else could possibly be done? "I CAN HAZ MOAR NONSENSE"
  7. @tulo: I'll poke around and see if I can figure it out or find someone who can.
  8. 0.50.2 has been released, addressing this issue: https://ripple.com/dev-blog/rippled-version-0-50-2/. Thank you again for the report.
  9. And 0.50.2 is out, fixing the secure websockets connectivity issue identified on xrpchat. You can read the release notes at https://ripple.com/dev-blog/rippled-version-0-50-2/ or you can take a look at the code at https://github.com/ripple/rippled/tree/0.50.2.
  10. As @JoelKatz said, we identified the issue. We have a mitigation plan in place and I expect the fix to be rolled out by tomorrow. Thanks for the report @bcLet.
  11. Interesting. I will try to test and see if this is something caused by our OpenSSL hardening. Thanks for the report! For future reference, please prefer opening an issue on github, to ensure that rippled developers see the report in a timely fashion. See: https://github.com/ripple/rippled/issues
  12. I should see about submitting a paper or two...
  13. The names we use now, Ripple and XRP, are just fine... I'm sticking with those.
  14. There are so many smart posters on here, but a few of them are just brilliant. It's a treat for me to read the forums because I learn something new almost every time I do.
  15. I suspect it's something specific to the exchange. You should raise this issue with them. Just to be safe, I checked a couple of rippled servers and they seem to work fine.