Jump to content

mDuo13

Ripple Employee
  • Content Count

    507
  • Joined

  • Last visited

  • Days Won

    18

mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank
    Advanced

Profile Information

  • Gender
    Not Telling
  • Ripple Address
    ra5nK24KXen9AHvsdFTKHSANinZseWnPcX

Recent Profile Visitors

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

  1. 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.
  2. 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' // }
  3. 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.
  4. 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!
  5. 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.
  6. 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.
  7. That part is accurate and correctly uses the current terms, though...?
  8. 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.)
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...