jn_r

I kinda agree with what you are saying, but on the other hand, I find xrpcharts very insightful and useful. I haven't seen all functionality yet in other currently available tools. One page in particular would be interesting, namely the https://xrpcharts.ripple.com/#/validators page. https://data.ripple.com is sort of the backend from xrpcharts and contains some knowledge that only the company Ripple can know. In particular the knowledge of which domain belongs to which validator is only available at data.ripple.com. Coupling a validator pubkey to domain name is sort of one of Ripples prerequisites for becoming a validator on their UNL. But as matter of fact, https://github.com/ripple/rippled/pull/2836 will make this information available in other ways. I think the other information is already attainable via other means than data.ripple.com. Because Ripple is the creator and maintainer of the currently most important UNL, I do think they should keep on publishing the info for their UNL as good and transparant as they can. The other info on xrpcharts.ripple.com should ideally be available in other tools.

Thanks. There is an error on that page btw. Ethereum is not UTXO based but Account/Balance based

If only he would not have that one prediction with an amount in it. Would he then not be a harmless fun jester?

Might be interesting to know the estimated time it took to generate those 32570 ledgers. With an average time of 6 seconds per ledger that would be ~2,5 days

There are slight differences between the first implementations of ILP and the current one. I found the following link describe it pretty well: https://interledger.org/rfcs/0027-interledger-protocol-4/#differences-from-previous-versions-of-ilp Here a picture of the overall layered architecture:

You are missing the market maker in this story. The thing is, with ILP, no money leaves any ledger. On ledger A the money is transfered from BankA/customerA to the market maker (Also on BankA ledger), on ledger B the money is transfered from market maker (on BankB ledger) to bankB/CustomerB. Because no money is leaving any ledger (it is a local payment from customer to mm and vice versa) it does not need to be settled with the CB Edit: market maker should be 'connector'

Does in your view the bank or corp have an account with the exchange, or does the exchange has an account with the bank? Imo the corporation or bank should have an account at the exchange. I agree with the place of the credit creation, but I would like to see the collateral somehow in the balance-sheets. I have to go for dinner now, but I'll crack my head later on. Thanks for the feedback!

Needs some time to sink in. I am not so used with balance-sheets, would collaterals also show up on balance-sheet? I also saw your other post now with sort of same thoughts on xPool, so it seems I have some catching up to do in reading.

Yeah that's the part where I got stuck, who and at which moment owns the USD and who is the XRP credited. Technically it would always be the exchange as XRP-counterpary because the exchange is the only one dealing with 'real' XRP. So the exchange in his turn should fix his own balances for bank and MM somehow such that it reflects the correct amounts for the of XRP and EUR (on the exchange-ledger they both are IOU's)

I was also bit of reacting to Wandering_Dog If the collateral with cash balance takes place on the exchange-ledger (assuming it is a regulated exchange following the 'rules') then an XRP loan should be possible. If keys are lost, exchange goes broke, etc. then then the normal rules apply and the usd-collateral can be 'fixed' according to the current law The following doesn't quite work out as I hoped, so probably not correct, but allaz, as I pictured it (with or without payment channels) - an xRapid payment BankA [usd] -> BankB [eur], the exchange rates are known already..then, BankA deposits 100 usd to MM on exchangeA MM requests 312xrp loan from [XRPcreditor], collaterals 100usd to [XRPcreditor] on ledger-exchangeA MM offers 312xrp for 100usd BankA takes offer, sends 312xrp to exchangeB -- 100usd is now still in collateral, maybe a simple deposit to [XRPcreditor] on the exchangeA.. BankB receives 312xrp on ledger-exchangeB BankB exchanges with MM 312xrp for 87eur, withdraws 87eur to recipient MM pays back 312xrp loan to [XRPcreditor], collateral of 100usd freed. The XRP loans should go to the market makers so they can create liquidity in the orderbooks. If the MM on exchangeA is the same MM as on exchangeB, then they can settle the XRP between themselves afterwards. Note that the [XRPCreditor] counterparty is the exchange, not the MM or the Bank.

some XRP connectors listed here: https://github.com/interledgerjs/moneyd-uplink-xrp/blob/master/connector_list.json

Could the borrowed XRP amount not be collaterized with the equal amount in e.g. USD? This seems to work especially well in the xRapid case, i.e. Bank sends USD to exchange, the exchange collaterizes the USD (with the XRP owner) for the XRP loan.. exchange receives XRP and sends it to exchange B.

