Jump to content

jn_r

Member
  • Content Count

    594
  • Joined

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. quantum resistant privacy preserving (Who owns what and who sends what to whom) high performance (> 10000 tx/s) tx finality in seconds fully decentralized And that is only the blockchain part. There is more, like anonymous voting, dApp (not delivered yet), Messaging (using the cMix platform). If it delivers what they promise then it might be a game changer as it delivers on all aspects that current blockchains in one way or another still miss..
  2. It's a really interesting blockchain / protocol. For those who want to learn more of it, check out these webinars: https://www.youtube.com/channel/UCmfUaqB2HQnEHU0o4Z7Es0Q And if you are thinking about investing in the ICO that is now live, check out: https://xx-coin.io/
  3. You can request the last sequence number from the rippled server you are connected with, but this number will only be updated every ledger (+/- 4 seconds). Therefor, what you should do is during a ledger interval increment the seqnum with 1 for every new transaction in that interval. And if you want to have this work over several instances and for the same address, than you should either a) have each instance request the seqnum from a central service and let each instance send the signed transaction to the rippled server, or b) have each instance send not-signed transactions to a central service where first the seqnum will be incremented, then the transaction signed and then sent to the rippled server In either case the rippled server will put the transactions in correct order and they should all succeed. When the new ledger arrives request again the current seqnum and start all over (or only do this if the seqnum is in error). In principle this works, but you have to take in to account that some transactions are queued and others might fail for whatever reason. the transactions in that ledger interval with a higher seqnum will then also fail.
  4. I would suggest: running nudb instead of rocksdb run the signing application on another system Because the signing application is no longer running on the rippled server, there is no need to encrypt the disk If the rippled server is only used for signing, you could opt for a smaller sized history edit: But do check https://xrpl.org/capacity-planning.html
  5. It is purely nodejs/javascript error (not ripple-lib related). When you use an 'await' you are only allowed to do that in an 'async' function. Which is logical, javascript wants to be strict here for a change: You can only (a)wait for a function to end or succeed if the overlying function itself is designed as asynchronous. And that implies that also that function must be awaited by for proper results and be wrapped in an async function by itself, etc.etc. What you can do is wrap the try/catch block in a asynchronous main function and then call this function. like this: async function main() { try { tx = await api.getTransaction(txID, {minLedgerVersion: earliestLedgerVersion}) console.log("Transaction result:", tx.outcome.result) console.log("Balance changes:", JSON.stringify(tx.outcome.balanceChanges)) } catch(error) { console.log("Couldn't get transaction outcome:", error) } } main() // no need for await here, just call the async function I don't think your script will work after this, but at least will help you through this first error ;-) Happy coding
  6. 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
  7. 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.
  8. 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
  9. 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/
  10. 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) })
  11. 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)
  12. 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.
  13. 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.
  14. 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?
  15. 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)
×
×
  • Create New...