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. XRP Ledger core server, rippled, v1.5.0 has been released! You can read the full v1.5.0 Release Announcement on the XRPL Blog. Also, we've published a whole bunch of changes to the documentation on xrpl.org, including: Known Amendments has the new protocol amendments listed and statuses updated: https://xrpl.org/known-amendments.html New fields in the response to the submit method: https://xrpl.org/submit.html#response-format server_info method updated with more recent examples and updated time fields: https://xrpl.org/server_info.html New manifest method: https://xrpl.org/manifest.html New validator_info method: https://xrpl.org/validator_info.html New fields in tx method providing for more robust Not Found errors: https://xrpl.org/tx.html#not-found-response Updated account_channels method to reflect bug fixes: https://xrpl.org/account_channels.html Instructions on how to enable the new gRPC API on your rippled server: https://xrpl.org/configure-grpc.html New warnings in API responses if your server is, or is about to be, amendment blocked: https://xrpl.org/response-formatting.html#api-warnings Request Formatting updated with better formatting and new API Versioning information: https://xrpl.org/request-formatting.html Other very minor cleanup and corrections Let me know if you have any questions or comments, and enjoy the new version!
  2. I think of not being on the recommended UNL as kind of like being in an athlete in a minor league. You may not have any impact on the outcome of major-league games, but it's still important that you're playing. First off, that's how you prove you're ready for the major leagues. Second, those who are already in the major leagues are held to a standard of performance that's in based in part on those in the minor leagues. If a recommended validator is not living up to the standard of those who are validating but not currently recommended, I expect those statuses to change. (Though, it's a bit more complicated since identity and reputation are important factors in what makes for a good validator; you can only get so far on easily-measured objective stats alone.) No entity should have more than one validator on the recommended UNL, but it has always been part of the plan for Ripple to slowly reduce its share of validators until it's no more important than any other entity that uses the XRP Ledger. That's still the case. Last I heard, we're still hoping to get down to just one Ripple validator on the recommended UNL. It's an open question whether entities should run hot/active backup validators. I could see something like the validator grouping (#2601) possibly working out, but I'd like to see some research first. It might also decrease fork-safety too much to be worthwhile. Why not? It's not like serving up ledger data has any impact on validation unless you're overloading your server. As long as your availability is good, your policies are fair, and your reputation shows you're taking this seriously, I don't see any reason you couldn't use your validator for some other stuff, too. It might even make your validator's availability higher because more people would be interacting with the server on a regular basis. Automated monitoring is fallible and doesn't always detect partial outages that people actually do notice. I'd like to give all-purpose validators a fighting chance to prove their reliability, than limit who can run a validator based on stringent precautions. Let the evidence decide what's best for the network. Easier said than done, but I strongly believe the current validator list system needs improvements and I have been pushing within Ripple for improvements on this front. We've just rolled out toml-based domain verification, which doesn't require Ripple's intervention, so anyone can verify a domain's and validator's owner are the same. The company has also dropped below 20% just recently, so for the first time Ripple no longer has the power to unilaterally delay an amendment from becoming enabled. These are important and concrete changes, but as always it's just one step at a time. I personally would love it if the community stepped up to the plate to improve the current validator list process. I don't know if that means making a certification standard, creating a competing list, implementing code for multi-signed lists, or something else. But it starts with someone taking the initiative. Even if something like that fails to gain traction, nothing will happen unless people are willing to try. As laughable as corporate values often are, one of Ripple's is "Go For It," and I think we've proven that we do. I hope someone in the community lives by the same standards.
  3. I disagree. If you're not on the recommended UNL, there's certainly no harm in you validating ledgers from a machine that you also use to look up transaction history, process XRP withdrawals and deposits, etc. This is (sadly) true and it gives @nikb fits when one is down for more than a few minutes. The network needs > 80% of trusted validators to be online and functioning at all times, but we'd really like to minimize the amount of downtime validators have to make the network more resilient even in the face of more extreme events. But this is also why it's generally fine to validate ledgers from a server you're using for other purposes. If your server gets overloaded because you made too many difficult queries all at once, maybe it has some partial downtime while it catches up. That's still better than not validating at all. Validating is a really small amount of overhead on a server. The only reason not every server validates by default is that it's how many unique entities, not how many servers, that really matters. If every server was a validator, then there could be confusion over which server from a particular business you should trust.
  4. I've raised the issue internally, but I'm not sure if we'll be able to effectively separate these scam connections/transactions from ordinary, benign traffic. Depends on some things like if they're connecting from the same IPs consistently, and if there are any clues we could use to disconnect them. We shall see. But in the meantime: There is no "Ripple Reward Tool". It's a scam!
  5. Even better, send the XRP to addresses that are selected at random from a carefully cultivated list, so the money goes to useful purposes instead of just being tossed into the void. What's that? The list only has one address? Don't worry, that's a security feature. I can personally assure you that I trust everyone on that list 100%.
  6. Since there seems to be some slight confusion about it in this thread, I'd like to clarify some bits about transaction costs burned. First, Stellar's fees work differently from the XRP Ledger's transaction costs. A couple years back Stellar implemented an "auction" system so that the XLM actually destroyed when transactions are processed is up to the amount those transactions specify. This saves people money but means you can't intentionally destroy XLM by setting a large fee. Because of this, when the Stellar Foundation burned their large amount of XLM, they did it by blackholing. The XRP Ledger, at a protocol level, always uses a fixed cost mechanism: every transaction destroys exactly the amount of XRP written into the signed transaction instructions ("Fee" field), or the network rejects it¹. If you explicitly specify a transaction cost, you can be assured that if the transaction gets shared to the network, it will destroy that exact amount of XRP. ¹ The only exception to the rule that a transaction pays its exact cost is for a specific edge case. It's theoretically a transaction gets distributed throughout the network and achieves majority support in consensus because the sender had enough XRP to pay the cost at the time, but due to other transactions being in flux, the sender ends up with less XRP than the transaction's cost at the time the transaction would be executed. In this specific case, the transaction fails but is included in the ledger with the code tecINSUFF_FEE, and instead of destroying the full transaction cost amount it destroys as much as it can (resulting in the sender having a balance of precisely 0 XRP). However, many transaction-signing utilities, including ripple-lib, allow you to omit the "Fee" field. In this case, the transaction signing utility chooses a "Fee" value for you and writes it into the transaction instructions before signing them. Typically this means the utility asks an XRP Ledger server what cost it needs to send the transaction right away. There are ways this can go wrong—if the cost to get a transaction is temporarily elevated due to a passing spike in activity on the specific XRP Ledger server you asked, you can end up destroying much, much more XRP than is reasonable. Of course, it's also possible to "fat-finger" and put more zeroes than you meant when specifying the transaction cost explicitly. Both rippled and ripple-lib have precautions against specifying too high a fee. However, ripple-lib did not enforce maximum transaction cost by default until version 1.0.0 added a new global setting "maxFeeXRP". With the new global maximum, ripple-lib flat-out refuses to sign a transaction if the transaction cost is too high. (You can get around it by explicitly specifying a bigger maxFeeXRP setting when you instantiate the API.) I believe that is the "max fee" that @SquaryBone is referring to: However, there are still ways to sign a valid transaction with as big of a "Fee" value as you want. If you have that much XRP and you submit that transaction to the network, you can burn precisely as much of your XRP as you want. This last bit is a personal note: I don't recommend burning XRP.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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' // }
  12. 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.
  13. 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!
  14. 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.
  15. 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.
  • Create New...