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
    Veteran Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Las Vegas, NV
  • Occupation
    Software Engineer
  1. nikb

    Five Bells Condition

    As the person who originally implemented cryptoconditions on the XRP Ledger, I'm happy to offer some insights. Feel free to ask specific questions, @rjremien.
  2. nikb

    Incentivising running validators

    If nobody derives enough value from the network to operate a validator, then the network simply isn’t viable. Luckily, it looks that isn’t the case, since a number of validators are being operated by a diverse group of operators.
  3. nikb

    Incentivising running validators

    I don't think that incentivizing validators by having the Company compensate operators in XRP helps to meaningfully make the validator network both more robust or more distributed. In fact, I think it's a bad idea. If people run a validator only to get compensated, then I wouldn't trust them because I'd worry that they would be willing to collude against me if someone paid them to do so. Validator operators need to have a stake in the long term health of the network, not in a monthly paycheck. Presumably the compensation would be enough to making running a validator profitable (otherwise, why do it?), in which case the plan could be easily gamed: simply setup multiple validators, under multiple personas. I am not against operators seeking to defray their costs. If someone wants to operate a validator and publishes a policy that explains how they'll operate it and then chooses to solicit donations to cover the expenses associated with running the validator, I have no problem with that. A program, operated by the Company, to compensate validator operators? Sorry, I don't like that. Although, I'll be honest: the marginal cost of operating a validator for an entity that already operates at least one server is minimal. Even if you're a user and want to host a validator in your home, the cost is likely pennies a day.
  4. I discussed both Shor's and Grover's algorithms earlier. Yes, it's true that quantum computers, combined with Shor's algorithm, will mean that a lot of the algorithms we rely on today will be obsolete. But, as you say, such a computer doesn't exist today and is unlikely to exist in the near future. In fact, it's not clear (at least to me) that such a computer, if built, would maintain coherence long enough to perform any useful calculations. We'll see, I guess. Anyways, I disagree that quantum computers will render cryptocurrencies obsolete. We already have signatures schemes (such as Lamport Signatures) that we believe are secure against attacks from quantum computers, and we could use them. They aren't great because signatures are a few hundred kilobytes long, although I'll take "secure but large" over "small but insecure". On top of existing schemes, the cryptography community is hard at work developing new post-quantum signature algorithms. It's tricky, but progress is being made. I feel confident we'll come up with something workable.
  5. If a signed integer is used, changing it to an unsigned is trivial: do nothing but simply start interpreting the 32 bits as unsigned rather than signed.
  6. This is not really a serious problem nor a "big concern". The timestamp format has the "zero" point as January 1, 2000, and the counter is 32-bits worth of seconds so what... 135 years or so. That gets us to 2130. I figure we can get started on this in a little early just to be safe. Sometime around 2100 sounds reasonable.
  7. Yes, you could definitely secure such a wallet. In fact, depending on how you've used the destination wallet, it may be resistant to quantum computers today! The obvious way would, of course, be if a new post-quantum signature algorithm was implemented in the code. Simply generate a new keypair and use it, likely by configuring it as a regular key for the destination account and disabling the master key. Tada. But even if no post-quantum signature algorithm was implemented, you could still secure the destination account using existing algorithms. The idea would be to generate a new ECDSA or Ed25519 keypair, and configure that as the account's regular key while disabling the master key. This may see a bit weird at first. After all, if this is a regular ECDSA or Ed25519 keypair, what makes it secure? It all boils down to algorithms and safety margins. We may not have general purpose quantum computers right now, but we do have quantum algorithms and two are of concern: the first is known as Shor's algorithm. It's fast, but you can only use it in some cases. The other is Grover's algorithm. It works all the time but it's slow. I'm playing a bit fast and loose with the definitions of "fast" and "slow" here, and this isn't the whole story, but just go with it for now. In order to be able to use Shor's algorithm, your public key must be known. In Ripple (and Bitcoin too) only the hash of the public key is known; the public key remains unknown (unless the holder chooses to publish it ahead of time for some reason) until a valid transaction is presented. That's why I said earlier that some wallets may be resistant to quantum computers today. So, if no transaction is made, then a quantum attackers doesn't have the information needed to launch a "fast" Shor attack, and is instead, forced, to use Grover's "slow" algorithm.
  8. Thanks for sending your resume in. I don’t know the details of the internal process that or recruiting folks follow once a resume comes in, but please don’t think that a lack of response is indicative of anything other than a backlog as a result of a massive amount of applications coming in. At the very least, our system should issue an automated “thank you” e-mail. If it doesn’t, that’s a mistake on our part and one I will ask to have corrected.
  9. Amendments weren't available at the time. The code was finished and enabled in commit https://github.com/ripple/rippled/commit/ce31e26f580044f89b960d76e12f39674e577ea0 which made it in on February of 2016. Also, please note: issuers of IOUs could (and can continue to) choose to not honor their obligations; the only recourse users had was either public shaming or legal action against the gateway. This is true whether the Freeze feature was implemented or not. The introduction of Freeze didn't change any of that. The only "change" was that issuers could freeze an IOU such that it couldn't be traded or used in any way other than having it returned to them.
  10. To be perfectly clear, I think that any such change would be ill-advised if not down right stupid and that it would never happen; anyone proposing it would be laughed out of the room. But let's think outside the box. After all, code can always be changed and no mechanism could ever prevent that. I'll start by pointing out that this isn't unique to Ripple; Bitcoin's 21 million BTC limit could be raised by changing the code too. The code inside a pacemaker could be changed to shock your heard to the tune of "Ice Ice Baby". The "the code can be changed" attack just doesn't carry a lot of weight with me. Sure, it can. But that doesn't mean it will. What if it did happen? The ultimate safeguard in these systems are people; the people who maintain the code, the people that operate servers and, ultimately, the people that use the system. Let's look at those groups, one at a time: First are the people who maintain the code. I can tell you I would not write code to increase the amount of XRP and I would not allow such code to merged into the code base while I am responsible for it. I'd resign, if it came to that. Which brings us to the people who operate servers: they choose which version of the software to run and can't really be forced to run it. Would they agree to upgrade to code that changes one of the core invariants of the system? My bet is that they would not. Lastly, there are the users; the last line of defense. If the system changes from under their feet, then will they continue to use it? Users value stability and they don't want a system that changes from under them in ways that contradict the system's core principles. If the amount of XRP was increased, what would those users do?
  11. Payment channels are NOT limited in any way. When you create a payment channel you pay a small fee (currently, 10 drops or 0.00001 XRP is sufficient). When you close a payment channel and settle it, you pay another small fee (again, , 10 drops or 0.00001 XRP is sufficient). Once the channel is setup you can operate the payment channel off the ledger, limited only by your CPU and the connectivity of the two endpoints. This part happens off the ledger, so it's not bound in any way by the 1,500 tx/sec figure and there are NO fees associated with these off the ledger messages. As for speed, according to https://ed25519.cr.yp.to/ed25519-20110926.pdf, an average quad-core CPU should be able to do over 100,000 Ed25519 signature operations per second. This figure will, obviously, only get better as CPUs get faster. Obviously, at 100,000 sigs/sec, the bottleneck isn't the signing, but the networking between the two endpoints.
  12. Yeah, the node_size can have a dramatic impact on RAM. It's almost always better to leave that value to "tiny" or "small"
  13. Interesting. We appreciate the feedback and will look at the increased I/O.
  14. Of 764434096B4BAE921F89F2ABB2481BE062BB9B633C182039296A7DF3CDA44028? I don't think anything about it really. According to XRP Charts it's a payment for a little over 1 billion XRP.
  15. It's just the version number of the client being used.