Jump to content

mDuo13

Ripple Employee
  • Content Count

    548
  • 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. The only difference between "amending the protocol" and "forking the network" is how many people go along with you. If it's (basically) everyone, you've amended it. If some people don't like your changes and refuse to go along with them, you've forked. Therefore, we can see that the most important power in amending the protocol is the power of persuasion. In fact, this thread is a case of @shekenahglory exercising grassroots power in an attempt to amend the protocol. Personally, I don't feel persuaded yet. I think there's the kernel of a good idea here, in that it would be nice if XR
  2. The pathfinding in rippled is not guaranteed to find all possible paths, but it's not strictly length-limited. Rather, it has several "templates" for paths that it checks depending on what you're asking for, who's asking (i.e. server admins can make more expensive pathfinding requests than public API users), and how busy the server is. In the code the templates have funny abbreviations like "sxd" (source → xrp → destination), "safad" (source → rippling to another account → use an order book to convert to the final output currency → rippling to another account → destination) and so on.
  3. The consensus protocol is designed to work either way. I think in practice most of the transactions have made it around through the network by the time the first round of consensus starts for a given ledger index. True. Pretty much. This happens separately on each server, which may not always be seeing the exact same picture, so it's possible some server proposed a transaction in round 1 but drops that transaction for the server's round 2 proposal because from that server's perspective the tx didn't make the >50% percent threshold, but other servers saw or trusted a slightly
  4. No, the price of XRP is irrelevant to those calculations. In Q2 the company didn't buy any XRP. In Q3 the company bought over $45 million worth of XRP to offset additional XRP sold as part of On-Demand Liquidity Line of Credit. Q2: 32 million sold minus 0 bought = 32 million net sales. Q3: 81 million sold minus 45 million bought = ~36 million net sales. The full circle on ODL Line of Credit is something like this: RippleNet customer borrows XRP from Ripple on-demand. Customer sends the XRP through ODL, selling it for a destination currency based on where the payment is going.
  5. Definitely my experience with netsplits on IRC has been formative in how I think about these sorts of consensus challenges. Unfortunately for the younger generation of developers, the systems they grew up with are more robust which deprives them of this useful frame of reference!
  6. Negative UNL is an experimental feature currently in testing on Devnet based on one of David Schwartz's wild ideas for how to improve the XRP Ledger. The idea behind this feature is it adds an on-ledger list of trusted validators who are believed to be offline, and adjusts the validation requirements accordingly, within safety limits, so that the ledger can continue to make progress even if several trusted validators are temporarily down. Negative UNL is present in rippled v1.6.0 as a "pre-amendment" feature, meaning you can force it on for a particular server for testing purposes but you can'
  7. On the one hand, you're right. The XRP Ledger should not have that kind of delay to confirm transactions unless things are very wrong. On the other hand, that's a normal confirmation time for Bitcoin. And, it's kind of apples-and-oranges, but ACH's wait-until-after-the-weekend confirmation times are not even in the same fruit stand.
  8. The RippleAPI "Trustline" transaction is an alias in the JavaScript API for a TrustSet transaction on the protocol level.
  9. What, my beautiful face isn't in there?
  10. @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
  11. 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
  12. 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
  13. 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
  14. 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.
  15. 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
×
×
  • 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.