Jump to content

jn_r

Member
  • Content Count

    589
  • 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'm curious to know their exact solution. Apparently they do something with MPC (Multi Parti Computation) where parts of the biometrics are stored encrypted over different nodes. By means of MPC the match can be proven without any node sharing its part, but only the computation on that part. So that is all nice, but still, the weak point IMO is the point where the biometrics is measured. Take e.g. a fingerprint, that is very hard to keep secret. You leave it literally everywhere behind. So it is really important to know how the liveness of the measured biometric can be assured ed. I found the paper :-) I'll give it a read
  2. I have a bit of an issue with using biometrics for creating secrets. IMHO a biometric is per definition not secret and therefor cannot lead to a secret. You offer your biometric to a terminal to measure it and the terminal will compare with a biometric template which is bound to your identity. Meaning the terminal already has all the data it needs to reproduce that same biometric. And if one terminal can measure it, any terminal can measure it, so if my biometric produces a secret, any terminal can now also produce the secret. To cut short, biometrics are good for identification, but not for authentication. So why does it work on your mobile (fingerprint or facial recognition). In basics it still is used as identification, but the extra security what makes up for the authentication is the measurement of 'liveness' of the scanned biometric, and in that there is also no secret involved. You trust you own mobile device (something you have) and therefor trust its 'liveness' features and therefor to hold some or determine some of your value. But you cannot trust an unknown remote terminal.
  3. I saw this talk at devcon5 (Ethereum conference) about debt-forgiveness and kinda reminded me of the @Wandering_Dog discussions. Below is a short summary And here the presentation if you have 20 minutes to spare: https://slideslive.com/38920105/money-and-debt-and-digital-contracts
  4. Wow, you digged up a really old post Well, Craig Wright is still controversial. At least we could say he lied in the video when he said he would never ever appear again on TV or other media..Turns out the guy is a narcist Here is (one of) his internet pages: https://craigwright.net/
  5. So I thought why not try to decode this mystical manifest from the unl and finally, succes at last The code below contains a function that will translate the manifest and the ephemeral public key: const binaryCodec = require('ripple-binary-codec') const addressCodec = require('ripple-address-codec') const request = require('request-promise') const validatorListUrl = process.argv[2] || 'https://vl.ripple.com' console.log(`UNL at ${validatorListUrl}:\n`) function getEphemeralPublicKey (manifest) { const buf = Buffer.from(manifest, 'base64').toString('hex').toUpperCase() const hexPubKey = binaryCodec.decode(buf).SigningPubKey return addressCodec.encodeNodePublic(Buffer.from(hexPubKey, 'hex')) } ;(async () => { const encodedData = await request.get({ url: validatorListUrl, json: true }) const buff = Buffer.from(encodedData.blob, 'base64') const unlList = JSON.parse(buff.toString('ascii')).validators const validators = (await request.get({ url: `https://data.ripple.com/v2/network/validators`, json: true })).validators for (let nr in unlList) { const pubKey = addressCodec.encodeNodePublic(Buffer.from(unlList[nr].validation_public_key, 'hex')) const ephemeralPublicKey = getEphemeralPublicKey(unlList[nr].manifest) const validator = validators.find(validator => validator.validation_public_key === pubKey) console.log(`${('0' + ++nr).slice(-2)} - ${pubKey} => ${ephemeralPublicKey} => ${validator ? validator.domain : '-'}`) } console.log('') })().catch(err => { console.error(err.message) })
  6. I think turning on rippling would not be smart. Imagine I create a USD stable-coin and set as operator the price at 1/10th of the normal price. I will then also issue/collaterize on my self operated stable-coin and receive 10x as many USD as I should have received. I will then 'ripple' to other - more fair priced USD and then exchange these USD back for XRP. I will receive ten times the amount I collaterated. (And just leave the collaterated XRP)
  7. I would love to trust them again and run bots on their orderbooks, but I have stopped since the hack. Sadly I can not trust their IOU's until victims of the hack have been compensated.
  8. Government intervention seems to be always in favor of the risk takers: Is it not the bad-banks that are bailed out by government, then it is those that spend more than they can afford (inflation making debts less). It seems to be a system where taking irresponsible risk is rewarded. I think it is this aspect why many crypto-lovers find the current government based fiat system unfair, and where native crypto would shine.
  9. Sorry for a bit off-topic question, but is amendement really the only way to have others accept breaking changes to the rules of updating the ledger? Just thinking of a scenario where the UNL owner (Ripple in the case of vl.ripple.com) is hacked and a new UNL is published with a bunch of malicious validators. Nearly all nodes will blindly take the new UNL for granted - at least for a short time - in which incorrect ledgers could be published. In that short time, I am not sure what will happen. Will the other nodes sort of 'stutter' but soon enough 'give up' and find agreement to use the new proposed ledgers from the malicious validators, or will they just not accept because the rules are not applied?
  10. or if 7 or more validators of the UNL at https://vl.ripple.com/ go offline simultaneously..(imo that would classify as an incident, not so much as an error)
  11. Any opinion available yet from a Ripple employee on the LibraBFT consensus protocol? https://developers.libra.org/docs/assets/papers/libra-consensus-state-machine-replication-in-the-libra-blockchain.pdf I am really curious what Ethan MacBrough and/or @JoelKatz think of it.
  12. That's the daily Jed sales. Every day, same time, same place
  13. 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.
  14. Bittrex will not delist XRP: https://bittrex.zendesk.com/hc/en-us/articles/360028996652
  15. 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 ..
×
×
  • Create New...