XRP Ninja

GCE provides various kinds of metrics from which one can create dashboard, alerting policies etc. However, there is no way to monitor performance of rippled unless we wrote something ourselves. Fortunately, GCE allows creating custom metrics. So as a starting point, I decided to create a metric for rippled build_version. This information is very useful. For example, you will be able to tell if the behavior of the server changes after version changes. However, I later learned that custom metric can't have "STRING" as its value type. So I created an uptime metric with build version as its label. It works just the same. Here is a screenshot of the chart created from this metric: Unfortunately, it seems I can't share this chart publicly, unlike charts created from built-in metrics which can be shared publicly.

I have been wondering about this lately. Then I found this article: http://eliasbizannes.com/blog/2017/10/why-bitcoin-or-another-deflationary-currency-will-lead-to-an-economic-revolution/ TL;DR: as long as investment has higher return then hoarding the deflationary currency, people will invest instead of hoarding. Similarly, if market maker can make more than hoarding XRP, market maker will make market instead of hoarding.

Maybe this is obvious all along to some people. Anyway, I just figured this out. So I thought maybe it's worth sharing. Previously I thought the bridging consists of two transactions, both on XRP ledger. One from fiat currency A IOU to XRP, the other from XRP to fiat currency B IOU. Then I saw this: https://www.xrpchat.com/topic/10981-xrapid-uses-crypto-exchanges-to-route-payments-in-real-time/ So Miguel Vias said in the pilot they used liquidity on bitstamp and bitso. However it's seems the trading volume of XRP/bitso.MXN since the beginning of 2017 is so low that it's virtually no liquidity there. See this: https://xrpcharts.ripple.com/#/markets/XRP/MXN:rG6FZ31hDHN1K5Dkbma3PSB5uVCuVVRzfn?interval=1d&range=1y&type=candlestick Then I realized, just like bitstamp, bitso has its own exchange and the liquidity there is much better. https://bitso.com/trade/market/xrp/mxn So now it's clear to me there is another way for XRP to bridge cross-border paym

An article about ILP posted on American Express's website. It could mean nothing. But I won't be surprised if AE turned out to be using ILP for real since there's already rumor about it. https://www.americanexpress.com/us/content/foreign-exchange/articles/international-payments-hyperledger-interledger/ everis (NTT Data) confirm their adoption of ILP as the Hyperledger Quilt Project http://insights.everis.co.uk/post/102eihg/everis-ntt-data-confirm-their-adoption-of-ilp-as-the-hyperledger-quilt-project These news prove that Ripple's collaboration with Hyperledger to produce the Java implementation of ILP (Hyperledger Quilt Project) is a very brilliant move. So what does that mean for XRP? If you are a long time XRP hodler, you probably have already known this. But if you don't: The more ledgers ILP connects, the more payment volume XRP will be able to bridge. See also  this .

https://ripple.com/insights/q3-2017-xrp-markets-report/ The release caused the price to shot up vertically. Although it fell back a little shortly after. The highlights of the report in my opinion are: 23 percent Q-o-Q volume increase More  xRapid partnerships to be announced in Q4

I have created ripple.txt for my validator, following this instruction: https://wiki.ripple.com/Ripple.txt . Here is the link to my ripple.txt https://xrp.ninja/ripple.txt Here is my validator: https://xrpcharts.ripple.com/#/validators/nHBTqw7vwjqrSMruoQNYmSXcrBmQHDquG7jgvrsQpurGaVELqdNx I am going to have ripple employee change the validated domain name from rippled.xrp.ninja to just xrp.ninja. The ripple.txt file can be validated here:  https://ripple.com/build/ripple-txt-validator/

https://www.xrpchat.com/topic/7229-a-question-about-validators/?do=findComment&comment=69555 There are several degrees of damage, that trusted validators can do (if they decide to give up their hard-earned trust), in increasing difficulty order: If a set of them, each of which only trust others in the same set, with less than 20% of them trust validators not in that set, decide to collude, they can create fork. If more than 20% of them decide to collude, they can prevent transactions from being validated. If more than 80% of them decide to collude, they can rewrite history as they wish.  However, as pointed out by mDuo13@, creating a fork is easy, but making people accept it is hard.