Jump to content


Platinum Member
  • Content Count

  • Joined


About Sukrim

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You were running VPN software on Codius? How?!
  2. There is no hint about online_delete in the post, it is not vmware, and since 10 peers are connected it is unlikely that it is a firewall issue.
  3. There is a timestamp, however it seems that the partial validations contained the then-current timestamp and there was no real way (or benefit) to rewrite all ledger headers after validations were no longer partial. Remember that ledger header hashes are also part of the ledger itself and they in turn can influence the ordering (and thus outcome) of transactions.
  4. What about https://github.com/ripple/rippled-specs/ if we're on the topic of private information about XRPL?
  5. Not really, especially since validations and consensus related messages are ephemeral and not logged or collected anywhere. It also isn't easy to do for someone who might want to start such an archive. Some indications might be transaction volume going down (since also a lot of nodes were not really working well during that time), but in general just by looking at ledger headers there's no way someone can find out after the fact that for some time some ledgers were only partially validated. Maybe this is different in newer versions of rippled though.
  6. TrustSet is the transaction type that creates/modifies Trust Lines.
  7. If you do not have the skills to administrate a server securely, I don't see why your validations should be trusted by others...?
  8. Switching off their validators unannounced would make the ledger more vulnerable if a few more validators fail if they keep announcing their current recommended UNL. If they don't announce further updated UNLs, the network would likely grind to a halt once the current recommended list runs out and people don't quickly reconfigure their validators.
  9. Prove it. Your tests just shows that it is NOT latency, but the fact that timestamps are not exact, especially since ledgers seem to arrive about 3-4 seconds apart which is the expected behavior and likely the actual close time.
  10. Ledgers get batched together often when there's too much disagreement between validators and timestamps in that case get just incremented instead of re-negotiated (that's the case if a ledger is closed in just a single second, which shouldn't really be possible). I still don't see the issue with that system though, if you want to measure latency of the ledger, I'd first recommend you to run your own node locally to at least remove that hop from the equation.
  11. Not really efficient, no. You can look up all transactions of all wallets involved and then see if you can find interactions between them. There's no API or service that I know of that will automatically do this for you. Maybe with Wietse's BigTable transaction dump there might be a chance to write this in SQL?
  12. Usually keys for various accounts are derived from that encoded secret, it isn't used directly. Did you already read https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki for example? I would guess that this is how Ledger does it, but you can read their source code for the exact process too.
  13. Yep, that's the global overlap requirement mentioned in the Consensus Whitepaper.
  14. It always refers to your own UNL. If you (and 80% of your UNL) have activated that amendment and someone else hasn't, you're no longer going to run on the same chain. Either your UNLs are so different, that there will just be a fork or one of them (your or the other one) will just stop working until there's some manual intervention, depending on how each server's UNLs look like.
  15. If you mean Ripple's corporate interbank transfer network: Most likely no. If you mean XRPL: Yes, see the answers above.
  • 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.