Jump to content

jn_r

Member
  • Content Count

    573
  • Joined

  • Last visited

4 Followers

About jn_r

  • Rank
    Advanced

Recent Profile Visitors

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

  1. I agree that there is no 'The UNL' and I didn't say you are obliged to follow the on-ledger UNL. The crux of the matter is, if you deviate enough, you will fork, and then you are on another ledger anyway. So why not publish on the ledger where you want to participate, the UNL that you want to intend to follow pardon my English, I meant trust of course ;-) Imo because the UNL is published on-ledger you don't need to trust the website where the UNL is published and you don't need to trust the publisher of the UNL (Ripple in this case). On the other hand you would need to trust the group of validators. The thought I had was that it would be published by amendment, but I see I made some false assumptions there. Amendments are software updates and not publishing on-ledger. Still the idea could be that validators vote by a similar process as the amendments on an UNL change. I agree that that process could indeed lead to spam..
  2. Here's a thought that just crossed my mind, I can't imagine it has not already been thought of, so there must be some hooks.. A minor observation that currently Ripple holds veto over amendments. Which can be changed over time (we're getting close to it actually), it would be quite a step, but to me it shows the amendment voting actually is a good process that allows democratic decision making between the current validators. Now the idea: What if we would publish the UNL (the public keys of the validators) on the ledger and that changes to the UNL can only be made through the amendment process? Wouldn't that make the XRP Ledger more decentralised and thrust-less? The power of changing the UNL is no longer with one party, but with the group of validators.. What are the arguments to not publish the UNL on-ledger? I can imagine if 's**t hits the fan' you want to be able to make changes fast, but every node still has the choice of not following the on-ledger UNL but follow a self-defined UNL, so calamities could still be handled off-ledger..
  3. Yes, I agree with that, if 'the network' decides that Ripple validators should be removed, it can be done. In that case we are no longer on the 'Ripple managed UNL', because the network decides to no longer follow their UNL. For that step to be done you would want to have all major network players (exchanges, gateways, market makers, FI's) with you.. Technically they would still have a veto-right in their own UNL sphere, but as the majority of the network is not following that anymore, it is of not much use
  4. I know it is possible to deviate from Ripple's UNL, but as I see it, you either stick with it for the greater part, or you don't. If you don't (with no overlap with the original UNL) you choose for a hard fork and start a new network with a UNL that is managed by another party. Small deviations are possible, but I would be careful not to deviate too much, or you will fork or halt. In my view Ripple - as manager of the current UNL we all use - is the guardian of what we now call the XRPLedger. The UNL is the central part of it and you can choose to follow that UNL or not. Within this sphere of the Ripple UNL decisions have to be made that require governance. Apparently one of the governance rules that currently apply is that Ripple has veto rights in the process of accepting amendments. The choice of keeping this rights might be a good one or it might not. I think at this stage the better choice is to still keep these rights at Ripple as I trust them in making the better decisions, but that might change if the validators become more mature in their decision making (- maybe I am underestimating the validator holders in that regard) N.B. with veto rights I mean one party that has the power to say 'no' such that it can not be overruled. I am not sure why the stanza is called 'veto_amendments' in the rippled.cfg. In my view there it means just a 'vote against' from that specific validator and not a 'veto'. Only Ripple can make the veto as they currently hold >20% of the validators
  5. 20% or more dominance in the UNL gives a party the veto right. Currently Ripple has a dominance of 25% Is Ripple planning to keep this right, or are they ok to also give this out of hand? (in which case you would e.g. no longer be able to block the checks amendment..)
  6. 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.
  7. Thanks. There is an error on that page btw. Ethereum is not UTXO based but Account/Balance based
  8. If only he would not have that one prediction with an amount in it. Would he then not be a harmless fun jester?
  9. 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
  10. 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:
  11. 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'
  12. 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!
  13. 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.
  14. 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)
  15. 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.
×
×
  • Create New...