Jump to content

alloyxrp

Member
  • Content Count

    301
  • Joined

  • Last visited

1 Follower

About alloyxrp

  • Rank
    Regular

Contact Methods

  • Website URL
    https://www.alloy.ee/xrp-validator/

Recent Profile Visitors

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

  1. If you want the stats from an arbitrary list of validators, then as @Sukrim says, you should write your own routines. However, if you want to get stats from validators on your UNL and other validators connected to your rippled instance, you could subscribe to the validation stream on your server. And store/analyse that data, beginning at the time when you subscribe to the stream. You will then be able to get the info for arbitrary time periods. https://developers.ripple.com/subscribe.html#validations-stream
  2. This looks like your rippled has got a SIGINT from somewhere, most likely the kernel. Could be disk space or open files limit. Do you have this in /etc/systemd/system/rippled.service.d ? [Service] LimitNOFILE=65536 And to ask you a very silly question, are you sure we're looking the correct config file (/home/caroma/.config/ripple/rippled.cfg), and not the file in /opt/ripple/etc/rippled.cfg ? Also, which rippled.cfg is your systemd init file referring to (/usr/lib/systemd/system/rippled.service) ?
  3. 1) Happily, this is the reason why most of us run validators. A belief that this will contribute to growth of the XRP ecosystem. And yes, many of the other points made in this thread. 2) It's perfectly possible to run a validator on a Virtual Machine (like Matt said, and Wietse's excellent tutorial explains how) , but I think most of the recommended UNL run dedicated servers. I certainly do, for both my validator as well as the zaphod.alloy.ee (no that link won't lead you anywhere) public hub pool. 3) Why community run public hubs? I feel it's an important part of the overall decentralization process. New nodes can discover the network, without the involvement of Ripple's own bootstrap servers. This was implemented as of 1.2.0 and here's the commit for that : https://github.com/ripple/rippled/pull/2807/commits/8b9e95405d31272c804261ca4f3bc63997b66bb4 .
  4. Resource usage is very low even when running a public node (>100 peers). Disk I/O and bandwidth increases somewhat proportionately. If you are running in a virtual environment, there are two things to look into: 1) What the resource utilization on the physical host is, especially w.r.t. iowait times 2) The eagerness of the host machine to move guest memory into swap. These things, however, can only be monitored and adjusted if the underlying physical hardware is also under your control.
  5. @Hodor : Many thanks for the kind words on your blog post. Humbled, yet inspired to continue, in whatever small way possible, in inevitable change. I won't quote Dylan here!
  6. That's only if you run a full history server. Very, very few nodes do that. The default for the rippled config is 2K ledgers I think. Which is a few gigabytes. That being said, your point is valid about not all being there to stay. But hopefully the additions will outweigh the drop offs.
  7. Hi all, In the interest of full disclosure to everyone here, I'm coming out . I'm one of the new validators on the UNL - alloy.ee . That makes at least 2 or 3 xrpchat members on the list. More power to us!
  8. Good points, and worth understanding in depth. However, Weitse does say that they store the source IBAN, phone number and destination XRP address for a period of 5 years, and since IBAN and phone number are used for verification, some parts of the KYC/AML at least are being taken care of.
  9. In many other EU countries, banks normally issue our debit (bank) cards as MC/VISA, not Maestro. And even the Maestro cards don't have the IBAN. None of this, however, takes away from the awesome work that Weitse is doing.
  10. Maestro has it. Not all MC and VISA debit and credit cards, if any.
  11. Forking the code base to start an entirely new DA is one thing, but forking XRP, as you said, would basically be poisoning the validators. And apart from causing network disruptions and confusion in the speculative market, the use case for the standard XRP version would remain unchanged, as would xRapid. There is another thread about Byzantine nodes here.
  12. If I understand Theorem 8 correctly, 90% consensus is required for network safety? I must admit I did a very brief scan, so apologies in advance. XRP LCP guarantees fork safety if Oi,j > nj/2 +ni −qi +ti,j for every pair of nodes Pi ,Pj . Note that although proposition 7 is an iff statement, the overlap condition in theorem 8 is only sufficient but not necessary for XRP LCP safety. This is because lemma 6 is not an iff statement. Further, there may be some validation configurations that cannot come out of deliberation, breaking our broad assumption that anything can come out of deliberation. However, it is the weakest condition that can be expressed purely as a bound on the size of overlaps. Once again assuming 80% quorums and 20% faults, the overlap condition in theorem 8 can be summarized as requiring roughly > 90% UNL overlaps. Although quite a narrow margin (and certainly far more narrow than originally expected), this does still allow a small amount of variation, which is very important for the XRP Ledger network’s transition to a recommended UNL comprised of independent entities. Having some flexibility in the UNLs is important both for after the diversification of trusted operators (as one can never guarantee total agreement on participants when the participants are independent entities) and also during the diversification process (if tiny disagreements during changes to the UNL list could cause a fork, then diversification would always be too risky to execute).
  13. From https://ripple.com/files/ripple_consensus_whitepaper.pdf In order to achieve correctness, given a maximal amount of Byzantine failures, it must be shown that it is impossible for a fraudulent transaction to be confirmed during consensus, unless the number of faulty nodes exceeds that tolerance. The proof of the correctness of the RPCA then follows directly: since a transaction is only approved if 80% of the UNL of a server agrees with it, as long as 80% of the UNL is honest, no fraudulent transactions will be approved. Thus for a UNL of n nodes in the network, the consensus protocol will maintain correctness so long as: f ≤ (n−1)/5 (1) where f is the number Byzantine failures. In fact, even in the face of (n−1)/5+1 Byzantine failures, correctness is still technically maintained. The consensus process will fail, but it will still not be possible to confirm a fraudulent transaction. Indeed it would take (4n+1)/5 Byzantine failures for an incorrect transaction to be confirmed. We call this second bound the bound for weak correctness, and the former the bound for strong correctness.
×
×
  • Create New...