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. I’m going to check the testnet API service; thanks.
  2. 🙄 A PR for this issue has already been merged. When the 1.3.0 release is ready and ships, it will be up to the validator operators to decide how to handle this issue by voting for or against the amendment that is gating the changes in that PR. The message for the commit says: Disallow using the master key as the regular key: The XRP Ledger allows an account to authorize a secondary key pair, called a regular key pair, to sign future transactions, while keeping the master key pair offline. The regular key pair can be changed as often as desired, without requiring other changes on the account. If merged, this commit corrects a minor technical flaw which would allow an account holder to specify the master key as the account's new regular key. The change is controlled by the `fixMasterKeyAsRegularKey` amendment which, if enabled, will: 1. Prevent specifying an account's master key as the account's regular key. 2. Prevent the "Disable Master Key" flag from incorrectly affecting regular keys.
  3. Does this help? https://developers.ripple.com/ledger-data-formats.html
  4. Ah, thanks. I haven’t been keeping up with BIP151, so good to know it was withdrawn before I coded up an implementation! I remember this issue, and we may tackle it going forward; it would certainly make it easier to connect. If someone external gets to it first, all the better. As for versioning, my goal is to start using the “Protocol” header in the HTTP upgrade to negotiate that better.
  5. I’d like to migrate away from that and use TLS 1.3 functionality. Alternatively, perhaps we can eschew TLS altogether for peer to peer use, opting to adopt BIP-151 instead. Although, we’d still need TLS for user endpoints, so it’s not like we’d remove a dependency.
  6. Several times I've struggled to explain XRP Ledger concepts to others, only to have @TiffanyHayden come up with a brilliant explanation in 140 or 280 characters. Her ability to communicate effectively is second to none.
  7. Honestly, I think that the existing generation scheme is a pain, and the way we conflate the 'seed' with a 'secret' (as Wietse points out) is a problem. My preference would be to define a new mechanism encode the key generation parameters. I came up with a new way of representing a seed, which encoded both the type (Ed25519 or secp256k1) and was more "user friendly". Here's an example 128-bit secp256k1 seed in my new encoding: 002992-186054-564520-197527-479336-662101-018205-239030-454003 Here's an example 256-bit Ed25519 seed in my new encoding: 005984-207295-416900-415811-559911-544368-575157-236995-404965-416339-352957-496848-476597-518793-247610-248468 Advantages of this format: It's only numbers! More universal than English, easier to write and less prone to mess up! Each 6 digit group has a check digit. If you make a typo in a group, you know which group the typo was in. The obvious disadvantage: WTF IS THIS?! IT DOESN'T LOOK WHAT I'VE USING UNTIL NOW!
  8. I want to start with a cryptography comment on your implementation: I'd strongly caution you against deriving a key directly from a seed using a single SHA-256 operation. Doing that leaves your users vulnerable to attacks; notice how rippled doesn't just blindly hash the seed and use it as a secret key. There are ways to strengthen derivations of a key from a passphrase/password and you should use them (e.g. PBKDF2). More broadly, as @Sukrim pointed out, your key derivation isn't "standard" in that you don't derive the key from a seed in the same way as rippled does. Strictly speaking, that's fine, but it may confuse some users who expect to have the "familiar" sWhatever secret; more importantly, it makes keys generated using your script not portable which can result in lock-in. For details on how rippled derives a keypair from a 128-bit seed, check out Generator. With that said, I personally find the derivation we use to be somewhat obscure and wouldn't mind simplifying it going forward. Perhaps a "new" standard, a-la BIP-39 which would also encode the key type (secp256k1 or Ed25519 for now, but maybe more in the future) would be a good idea. Lastly, I'd be very wary of calls like SecureRandom.random_bytes(32). Maybe Ruby has a great PRNG that is cryptographically secure and does the right thing in all cases—the docs suggests it does. But you probably don't want to depend on just that. Consider additional randomness sources.
  9. What a thread to read on a Saturday night…
  10. 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.
  11. Please don’t configure two separate validators with the same key. Your validator will, in essence, appear as a single validator exhibiting Byzantine behavior.
  12. 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).
  13. I agree with you: validators should not automatically pull updates. But an unattended update isn’t always automatic.
  14. 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.
  15. 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.
  • Create New...