Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank

Profile Information

  • Gender
    Not Telling
  • Ripple Address

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The server should not enforce maximum transaction costs because then normal people can't do business at all when the ledger is being DoS'd. People need the choice of either doing their business now at higher cost, or deferring business until costs decrease. I believe the correct way to handle this stuff is to set a maximum transaction cost on the client side, preferably during/before signing, so you can't get a signed transaction that would burn a high transaction cost by accident. Then, add a setting to bypass this limit for a specific transaction. Basically, an "in case of emergency, break glass" kind of setting to make through a transaction with a big cost ripple-lib has had such a setting since version 1.0.0. I recommend those who write client libraries in other languages add a similar rule.
  2. That part is accurate and correctly uses the current terms, though...?
  3. How big are your debug logs? That's another source of disk usage that grows over time. The docs don't go into a whole lot of details on log rotation, but that's another thing you should keep an eye on. (Note to self, add that to the capacity planning docs.)
  4. I will be referring to the 16-byte seed value as the "seed", "seed value", or (if absolutely necessary) "secret seed" based on what fits best in that context. I'll get back to you on whether I settle on "private key" or "secret key" for the 32-byte value that is directly used with the signature algorithm. I want to bring it up with more stakeholders / cryptography people at Ripple to get their takes on it. I'm leaning toward "private key" though. I might make room for a generic term that means "any seed, private key, or passphrase that should be kept secret". Possibly "secret" or something along those lines. Not yet sure. Here's a PR starting this work: https://github.com/ripple/xrpl-dev-portal/pull/705
  5. Those of you who've noted that the terminology is confusing have a good point. It was confusing to me until this latest work, which spilled over into some of the docs. I'll update the "sign" method and keep an eye out for other places that need to be adjusted as well. Unfortunately many of the places I see it used elsewhere outside of XRPL.org are inconsistent and I don't have as much control over that. Fun fact: I was actually using the term private key in an earlier draft, but it was changed to "secret key" after review to match the conventions used in the rippled source code. (I guess "pk" is used there as an abbreviation for "public key" while "sk" is used for "secret key".) I do still kind of like "private key" because in addition to what you mentioned, there's a base58 encoding (unused, I think) for full private keys, which uses the prefix "p" as opposed to seeds using the "s" prefix.
  6. As part of our ongoing effort to describe and specify the XRP Ledger technology, down to the deepest details, the XRP Ledger Dev Portal now has expanded documentation and sample code for the process of cryptographic key derivation. Without quite delving into the theory behind the cryptography, the new docs show the steps to go from a passphrase, to a seed, to an actual keypair that can be used to sign transactions using well-defined elliptic curve math. The new Python sample code even doubles as an offline utility for generating or deriving secret keys. (It doesn't get all the way to address encoding, so maybe that's an exercise for you, the reader, to go through!) Incidentally, if you are interested in learning the cryptography itself, an item added to my reading list as a result of this work is Modern Cryptography and Elliptic Curves by Thomas R. Shemanske, which comes heartily recommended by several members of the rippled team. I hope this work helps, in some small way, to extend the XRP Ledger technology to new platforms, new programming languages, and new use cases.
  7. If you use the JSON-RPC interface (such as through curl) you can specify a specific ledger index in the ledger_data command. If for some reason that's not working, please file an issue with the steps you're using so we can try to reproduce.
  8. Yes, you've basically been describing Escrow all along. Of course, the XRPL's Escrow feature currently only works with XRP because you can make much stronger guarantees with a native digital asset than you can for an issued currency, and the details around how you would actually set aside balances of an issued currency (move it out of the trust line??) are a little more complicated. Not that Escrow couldn't theoretically support issued currencies, but there are some details that would have to be worked out and caveats that would have to be accepted first. In fact, I'd love it if someone put out a standards draft for issued currency escrow. If it were comparable to the one for Deletable Accounts then it could probably get implemented without much trouble.
  9. Personally, I'd like a health check method that summarizes the statistics into something easy to grok and take action on even in an automated fashion. It would also certainly make server administration easier if the rippled server's log messages were less noisy. A whole bunch of the known log messages at the warning level are only concerning if they occur outside of the syncing period or recur consistently. I think a great start for cleaning up the rippled server log would be to have a (tunable) sync time parameter, such as 15 minutes, and a class of messages that aren't considered warning-level messages if they occur within that amount of time after starting up. Similarly, the server could report increasing severity messages if it still hasn't fully synced by the end of the sync period & increasing intervals thereafter.
  10. Interesting and promising idea, but the latency issues might be killer. Still, intranet speeds are fast and getting faster, so it might be doable. I'm skeptical how many entities would really have the interest, expertise, and motivation to set up a network database though. I wonder if the same concept could be expanded to implementing a completely diskless server, though. If you can keep all the things you need for validation in memory, you could do away with the node store entirely and track just the latest validated + in progress ledgers.
  11. The "Checks" amendment, as designed and implemented, handles receipt validation fairly elegantly already. The sender has to sign a transaction to send the Check, and the address already has the checksum built into the address, so simple typos probably couldn't result in the money going to a valid address. (Copy-paste mistakes are a different problem that's harder to solve, of course...) And the recipient has to send a transaction to receive the Check, so the recipient can't actually get the money unless they cryptographically sign a transaction specifically trying to do so.
  12. I think this is an interesting idea that could have some cool benefits, but it would probably be best studied from a theoretical basis to make sure whatever design we come up with doesn't have any pitfalls that could be abused or unintentionally cascade into a worse situation. For example, I'd want to be fairly confident that a gradual split in network connectivity couldn't result in two networks diverging along the lines of whom they temporarily can't see; and similarly, I'd want to make sure a small but coordinated group of malicious validators couldn't conspire to get honest validators placed on the "unreliable" list through some trickery. I'm optimistic that we could design around those sorts of problems as long as we take the time to plan things out.
  13. The "governance layer" could be Cobalt or something else with similar properties, right? Meanwhile, the inner layer could benefit from the (well-studied) efficiencies of a consensus protocol whose participants are known in advance, allowing the ledger to advance even faster, right? This seems like a very complicated change, and the switchover would be especially tricky. But the benefits could be a big deal. I think I'd lean towards incremental improvements in validator list management first. Actually, come to think of it, the "validator list" system kind of resembles this, doesn't it? The small set of participants in the recommended UNL could become the "inner layer" that do transaction processing, and the set of participants who declare consensus on a "recommended UNL" would become the outer layer. Maybe we should think about the path to reaching this through that lens.
  14. Seems like a good optimization with minimal user-facing changes. It's not flashy, but I think it would be great.
  15. Yep, it's in the docs: https://xrpl.org/setfee.html Maybe I should add a note there about the fact that this isn't true in historical data...
  • Create New...