Jump to content

Sukrim

Platinum Member
  • Content Count

    1,991
  • Joined

Everything posted by Sukrim

  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.
  16. None that I know of, maybe putting https://xrpl.org/ in book format could earn you a few bucks?
  17. ...then you proceed by linking an article that explains that elliptic curves in the 2d plane are used for cryptography. Wut?!
  18. Here's a more radical idea: Ripple turns off vl.ripple.com for a month. What would happen?
  19. This is not what he said. Not every human and device has a Visa card either.
  20. It is the default, documented right at the start of the documentation about "how to accept XRP as an exchange" and also whenever Payments are mentioned usually. You need to look at "amount_received", not at "amount" (which is the maximum amount sent, not the actual amount). Exchanges need to correctly implement this though. It is definitely not clear if an exchange is vulnerable or not if you don't look at their internal code, so I'm not sure how the "we intercepted successful attacks" claim comes about. Maybe they also monitored the withdrawals?
  21. Why did you resurrect a thread that's nearly 2 years old at this point for this comment?
  22. This would be the easiest way to get started, not the end-all solution. With the library you're using (which is mostly a wrapper around RPC calls) that would have been the easiest way forward to start implementing your logic and then focusing on getting the lower level stuff right. Seems to have offline serialization (https://github.com/ulamlabs/aioxrpy/blob/master/aioxrpy/serializer.py) and signing (using https://github.com/warner/python-ecdsa). The warning there ("This library was not designed with security in mind.", "This library does not protect against side channel attacks.") mak
×
×
  • 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.