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
  1. When we say issued currencies have "15 decimal digits of precision" what we mean is that it uses decimal math (no floating point rounding weirdness) and at most 15 continuous digits of the issued currency can be nonzero values, regardless of where the decimal point is. So you can have 1.23456789012345, or 999999999999999 or 0.00000000000000123456789012345 but not 100000000.0000001. If you make a payment that is outside the precision of an issued currency, the remainder is rounded. In your example of someone who has 10000000 FOO and you send them .00000001 FOO, your balance will decrease but theirs won't increase. This was a conscious choice when the system was created. To paraphrase @JoelKatz, "If you have a trillion dollars and I pay you two hundredths of a cent, are you even going to notice? But you still have to consider the payment made since I spent my 2/100 cents."
  2. mDuo13

    Ripple Names API

    Yes, it's deprecated. No new names can be added. I should really update and publish the webfinger-based spec that I drafted up as a decentralized way of associating names with Ripple addresses...
  3. I think the answer is yes. Here's a type-script example from ripple-lib that uses that library to sign transactions: https://github.com/ripple/ripple-lib/blob/develop/src/transaction/sign.ts
  4. Run rippled as a validator and go through the Domain Verification process Demonstrate high agreement with the rest of the network, high availability, and fast upgrades to new releases over an extended period of time. (See also: Properties of a Good Validator) Show a dedication to the XRP ecosystem and a commitment to be around for the long term (a few years at least). That's easier to do if you're representing an organization rather than yourself as an individual. Ripple is working on improving the Domain Verification process, by the way, so it can be more transparent and more decentralized. I'm sure @nikb will be very excited to share more details when he's ready.
  5. mDuo13

    Third party xrp ledger implementations?

    There are no third party implementations of the XRP Ledger that I know of. It would be very hard (but not impossible) to build one. Transaction processing, in particular, must work exactly the same way or you won't be able to stay in sync with consensus. http://developers.ripple.com/ provides a start. You can also look at stuff like https://github.com/ripple/ripple-binary-codec which reimplements the binary ←→ JSON format conversions in JavaScript. But at some point you're probably going to have to refer to the C++ source of rippled to figure out how some stuff works.
  6. mDuo13

    Payment Channels discussion/info

    Yes, Interledger settlements, including Coil, are the vast majority of Payment Channel transactions on the XRP Ledger.
  7. Spent some time trying to understand the Riemann and Fine Structure Constant papers without having a background in advanced math. (I stopped formally at Calculus; that **** was the worst.) As you might expect, it did not go well. That FSC paper in particular is crazy. Not sure if Atiyah has attained enlightenment or just stretched a bit too far, but with things like mapping fundamental forces of the universe to categories of mathematical equations/numbers it's sure grandiose. I think the Riemann Hypothesis proof doesn't have any immediate implications for cryptography because the proven result matches what mathematicians already suspected. But of course, the technique he came up with can potentially do a lot of things. Proving Riemann is pretty much just a byproduct of the rest. I wouldn't be surprised to see some new cryptographic techniques—ciphers, solvers, or both—come out of this work.
  8. mDuo13

    rippled source code analysis and audit

    Caught one minor mistake: The [ips_fixed] section lets you specify other servers to connect to, but they aren't treated as part of a cluster unless you specify specific public keys in the [cluster_nodes] section. I can see how one could misread the clustering tutorial since it contains an example for [ips_fixed] but not for [cluster_nodes]. Will fix!
  9. Awesome to see people actually building good stuff on the XRP Ledger! I have to say, though, I'm just squirming with excitement for the future. Right now it's like we're only at step 1 (get money in), when you really need the full circle to get value. Maybe by the next time I plan a trip to Europe, there'll be an easy way to convert my¹ XRP back to Euros? (Either that, or vendors accepting XRP directly in exchange for goods and services, but I'm not holding my breath on retail.) ¹Full disclosure: the amount of XRP I currently hold is probably pretty small by comparison to most people on this forum.
  10. mDuo13

    Hide IP of my rippled

    It depends on why you're trying to hide your IP and how much budget you have to work with, but Ripple's recommendation is to run two or more rippled servers: One of them will be the private one. In the config file, set [peer_private] to 1 on this server. This should be your validator, if you run a validator. Firewall this server so it can't connect to the internet at large. The rest of the rippled servers (running on different machines) will be public. If there's more than one, they should be configured in a cluster. Their config files should have [ips_fixed] sections with your private peer's IP address and with each other. You should also add the [ips_fixed] section with these servers to your private peer's config file. These should be also behind the firewall with your private server, but with the firewall opened to allow connections to the public servers. The result is you have a private server that can only speak to (and hear from) the outside world through your public servers. And your public servers are sworn to secrecy on the private server's IP, so they won't tell everyone where to find it. But thanks to the power of cryptographic signatures, people can still confirm that the messages from your private server are authentic.
  11. mDuo13

    Node/Validator Backup strategy

    You should never run more than one validator at a time with any given validator key pair. It's OK to stop running one and then run another with the same key as long as they won't run simultaneously. I recommend keeping your validator keys in an offline backup only and intervening manually if you need to replace/migrate your validator. Node seed keys are useful for clustering but ultimately optional. If you're not clustering I recommend letting servers generate ephemeral node_seed values. I'm not sure exactly what rippled stores in the wallet.db file, but I know you can safely delete all the databases and restart while keeping your existing node/validator seeds.
  12. mDuo13

    rippled source code analysis and audit

    rippled always uses an SQLite database to store some transaction history. Additionally, the core ledger store can use either RocksDB or NuDB (both are included in the rippled source code). RocksDB is better or about even for most use cases, but NuDB is better for storing lots of historical data on SSDs without using too much RAM.
  13. You do not need to use NuDB to store history shards. The shard store is separate from the ledger store: Ledger Store ([node_db]) Required Contains recent ledger versions Back-fills to the number of ledger versions specified by ledger_history setting (256 by default) Deletes ledger versions older than online_delete setting (2000 in the default config file, disabled if you don't specify in your config) RocksDB is recommended for most cases. NuDB is OK though Shard Store ([shard_db]) Optional Contains random shards of historical data Each shard is 16384 ledger versions Downloads as many shards as can fit in the configured max_size_gb setting. NuDB is recommended for most cases. RocksDB is OK though RocksDB works well on both SSD and rotational disks. NuDB requires SSD, but requires less RAM for some usage patterns (especially when data is queried infrequently).
  14. That's correct. I guess maybe I should add some more limitations to the Escrow article: An individual escrow can have only one sender and one recipient. You cannot add to the amount of the escrow after creating it. When you finish the escrow, you must deliver the full amount. You cannot deliver part of an escrow. If you want to lock up escrow from several senders, you have a couple options: Create a bunch of separate escrows, one from each sender. (If you're using a conditional release, you can use the same condition on all of them, if you like.) Downsides to this approach include: You have to send separate transactions to finish each escrow. (Probably just 10 drops for time-based escrow; more than that for conditional escrows.) If you want to know how much is escrowed, you have to find all the parts and calculate their sum. Some addresses have to commit their funds to escrow before others, so theoretically some of the senders could back out after other senders have locked up their money. Each sender has to set aside 5 XRP for the owner reserve of the escrow while it's locked. (They get the 5 XRP back when the escrow is finished or canceled.) Or, aggregate the XRP into one sender, then send the escrow from that sender. Downsides: If you fund a new address to use as the sender, you have to give the aggregate sender an extra 25ish XRP (20 for the account reserve, 5 for the owner reserve). Most likely, nobody is ever getting the 20 XRP account reserve money back. Whoever owns that address has full control of the XRP until they escrow it. Hope this information is helpful!
  15. mDuo13

    rippled source code analysis and audit

    Thanks for linking into the existing docs for a bunch of this stuff. By the way, if you want to know more about the sqlite vacuum stuff that's in int main(), there's a new doc (just waiting for the rippled 1.1.0 release) that explains what it's for and when to use it. Basically, if you have a full-history database that you started on an old version of rippled (<0.40), you can run out of space to store transactions due to limitations from the SQLite page size setting, so the VACUUM thing lets you migrate to a new SQLite database with larger capacity. New full-history rippled servers don't have this problem because they configure SQLite DB with the larger page size setting from the start.