Jump to content

xrpscan

Member
  • Content Count

    33
  • Joined

  • Last visited

Everything posted by xrpscan

  1. Its a fair point that every car driver need not know about IC engines - but at the same time enough independent car mechanics must know about engines so one can get it fixed anywhere.
  2. @yxxyun has quite deep understanding of the XRPL. I wouldn't belittle their argument about downward sell pressure.
  3. Deleted accounts are now correctly highlighted instead of showing Account not found error. Searching for deleted accounts will also work properly. Let us know if notice any bugs: https://xrpscan.com/account/r93Fr5Cmf6KAho1GfF9mvNKV97tZsCFKcB
  4. Precisely what @yxxyun said. When the docs say the account is deleted from the ledger, it implies the current validated ledger. Every account's transactions are present in the full history server. There's a tiny difference though, all accounts activated after passing of the amendment will have their sequence number set to the ledger in which they were created (ex. https://xrpscan.com/account/rpgtBwm6FaSdj9YUCrGV81GgwANq7Hm3JV).
  5. It is possible to show historical transactions for a deleted account too. We're rewiring the xrpscan api to do this, as the assumptions we made about the accounts are no longer true due the amendment.
  6. There are 35 dUNL validators. One of them is using a more modern domain verification technique, but the data api does not support this method yet and reports 34 validators.
  7. The xrpl.org blog provides more background on why this amendment lost majority. Mainly due to the fact that this amendment introduces a backwards-incompatible change and about half the nodes in the network are still on 1.3.1, and therefore would get amendment blocked.
  8. They've taken this a level up. For 1 XRP they're able to send (1 / 0.000088 + 0.000012) 10,000 scammy payments, and possibly generating as many deposit notifications from exchanges, wallet and tracker apps et al.
  9. The validation message data is not on-ledger, is ephemeral and is transmitted as part of consensus metadata. Therefore, retrieving historical validation messages is a bit tricky. Additionally, validation messages contain only those amendments that a validator is voting for, guesstimating vetoed amendments in historical validation messages is even trickier. For these reasons we don't show voting/vetoing pattern for enabled amendments till we figure out how to backfill this data. Thank you very much! If you have any suggestions for improvement, we're all ears.
  10. Hi SquaryBone, there's been some reports of 404 errors in this release. We've identified the cause, but meanwhile would it be possible for you to hard-refresh the browser window and see if its fixed?
  11. I agree, the amendments could use a bit of context to make sense. We're exploring if its a good idea to write a short summary for each amendment or simply link to the specific amendment writeup. Thank you for your feedback!
  12. XRPL Amendments dashboard is now available: https://xrpscan.com/amendments With this release we aim to provide greater transparency on Amendment voting numbers, super-majority status and Vote/Veto pattern by dUNL validators. Amendment voting status displayed here is based on the validations received during the latest voting round, as reported by our node. Feedback on what's broken, what can be improved is most welcome.
  13. Berkeley validator had an outage last week. Its back online now, but this could be the cause of the dangling validator key.
  14. Thanks for the mention @hallwaymonitor! Btw, we moved over from a flat file to an API over the last quarter: https://api.xrpscan.com/api/v1/names/well-known
  15. Unique index on transaction hash indeed turned out to be an incorrect assumption. It doesn't seem like there's a way for us to query rippled for a tx hash and process it as multiple transactions since the response is a single object and not an array. Response from data.ripple.com too seems to assume that there's only one transaction with same hash possible, and shows only the latest included transaction from ledger #3721729: 1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B Furthermore, this SetFee transaction seems to be missing from the full history server: websocket-tool
  16. They're planning to continue running both services: https://twitter.com/warpaul/status/1146675698024603648
  17. That's a fair point, and I agree that better wording could be used here.
  18. All I could find is this article: https://www.blocktempo.com/taiwan-exchange-bitopro-got-hacked-xrp-lost/
  19. Looking at the transaction pattern, here's my take: The attacker at rERfHy4YmDbKxsuFmzPBhMQCGyFrAGvbra has a small USD balance at gatehub that they use to probe exchanges. I scrolled till page 4 and almost every popular exchange that has XRP listed has been probed. The list even includes XRP Tip Bot! As a corollary, I believe the unlabelled destination addresses may be unknown exchanges. The pattern seems to be first a test amount (7K XRP) and if it works, a large transfer (of 3M XRP, to be withdrawn/traded until the exchange wallet runs dry). BitoPro's case looks to be a bit curiou
  20. It looks like a partially fulfilled offer from Gatehub for 0.001 USD. Sorry, this doesn't seem intuitive - we'll try and see if we can add more details to offer fulfilment transactions.
  21. As per those who're familiar with Coinbase's listing pattern, a Coinbase Pro listing is usually followed by Coinbase listing after a few weeks.
  22. In case someone wants to look up, their deposit account is here: https://xrpscan.com/account/rw2ciyaNshpHe7bCHo4bRWq6pqqynnWKQg
  23. Thank you for the vote of confidence CB. This means a lot, coming from folks who've been around for a while. I would recuse myself from commenting on the topic due to conflict of interest, but I'll say this - Ripple's Data API has been a big help in keeping xrpscan.com operations sustainable. By consuming Data API's transactions and payments endpoints, we keep our storage costs low. There may be a point in future where we cache all ledgers and generate transaction listing locally, but for now considering our traffic and query pattern, we're happy with the architectural trade-offs we've ma
  24. (emphasis mine) Well said. People come from diverse backgrounds and everyone has a different taste and preference. Giving more choice to users benefits everyone in the ecosystem!
×
×
  • 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.