Jump to content

mDuo13

Ripple Employee
  • Content Count

    527
  • 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. 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 "*"
  2. 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.
  3. If you're looking for a more robust commercial solution, I hear that Bitpay also supports XRP.
  4. 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.
  5. 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
  6. 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.
  7. 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.
  8. 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.
  9. I'm with @JoelKatz on this topic:
  10. 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
  11. 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?
  12. 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!
  13. 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.
  14. 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.
  15. 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!
×
×
  • Create New...