Jump to content

jn_r

Member
  • Content Count

    568
  • Joined

  • Last visited

Everything posted by jn_r

  1. 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.
  2. Thanks. There is an error on that page btw. Ethereum is not UTXO based but Account/Balance based
  3. If only he would not have that one prediction with an amount in it. Would he then not be a harmless fun jester?
  4. 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
  5. 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:
  6. 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'
  7. 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!
  8. 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.
  9. 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)
  10. 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.
  11. some XRP connectors listed here: https://github.com/interledgerjs/moneyd-uplink-xrp/blob/master/connector_list.json
  12. 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.
  13. 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.
  14. 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
  15. 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); })
  16. The faq mentions this: So it would seem they are looking for ways to improve it. The problem is, how do you divide 5 USD over a monthly period such that you will not spend too much and not too less.
  17. I know this discussion has been before, let's not pick it up in this thread. happy to agree that we disagree for now :-)
  18. What I can see, you receive a JWT token with the following content: { "userId": "xxxxxxxxxxxxxxxx", "throughput": 100000, "currency": "USD", "scale": 9, "iat": 1547251202, "exp": 1548460802 } iat is issued time, exp is expiration time. When the token is expired a new request is done and coil can recalculate and maybe change the throughput. I am not sure what the frequency of the 0.0001 USD payment is, seems like +/- 30 seconds. You do not have control over this yourself, coil calculates all this for you.. I also see that a call is then made to the SPSP (simple payment service provider) https://twitter.xrptipbot.com/<name> in this case - and according to ILP protocol it returns - the -lowlevel- ILP account, which is hosted at strata. Now that this endpoint is known, a low-level BTP (Bilateral Transfer Protocol) message is sent to coil's ILP-endpoint to start the actual ILP-payment. this payment is then repeated every 30 seconds. hmm, hope I interpreted that correct and if at all understandable :-) I have some foreknowledge as I did some research on ILP previously. If you read through the ILP-github it is all there, it's just not that easy
  19. no problem @WrathofKahneman I don't know either what they exactly are and am curious/interested to find out more. - The assumption that they do not trust the real UNL I am not sure that is correct. Maybe some of them just can't keep up with the network, but on the other hand I think they would then not propose a new transaction set, so maybe your assumption is right. - If the forked network would choose to trust the real UNL at some point, then they should 1) forget about their current history and then 2) start again by receiving ledgers from the UNL validators.But I haven't tried this out yet myself, would love to hear from some ripple-representative.
  20. They would only process if they have reached their own quorum from their own UNL. Maybe they deliberately try to create a fork, have maybe 3 other validators in their UNL doing the same thing. They would send out the agreed upon transaction set over the rippled network, but as nobody is following them, it will just be in thin air
  21. only for twitch and youtube. If you want to see for yourself, open a chrome browser (and be coil-enabled), open the 'inspect' window (alt-cmd-i on a mac) and in there the tab 'network'. filter on 'coil'
  22. Ok, so I did some network-debugging on a youtube session and it is not option 3 but option 1: 1) The chrome-extension makes a call to an url-service from coil to receive the corresponding content creator's ILP-endpoint and then makes the ILP-payment They call an endpoint at the coil website where they request the corresponding ILP-payment-pointer that is linked to a certain youtube website. And then respond with the ILP-payment-pointer, which then can be used by the coil-extension. Must say, I am a bit disappointed by this, since they do this for every youtube call I make, which is a bit of a privacy thing. I'd rather have seen option 3 implemented.. Edit: I also did a network-debug session on a twitch session and there the same happens. First a call to coil to retrieve the ILP pointer. The difference is that now a payment-pointer at coil is provided ($spsp.coil.com/twitch/< twitch-account >) so it basically works as I previously described, the payment from browser to coil is ILP and then from coil to twitch I can't see, but it will be based on the twitch/bit system.
  23. I wouldn't say collaboration. I think if they use your google-account that it's just a generic property field (but I haven't found it yet) of your google-account that coil uses to place your ILP-paymentpointer in
  24. I don't know how twitch works. Do you receive twitch bits? The coil page mentions: In that case I think the connection from coil-extension to coil-ILP-provider is ILP, but coil will then be the endpoint and send the Twitch Bits (what a name) via their own system. But if you use youtube it is different, you actually receive the funds in you ILP payment pointer. I have tested that (connecting my sons google-account and watching his youtube channel) and I received some XRP in my xrp-payment-pointer.
  25. I disagree. Keeping history will allow verifying that the validators are not misbehaving. There was a tweet thread on this subject where Nik also joined in. Not sure where best to start that thread, but this is one of those tweets: Key in this is that you need a previous ledger (read - history) to be able to calculate the next ledger Edit: But besides that, I'm not sure the reason why they started the fork. Imo you should fork only if you disagree with the current status of a chain and can not come to consensus about the current way things are going. That would mean that they would have discussed their improvement points with Ripple and the community, and could not come to consensus, but I doubt that has happened
×
×
  • Create New...