Jump to content

mDuo13

Ripple Employee
  • Content Count

    558
  • 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. If you look at the account_tx (JSON-RPC/WebSocket) or getTransactions (ripple-lib aka RippleAPI) for the issuer's address, the results should include all transactions transferring the token from one address to another since those transactions ripple through the issuer.
  2. The response to the submit command includes information about whether the transaction was broadcast to the network. The details of that and a bunch of other stuff are on xrpl.org
  3. It's great that you've done this! I noticed a couple really minor inaccuracies—for example, the validators command is not exclusive to validators; you can run that on any server (as long as you're the server's admin) to get info about the validators it trusts. But overall, it's a nice walk through the steps to setting up a validator and it's great to have it all in a PDF form!
  4. I've opened a PR to add a note to that page about the same thing. https://github.com/ripple/xrpl-dev-portal/pull/989
  5. Not sure which explorers check for TOML-file account verification but that's also an option. (You set the Domain field of your account in the XRPL to a domain you own, then host a /.well-known/xrp-ledger.toml file with the account name at the domain and an optional description.)
  6. If you built it yourself from source it doesn't automatically set up the systemd unit files. You have to put those in the right place first and then do the systemctl commands as mentioned here
  7. The initial result from the submit command is preliminary. The transaction has to get propagated through the network to the validators to be incorporated in a validated ledger. (If the transaction has a LastLedgerSequence, then it has to make it before that ledger index gets validated. Otherwise it could potentially get validated at any time in the future as long as its Sequence number doesn't get used by another tx from the same sending address.) If you're getting a preliminary success but then the transaction doesn't make it into a validated ledger, then my best guess is that—at the time the
  8. I am seeing a large number of transitions recorded between the full, syncing, and tracking states, which confirms that your server has been temporarily losing sync with the network for some reason (though it's currently synced at the time of this server_info response). Based on the ledger index, it looks like you're on Testnet? BTW, re: the warning that protocol amendments it doesn't understand have reached supermajority—you can safely ignore that for now. A few new amendments have temporarily gained a majority there (because Ripple upgraded Testnet validators to 1.7.0-rc1) but that shoul
  9. As several other posters have stated, old accounts were "grandfathered" in; or, more accurately, it didn't bother to change stuff that was already recorded in the ledger. If your account was funded (received its first 20+ XRP payment) before deletable accounts went live, then its first sequence number was 1 (and still is, if it has never sent a transaction). If your account was funded after deletable accounts went live, its first sequence number was the ledger index at the time it was funded. And thereafter, no matter what, its sequence number went up by 1 each time you sent a transaction¹ and
  10. First off, if you want to create your own validator list site / publisher, be aware that doing so can create a situation where it is possible to unintentionally fork away from the main network. Your list must have >90% overlap with another person's list to completely eliminate the chances that you and that person end up following different chains. Second, the steps from many of your examples describe how to configure one validator, but then you're asking about setting up an entire list of validators. Keep in mind that one of the most important aspects of a validator list is that it has
  11. 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
  12. 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.
  13. 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
  14. 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.
  15. 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!
×
×
  • 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.