Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by mDuo13

  1. I think I remember hearing that during some of the recent periods of high transaction activity, one of the validators completely saturated its 100 MBit link. Most of the time it's not that high so you could get by with 50 mbps more often than not, but you might not be able to keep up with high volume periods. That's still helpful to the network, but you wouldn't be a good candidate for the recommended UNL with that kind of network link. Still, more information on how to run a validator would be helpful and those kinds of contributions could lead to improvements in the overall ecosystem.
  2. Tickets are not fully implemented at the moment. There's a concept, a spec, and some implementation work, but they're not available in the production XRP Ledger. When they're done, I think they'll do what you're looking for although not quite in the way you've suggested. If you want to execute transactions in a different sequence order than you signed them, you could explicitly provide the sequence numbers when you sign the transactions. Of course, that only works if you know what order you want them to execute in at the time you sign them. Otherwise, you need tickets.
  3. The XRP Ledger supports "IOU" currencies, also known as issued currencies. Basically they're stablecoins or arbitrary tokens. You can trade them in the XRPL's decentralized exchange. The XRPL also supports "Escrow" where XRP can be locked up so that literally no one can use it for anything in the XRPL until a specific time or condition is met. Theoretically you could also do something like this for issued currencies, but right now the XRP Ledger only supports Escrow of XRP. The main reasons the XRPL doesn't support escrow of issued currencies are as I described in my previous post, above. This question doesn't exactly make sense, because by definition a cryptocurrency (in its own network) is not an IOU. So the XRP Ledger (the blockchain) does not support escrow of IOUs. Neither does the Stellar network, as best I can tell (though you can do some interesting things with their "Minimum Time" feature). You could theoretically do whatever you want on the Ethereum network since it has a general-purpose, turing-complete programming language... but good luck getting that to work. Same goes for any other blockchain with a similar turing-complete decentralized-app platform built into the chain. The XRP Ledger is intentionally not a general purpose, turing-complete platform. It's intended for payments, specifically, and fast. Complexity is often the enemy of speed. That said, I think the ability to create arbitrary tokens native to the XRP Ledger has some good potential and if that ever caught on I could see issued currency escrow being a feature that's worth the effort and complexity involved.
  4. It seems like it should be possible to implement in the XRP Ledger, but it's not currently implemented for a few reasons. First, there is the question of value added. Escrowing XRP in the XRP Ledger provides for very strong guarantees, since that's where the XRP natively exists. The escrow has a direct and powerful influence over where the XRP exists and who truly has control over it. With issued currencies, if the currency is an obligation for an out-of-ledger asset (that is, a true "IOU" and not yet-another-digital-token), then whoever's custodying the underlying funds technically has the power to move and use the "escrowed" asset regardless of what the XRPL says about the IOU. Sure, with XRP you could always sell/rotate the keys to the destination of an escrow to change who would receive it, but the escrow still puts very strong and specific limits on what can be done with the XRP while it's escrowed, which don't apply to IOUs. For any "issued" asset in the XRP Ledger that is actually native there—kind of like the "ERC-20" tokens on Ethereum, but issued on XRPL instead—then issued currency escrow could be similarly powerful to XRP escrow. So, at the very least, that's one potentially strong case for issued currency escrow. On the other hand, there are very few natively issued tokens on the XRP Ledger today, just a few experimenters and trailblazers like Allvor. So there's not a big market demand for this at the present. Second, there is the question of complexity. XRP escrow is very easy because every account in the XRP Ledger can hold an unlimited amount of XRP, and the XRP can be sent directly to any one of them. Issued currencies, by contrast, have to flow through paths and be stored in trust lines, which have maximum values that can change. Even if you created an issued currency escrow today, it's possible your intended recipient couldn't receive the XRP when the escrow is finished. Issued currencies can also have transfer fees, which can fluctuate as well, and trust lines have quality settings which can have some unexpected consequences. And that's not an exhaustive list of the complications that are specific to issued currency escrow; those are just the ones I've thought up in a couple minutes. None of these problems are unsolvable, but they are complex. To implement Escrow for issued currencies, you'll have to think through all the possibilities and consider each one. That requires a very deep understanding of how issued currencies work in the XRP Ledger, and having the time and methodical thinking practice to not only do this but convince others that you've done so responsibly. (Most likely, convincing others means writing a specification that walks through everything.) Ripple's employees did the cost-benefit analysis and decided they have other things they'd rather do first. But if you really want to make it happen, by all means, go for it.
  5. I think ripple-lib on its own doesn't have an easy way to do that. That would be a good idea for a feature request! I think it shouldn't be too hard to implement, because the library internally has the ability to deserialize transaction blobs and the rippled equivalent API already returns both the JSON and binary formats. That said, you can decode the binary pretty easily by using ripple-binary-codec, which is one of ripple-lib's dependencies. For example: const binarycodec = require("ripple-binary-codec") const tx_binary = "120007220000000024000195F964400000170A53AC2065D5460561E"+ "C9DE000000000000000000000000000494C53000000000092D70596"+ "8936C419CE614BF264B5EEB1CEA47FF468400000000000000A73210"+ "28472865AF4CB32AA285834B57576B7290AA8C31B459047DB27E16F"+ "418D6A71667447304502202ABE08D5E78D1E74A4C18F2714F64E87B"+ "8BD57444AFA5733109EB3C077077520022100DB335EE97386E4C059"+ "1CAC024D50E9230D8F171EEB901B5E5E4BD6D1E0AEF98C811439408"+ "A69F0895E62149CFCC006FB89FA7D1E6E5D" const decoded_json = binarycodec.decode(tx_binary) console.log(decoded_json) // { // TransactionType: 'OfferCreate', // Flags: 0, // Sequence: 103929, // TakerPays: '98957503520', // TakerGets: { // value: '1694.768', // currency: 'ILS', // issuer: 'rNPRNzBB92BVpAhhZr4iXDTveCgV5Pofm9' // }, // Fee: '10', // SigningPubKey: '028472865AF4CB32AA285834B57576B7290AA8C31B459047DB27E16F418D6A7166', // TxnSignature: '304502202ABE08D5E78D1E74A4C18F2714F64E87B8BD57444AFA5733109EB3C077077520022100DB335EE97386E4C0591CAC024D50E9230D8F171EEB901B5E5E4BD6D1E0AEF98C', // Account: 'raD5qJMAShLeHZXf9wjUmo6vRK4arj9cF3' // }
  6. I don't think there's a trivial solution to this problem with the existing API. If you subscribe to all transactions and the ledger stream, you can look at the ledger's txn_count and then count transactions to know when you've seen them all. (I'm not sure if it streams them in order, but if it does you could also just look for the transaction whose meta.TransactionIndex is one less than the txn_count.) But if you're only subscribed to an order book, most of the transactions won't affect that book so that won't get you there.
  7. To sign a transaction offline, you need to provide the correct Sequence (sequence number) and Fee (transaction cost) values. You can't use fee_mult_max / fee_div_max because those are just setting limits on what the auto-provided Fee value would be. Since the XRP Ledger is still operating below capacity, 10 drops is enough for almost any transaction. (See Special Transaction Costs for a list of exceptions.) You could provide a higher value just in case something happens and the ledger gets really slammed and you don't want to wait. But basically, just hard-code a Fee that seems reasonable to you. The Fee should be written as an integer number of drops in string format (this is the rippled API format). The Sequence number depends on your account. To sign offline, you have to know your account's current Sequence number. It's just a positive integer, nothing special about it. You can look it up with getAccountInfo if you don't know what your account's current Sequence number is; it won't change unless you send a transaction. (When your account is first created, the Sequence number starts at 1. This will change if/when DeletableAccounts gets enabled, so brand-new accounts' Sequence numbers will start at the current ledger index instead.) Anyway, whatever your account's current Sequence number is, your first transaction uses the same Sequence number. Then the next transaction should use a Sequence number that's 1 higher, and the transaction after that uses a Sequence number that's 1 higher than that. So putting that together, here's your code, modified: let seqNum = 5; // whatever your account's current Sequence number is const txJSON1 = { "TransactionType": "Payment", "Account": fromAddress, "Amount": amount, "Destination": toAddress, "Fee": "10", // This minimum Fee is enough for the vast majority of cases "Sequence": seqNum, "DestinationTag": dTag, }; const { signedTransaction1 } = api.sign(JSON.stringify(txJSON1), privateKey); seqNum += 1; // Increase sequence number const txJSON2 = { "TransactionType": "Payment", "Account": fromAddress, "Amount": amount, "Destination": toAddress, "Fee": "10", "Sequence": seqNum, "DestinationTag": dTag, }; const { signedTransaction2 } = api.sign(JSON.stringify(txJSON2), privateKey); You can repeat that any number of times and then submit all the transactions at the same time. If for some reason one of the transactions doesn't get accepted into a ledger, then all the ones after it won't get accepted either. (This is one of the reasons that transactions fail with "tec" codes and get included in ledgers rather than just being forgotten about when they fail.) Feel free to submit the same signed transaction multiple times, by the way, in case something seems off. It won't get processed more than once. If it really comes down to it—maybe you signed transactions with sequence numbers 11 through 13 but transaction 11 is malformed or something—you can go back to your offline machine and sign just a replacement transaction that uses sequence 11, submit that one, and then your previously-signed transactions 12 and 13 should be good to go. (See "About Canceling a Transaction") Hope that helps!
  8. Ripple manually updates the recommended UNL on a regular basis (usually there's an update about once per month, sometimes with no changes other than a new expiration date). This process involves monitoring nodes for appropriate behavior (for example, not censoring transactions; processing transaction outcomes the same way the vast majority of the rest of the network does), performance (uptime, reliably participating in every consensus round, etc.), identity (not sockpuppets or aliases of other UNL members), and resiliency (commitment to long-term support; geographic variation, etc.). Coil publishes a matching list signed by their own keys, which is intended to match Ripple's list. If there's a disagreement between which validators are included in the lists, it might be worth investigating. Technologically, the list is defined by vl.ripple.com (vl.coil.com for Coil's) and signed by a key pair that is published by Ripple and distributed in the default config file of validators.txt which is installed with the default install package but is user-editable. (RPM/DEB updates are configured to overwite that file automatically if necessary; if you want to set custom settings that don't get overwritten, you can change the [validators_file] stanza of your config to use a different file.) If you use custom settings that don't overlap at least 90% with the rest of the network's list of validators (which largely follows Ripple's recommended list) then you have a chance to diverge with gets higher depending on network connectivity/latency and the amount of difference between your list and everyone else's. If Ripple ever does something to lose the community's trust, the community can switch over to some other, more reputable list—be it Coil, or some other community-started list, and the network can continue on after doing so. Untrusted validators serve the important purpose of providing a point of comparison in how transactions were expected to process, so you can recognize if validators are censoring transactions or following strange rules for transaction processing. Of course, take untrusted validators' information with a grain of salt, since their identities aren't verified so anyone could start up a whole bunch of validators and claim that they're all different people.
  9. 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.
  10. That part is accurate and correctly uses the current terms, though...?
  11. 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.)
  12. 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
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. Seems like a good optimization with minimal user-facing changes. It's not flashy, but I think it would be great.
  23. 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...
  24. This is one of the areas I'd love to see prioritized most. (In part because it doesn't require any work from me! ) But I think bringing down the hardware requirements—or even just, keeping them where they are as commodity hardware specs improve—will do a lot to facilitate the growth and decentralization of the core peer-to-peer network. If the next Raspberry Pi could be a reliable validator, imagine just how great that would be!
  25. The public spec defines a transaction that the account owner sends, which tracks down everything tied to the account that can or can't be deleted, and does that if possible. I think that's a great approach. (Actually, the spec itself is just fantastic work. Thanks especially to Scott Schurr for putting a ton of research effort into the thing.)
  • Create New...