Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by mDuo13

  1. I've proposed some edits to the page introduction that should make it easier to understand: https://github.com/ripple/xrpl-dev-portal/pull/875/files
  2. I think your problem is the lack of CORS support. In-browser tools (including the PayID validator, it seems) can't make calls to other websites unless the other website specifically allows them to. This is a protection in browsers against scripts being injected in one website to pull data off another site. The XRP Ledger toml file has the same requirement. The way to fix it is probably similar for PayID. You should add this line to your httpd.conf, maybe in the <VirtualHost InstancePublicIP:443> stanza? Header set Access-Control-Allow-Origin "*"
  3. 1. To get the final result of a transaction, use the tx command and look for "validated": true in the response. 2. Be sure to use LastLedgerSequence in your transaction so that the transaction gets a final result in a limited amount of time. (Otherwise, a transaction that doesn't quite make it could theoretically be retried forever.) 3. It's perfectly safe to submit the same transaction multiple times as long as you use the same Sequence number each time. Each Sequence number can only be used once so if that transaction or any other transaction with the same sequence number has already executed, your retry won't send additional times. The Reliable Transaction Submission guide describes this process in much more detail, including how to take precautions so you don't have duplicates in case of power outage or whatnot. As for why the tentative result is a "ter" code, it would be easier to say why that is if you clarify which ter code you're seeing.
  4. If you're looking for a more robust commercial solution, I hear that Bitpay also supports XRP.
  5. Yes, ripple-lib added support for X-addresses in v1.4.0 and has improved support (bug fixes, etc.) in several releases since then. At this time, X-addresses are not directly supported in rippled or at the protocol level.
  6. I used to do a fair bit of testing on Mainnet, so here are some of those: AccountSet with Domain and MessageKey: https://livenet.xrpl.org/transactions/439E2E369C81A6F21E9EA2C7CA3094E74A792B1D1CE7EEA58A52FEFF7A1626CB SetRegularKey with RegularKey: https://livenet.xrpl.org/transactions/6AA6F6EAAAB56E65F7F738A9A2A8A7525439D65BA990E9BA08F6F4B1C2D349B4 EscrowCreate with Condition: https://livenet.xrpl.org/transactions/529C16436FFF89C1989A8D7B5182278BC6D8E5C93F4D0D052F9E39E27A222BB1 EscrowCreate with Condition & CancelAfter: https://livenet.xrpl.org/transactions/C44F2EB84196B9AD820313DBEBA6316A15C9A2D35787579ED172B87A30131DA7
  7. One suggestion: first, upgrade to ripple-lib 1.7.0, then change this line: api.submit(sgnd).then( response => { to use failHard: api.submit(sgnd, true).then( response => { That way if account deletion doesn't work you don't lose 5 XRP for trying.
  8. BTW, I strongly recommend submitting your AccountDelete transactions with the fail_hard option set to true. If for some reason the transaction can't be applied (like, you actually do have some object preventing your account from being deleted) then you'd really, really much rather have it be as if the transaction was never sent, than to send the transaction and destroy 5 XRP only to have it fail to delete the account.
  9. Hm, very odd. Those specs sound like they should be sufficient, but obviously something is wrong for it to be falling out of sync that often. Unfortunately I don't know where to look next.
  10. I'm with @JoelKatz on this topic:
  11. Not sure what hash you're looking for, but here's an AccountDelete on XRPCharts: https://xrpcharts.ripple.com/#/transactions/2BCD5B4C9CB7DC65C4C620F2767104CF3F35F805B189A414C1E02479788B7FDA Same one on the XRPL Explorer:https://livenet.xrpl.org/transactions/2BCD5B4C9CB7DC65C4C620F2767104CF3F35F805B189A414C1E02479788B7FDA/detailed
  12. Yikes, that is a lot of transitions in/out of the full state—an average of once every ~53 seconds! Sounds to me like your hardware (or network?) might not be able to keep up with the ledger. Would be nice to know what kind of disks, RAM, and network connection the server is on—gotta get more datapoints on what's sufficient and what's not. Also, what [node_size] setting do you have in the config file? Also, are you using this machine for a bunch of other stuff, or is it dedicated hardware?
  13. 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!
  14. 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.
  15. 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.
  16. 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!
  17. 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%.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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' // }
  24. 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.
  25. 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!
  • Create New...