Here are some thoughts / 2 cts: A connector serves its clients (which can be original ILP senders or other ILP connectors) by accepting their payment and forward the payment (route) to the next connector. All the clients have a relationship with the connector, i.e. an 'account'. If for example the relationship is based on an XRP payment channel, then the account can be pseudonymous, but at least it is known and kept for as long as the relationship lasts. The accounts can also be implemented in other ways, e.g. as some sort of debit/credit system. ILP example flow: Coil browser -> Coil connector -> Strata connector -> xrptipbot 'moneyd' connector -> xrptipbot-ledger account (payment pointer) The Coil connection from your browser to a coil ILP connector is not based on XRP payment channel, but on the credit you have at the connector - as you are a known client from Coil (with 5$ monthly subscription). The next ILP hops in a coil payment are from Coil to Strata and from Strata to xrptipbot, his 'moneyd' node. Both hops based on XRP payment channels Then a final ILP delivery (not XRP payment channel) is made to your account at xrptipbot-ledger. (you receive an IOU, not XRP .. you can withdraw to XRPledger if you want) I am imagining the process of accepting/validating one or more XRP payment channel packages to be called the 'clearing/netting' of that particular payment and when you want to make it definitive in the payment-channel or on-ledger, you 'settle'. The clearing/settlement for the payment from coil-browser to coil-ILP-connector is very different. As is the clearing/settlement from xrptipbot moneyd to your xrptipbot-ledger-account. Maybe interesting to read more on XRP payment channel setup and so called 'mini-accounts' here: https://github.com/interledgerjs/ilp-plugin-xrp-asym-server The connection between ILP client and ILP connector. The client communicates the intended ILP package (the 'prepare') to connector and waits for the 'fullfill' answer. If received, then the payment is processed (clearing/settlement) and at his turn the client sends the 'fullfill' back to its own client (if any), etc. This repeated for many micro-payment packages. In a websocket connection, the connection is kept alive for processing multiple messages The point being made is that keeping every connection alive (stateful) for its duration in a bi-directional websocket is apparently a more heavy load than compared to an architecture using stateless http sessions: stateless sessions can be scaled horizontally with existing (cloud) techniques. The ILP communication without the 'non ILP'-clearing/settlement can be done stateless; clearing and settlement (everything that is not ILP) can be done separate and maybe at more convenient intervals. Passing the clearing/settlement to a separate engine, the managing of account balances to a database system, the whole process would become more lean and scalable.

to get started https://interledger.org/ - do the 'Try it out' and read through the specs and for the code https://github.com/interledgerjs an ILP connector receives an incoming payment package. He will try to deliver it to its destination by sending a new package to the next hop. How much and in which currency they send the next package is up to the connector. So, they can hold a little-bit for themselves if it is the same asset/currency, or keep a little margin on the trade-price if the payment switches to another asset/currency. The payment packages are tiny micro-payments. Sender/receiver decide on basis of some test payments and the ratio of sent/delivered amount if they continue the stream

Thanks @mDuo13, well explained. Triggered by @Sukrim I created a little script that checks if RFC6979 is used on a transaction by replaying an old transaction with the newest ripple-lib (which uses RFC6979). If the old transaction uses RFC6979, then the resulting hash will be the same. I think it works pretty ok, but no guarantees that it works 100% . I checked some of my accounts and indeed most of them make the cut somewhere at August 2015, depends of course which client was used and when that client was updated to use a newer version. For those interested, here is the script (careful with those secrets, clear your shell history afterwards): const { RippleAPI } = require('ripple-lib'); const txHash = process.argv[2]; const secret = process.argv[3]; const rippledService = 'wss://s2.ripple.com'; const api = new RippleAPI({ server: rippledService }); (async () => { await api.connect(); const transaction = await api.getTransaction(txHash, {includeRawTransaction: true}); const rawTx = JSON.parse(transaction.rawTransaction); delete rawTx.meta; delete rawTx.TxnSignature; delete rawTx.date; delete rawTx.hash; delete rawTx.inledger; delete rawTx.ledger_index; delete rawTx.validate; const signed = await api.sign(JSON.stringify(rawTx), secret); console.log(JSON.stringify(transaction.specification, null, 2)); console.log("New txHash:", signed.id); console.log("Old txHash:", txHash); api.disconnect(); process.exit(0); })().catch(err => { console.error(err); })