jn_r

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.

Bittrex will not delist XRP: https://bittrex.zendesk.com/hc/en-us/articles/360028996652

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 ..

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.

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..

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..

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

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

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..)

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'