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. To be clear: nothing and nobody can stop you from doing it. But other servers will quickly start treating your validation public key as belonging to a Byzantine or malicious validator.
  2. Please don’t configure two separate validators with the same key. Your validator will, in essence, appear as a single validator exhibiting Byzantine behavior.
  3. I think that validator operators do make an explicit choice: to upgrade or not to upgrade. If I choose to install 1.3 (when it becomes available) isn’t that me explicitly making a choice? I can make further explicit choices: to opt to veto amendments introduced in 1.3. Conversely, if I choose to remain on 1.2, isn’t that me explicitly making a choice too? I can, again, make further explicit choices: to support amendments that my server doesn’t know about (and there are reasons I may want to do that).
  4. I agree with you: validators should not automatically pull updates. But an unattended update isn’t always automatic.
  5. I respect you and give a lot of weight to your opinions/positions because of that. I was a big fan of an “abstain” mechanism and argued in favor of adding it. I was, after talking to my colleagues, convinced that it only complicates things and offers no benefits. I genuinely think adding such a thing is a bad idea. The explicit requirement is interesting, but one that may or may not fly with validator operators. It’s a UX nightmare too—there is no UI here; just a command to update a package (or a set of commands to compile from source). Would the server just error out and refuse to start until admins manually edited a config file? This would make unattended automatic updates impossible and would lengthen the upgrade cycle when we should be looking to shorten it. Agreed 100% and that’s already being phased out; see https://github.com/ripple/rippled/pull/2873 for example. We had already planned to do this anyways because referencing JIRA tickets is unhelpful if the JIRA is private. Once the community spoke up and made it clear that they wanted improved naming, we bumped up the priority of this.
  6. My position is that upgrading to a newer version of the software which supports a specific amendment is tacit approval of that amendment, hence why the default opt-in behavior makes sense to me. Your mileage may vary. If you believe (as you seem to) that the default behavior isn’t ideal, by all means submit a pull request making the necessary changes. Submit it as an amendment, and lets allow the network to decide the semantics that it prefers. I disagree that you can do what I’m proposing with an Escrow. First, escrows don’t support IOUs. Second, escrows lack some of the features that checks have (e.g. the ability to partially cash a check). Lastly, a future extension to allow a check to be cashed out in a different currency by doing a live trade is superior to the multi-step process you describe. On this topic, don’t fall prey to the logic of “well, X is almost the same as Y, so just use Y and let’s not do X.” As for ideas: please open issues on GitHub for your ideas. It’s where we want to migrate our internal tracking board, so that we are all working from the same page. Also, my explanation wasn’t that Ripple is vetoing the feature because it wants more features. You may want to read what I wrote one more time.
  7. That’s exactly what I said: “Ripple [validators] [are] not voting to enable them” but if you prefer the term “explicitly vetoing” then I guess Ripple’s validators are among the validators explicitly vetoing this amendment. I can’t speak for anyone else, but in Ripple’s view, activating a new feature on the ledger is not something to be undertaken lightly; once you activate it, you have to to carry it forever and so the cost-benefit analysis matters; the pros that come with an amendment must outweigh the cons. Maybe this isn’t an important consideration for some but it is for others, myself included. With that said, my personal preference would be to further enhance checks before enabling the feature, so that we can: (1) support “certified” checks —that is checks which actually “hold” the amount internally instead of being like “drafts”. (2) allow a check to be “cashed” in a different currency; for example, I can “cut” a check for 100 USD/Bitstamp and you can cash it, at your convenience, to receive XRP or any available IOU you want by doing a real-time exchange.
  8. The validation bot is… let’s be generous and say “flakey”. The good news is a decentralized verification mechanism is coming in 1.3! Check out the first half of the solution: https://github.com/ripple/rippled/commit/88cb0e5928510d684a894ddf8a4ccc379c09d8fe Then check out the second half here: https://developers.ripple.com/xrp-ledger-toml.html
  9. Because not enough validators are voting to enable them. Specifically, Ripple is not voting to enable them; others may or not be. But it’s not for any nefarious reason. It is another feature that I don’t know if anyone will ever use so why enable it? Remember once something is activated it can’t ever really go away—it would take another amendment to prevent new checks, but the code couldn’t ever be removed as long as more than a single check existed uncashed on the ledger. An amendment is basically for life and imposes a certain cost. I think we should weigh that cost against what it buys us instead of just paying it. Look at TickSize. It’s enabled and nobody is using it…
  10. This is very high on our priority list. It probably won’t make it into 1.3 but we hope to see deterministic shards in 1.4.
  11. Hi! I opened an issue for this on GitHub: https://github.com/ripple/rippled/issues/2877. For future reference and improved visibility, when reporting potential bugs we should try to use GitHub issues so that there is improved visibility and things don’t fall through cracks: https://github.com/ripple/rippled/issues/new
  12. nikb

    Hi! I'm Bob

    I have no idea what that question means either. I hope @7Bs can clarify.
  13. nikb

    Hi! I'm Bob

    Yeah, I’m with you there. The Internet has reshaped everything it’s come in contact with. It’s an amazing force for change. You wrote that you’d “hate to repeat this pattern with the democratizing of the flow of funds and hope we can correct this with the flow of information over the next decade or so.” I agree, wholeheartedly. I joined you at Ripple because I wanted to change the way money and value flowed, by building an open system that was accessible to everyone and favored no one—a value we shared. Getting to work with you again was the cherry on top. So the decentralized exchange aspect of the ledger was a huge thing for me. I hope that more uses for that feature emerge. I hope new IOU features are added to support new and exciting use cases. Speaking of which, we had someone open a PR to extend escrows to IOUs which I thought was great. I hope he completes the changes so it can be merged. More generally, I hope that more people start contributing.
  14. nikb

    Hi! I'm Bob

    It was great pizza, wasn’t it? For the record, I didn’t doubt this was you. But figured it’d be fun to quiz you. I’m well and things are great. Glad to have you join the community again!
  • Create New...