Jump to content

nikb

Ripple Employee
  • Content Count

    911
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by nikb

  1. Your whole post is just a thinly veiled attempt to insinuate (though I’m not sure to what end) and it sickens me. What does Tiffany’s or my personal life have any bearing or relevance? Why should my employment status have any kind of impact on Tiffany and her ability to operate a server or limit the things she can experiment with, like and/or support? And as for David’s comments, I share his point of view and I see nothing strange about them.
  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.
  16. 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.
  17. 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
  18. 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…
  19. 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.
  20. 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
  21. nikb

    Hi! I'm Bob

    I have no idea what that question means either. I hope @7Bs can clarify.
  22. 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.
×
×
  • Create New...