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. @BillyOckham's analysis is correct: 80%—the quorum requirement—is a threshold for consensus defined in the code. The developers chose the number 80% based on the best understanding of the nature of the problem and the overall algorithm's behavior in various theoretical and tested circumstances, and (I believe) because 80% is an easy number for humans to understand. The XRP Ledger's protocol is designed so that each server operator can choose their server's UNL based on their own ideas/rules/parameters. It was always known that servers that have very different lists from each other wo
  2. It does not. You can only safely conclude that a transaction has failed to achieve consensus if (a) it got a tem-class error¹, or (b) all of the following are true: The tx command fails to find the transaction The transaction has a LastLedgerSequence field There is a validated ledger with ledger index >= the LastLedgerSequence The server you queried has the entire ledger history from when the transaction was first submitted through the ledger whose index matches LastLedgerSequence See also: flowchart of reliable transaction submission. ¹Exception: te
  3. The close time on a ledger is approximate. This is so that individual servers don't have to have their clocks synced to the exact second. It is rounded to the close_time_resolution (10 seconds) and then incremented if it got rounded to the same close time as a previous ledger. The Ledger Header documentation covers this in a little more detail. (Note to self: link to that doc from the subscribe command and other relevant places.) If you notice, the end of the official "close time" tends to follow something of a pattern: ...10, ...11, ...12, ....20, ...21, ...30, ...31. That's the close ti
  4. There is a cache that is separate from the queue. Transactions get put in the queue when the open ledger is "full" (it's a soft limit, not a hard limit) if the transactions seem "likely to succeed". Transactions get put in the cache in a bunch of other cases and retried from there. For example, if a server sees transaction with sequence N+1, when the next sequence for the sender is N, it saves the N+1 transaction in the cache in case it receives seq. N right afterward. Each server kind of has to do that because when transactions get relayed through the network there's no telling what
  5. Just because the ODL transactions don't all look like they did before doesn't mean they aren't there. ODL is very much alive and growing.
  6. No. It probably won't give you the amount of control you want since other servers in the network may retry the transaction according to their own rules. And if you want to retry it more times, you can submit the same signed transaction as many times as you want if it's still valid. (As long as use the same sequence number it'll only get processed at most one time no matter how many times you resubmitted it.) That is one way. As I mentioned before, other ways to do this include account_tx, tx, or subscribe methods. Pick the one that works best for your needs. I don
  7. I don't know if the device could have possibly done this, but it might be something like: Test deriving multiple accounts from the master seed Look up the generated addresses to see if they exist in the public blockchain. If so: cool, must be yours Continue until you get a miss or something
  8. Short version, you don't need XRP for stablecoins etc. But it can help, or make things more convenient. For example, in the XRP Ledger's decentralized exchange, you can trade any issued currency for any other directly. But since anyone can make up their own issued currency, that's a very large number of potential currency pairs. Too many pairs/markets means shallow order books and higher prices (spreads) when trading. Autobridging (a feature introduced all the way back in 2014!) automatically connects more of these pairs by crossing through XRP where doing so is cheaper than trading them
  9. No, there is not really a way to configure this. You could change the rippled source code and recompile it, but I don't recommend it. Mostly, yes. As jargoman said, there is also the LastLedgerSequence parameter, which can help you know for sure that a transaction has failed if it hasn't succeeded by a certain point. Reliable Transaction Submission describes this in detail. In the case where the transaction eventually succeeds, then you need to wait for the network to validate the transaction. Aside from the tx command, you can also use the subscribe command to get a mess
  10. You can submit any number of transactions from the same address at the same time as long as you pay the open ledger cost to skip the queue for each new transaction. This cost depends on how busy the XRP Ledger is, but it increases very rapidly with each additional transaction you send. This is, of course, to prevent spammers from sending too many transactions at the same time and overloading the network. The cost is much less if you let the transactions wait in the queue. 1. There is no easy way to know how long it will take to process all queued transactions. This depends on the consensu
  11. It's slightly more complicated than this because your validators care about what their validators are doing. Each server decides individually whether to propose the pseudo-transaction to enable an amendment based on that server's own trusted validators. But whether that pseudo-transaction achieves enough support to become a validated part of the ledger history (from your server's perspective) depends on what your validators observe that their own trusted validators did. If not enough support an amendment, then they say, "Welp, nevermind. It didn't get enough support, so I can't enable it
  12. 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
  13. 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 "*"
  14. 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 alrea
  15. If you're looking for a more robust commercial solution, I hear that Bitpay also supports XRP.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.