Jump to content


  • Content Count

  • Joined

Everything posted by jn_r

  1. I would call it liquidity? Imo it is a (bot) trader waiting for a good deal. He wants to get a good price, e.g. > 1% of the expected market price. So he moves his offer every time he sees the market price move. And if buyers take his offer he can sell again with a little profit.
  2. Bittrex will not delist XRP: https://bittrex.zendesk.com/hc/en-us/articles/360028996652
  3. Although I think for the average user a wallet with built-in regular key/disable functionality would be better solution, maybe some people will prefer code that they can build and run themselves from the command line. The risky thing with setting regular key is -if- you do it wrong and use the wrong secret / address, you will lock yourself out and lose all your funds. I wrote the following scripts with some extra checks to make sure the correct keys are used, which I am happy to share. It's only for those who are familiar with nodejs (also do not forget to install ripple-lib): Store your keys locally (normally you would keep your keys only in key-store! but for this purpose we need them on disk) in a file "keys.json": { "masterSecret": "ssgnh7PsELz3pyFcMibVfJkjReBYS", "masterAddress": "rMASiKzzomFAAMduMWDeURtrDRTGjwoYYq", "regularSecret": "spmvYBTAj8zgpwZCLPk1YuBoEdhyh", "regularAddress": "rrEGH2qXLH945HrLvrrDuoHpmy823yHj4" } First set the regular key to the master address with the following script (I named it "set-regular-key.js"): const { RippleAPI } = require('ripple-lib') //const rippledService = 'wss://s2.ripple.com' const rippledService = 'wss://s.altnet.rippletest.net:51233' const keys = require(process.cwd() + '/keys') const api = new RippleAPI({ server: rippledService }) ;(async () => { await api.connect() console.log(`\nSetting regular key "${keys.regularAddress}" for account "${keys.masterAddress}"`) const keypair = api.deriveKeypair(keys.regularSecret) const regularAddress = api.deriveAddress(keypair.publicKey) if (regularAddress !== keys.regularAddress) { console.error('regularSecret does not match regularAddress!\n') process.exit(1) } const { txJSON } = await api.prepareSettings(keys.masterAddress, { regularKey: keys.regularAddress }, { fee: '0.000012' }) const { signedTransaction } = api.sign(txJSON, keys.masterSecret) const result = await api.submit(signedTransaction) console.log(`\n${result.resultCode}: ${result.resultMessage}\n` ) api.disconnect() process.exit(0) })().catch(err => { console.error(err) }) Now use the following script to either enable or disable the masterkey (I named it 'enable-master-key.js'): const { RippleAPI } = require('ripple-lib') //const rippledService = 'wss://s2.ripple.com' const rippledService = 'wss://s.altnet.rippletest.net:51233' const keys = require(process.cwd() + '/keys') const api = new RippleAPI({ server: rippledService }) ;(async () => { await api.connect() const settings = await api.getSettings(keys.masterAddress) console.log(`\n${settings.disableMasterKey ? 'En' : 'Dis'}abling master key for account "${keys.masterAddress}"\n`) const keypair = api.deriveKeypair(keys.regularSecret) const regularAddress = api.deriveAddress(keypair.publicKey) if (regularAddress !== settings.regularKey) { console.error('regularSecret does not match address from regularKey!\n') process.exit(1) } const { txJSON } = await api.prepareSettings(keys.masterAddress, { disableMasterKey: !settings.disableMasterKey }, { fee: '0.000012' }) const { signedTransaction } = api.sign(txJSON, settings.disableMasterKey ? keys.regularSecret : keys.masterSecret) const result = await api.submit(signedTransaction) console.log(`${result.resultCode}: ${result.resultMessage}\n` ) api.disconnect() process.exit(0) })().catch(err => { console.error(err) }) Having the keys in a file on disk and checked for the correct combinations of secrets/addresses will minimise the risk of making errors. Of course when you're done, make sure the keys are stored in a key-store and removed in the clear from disk. The above scripts are pointing to ripple test-net and with some test accounts. You can change it to use your own addresses and/or point it to the main-net. Use at own risk and please only use it if you know what you are doing ..
  4. You are probably referring to this: https://ripple.com/dev-blog/statement-on-the-biased-nonce-sense-paper/ I am wondering, from any of the victims ( to exclude this as the possible source of the hack ) if they either a) made 0 or max 1 transaction with the hacked account: In that case brute-force attack as described in the paper is not possible b) made transactions using Gatehub via a client device that would not be able to generate a 'good' random value (perhaps very old laptop, mobile, or something else). I think most newer devices create good random values and then the issue described in the paper would imo not be an issue.
  5. 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..
  6. 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..
  7. 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
  8. 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
  9. 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..)
  10. 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.
  11. Thanks. There is an error on that page btw. Ethereum is not UTXO based but Account/Balance based
  12. If only he would not have that one prediction with an amount in it. Would he then not be a harmless fun jester?
  13. 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
  14. 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:
  15. 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'
  16. 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!
  17. 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.
  18. 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)
  19. 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.
  20. some XRP connectors listed here: https://github.com/interledgerjs/moneyd-uplink-xrp/blob/master/connector_list.json
  21. 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.
  22. 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.
  23. 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
  24. 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); })
  25. 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.
  • Create New...