Jump to content

jn_r

Member
  • Content Count

    609
  • Joined

Everything posted by jn_r

  1. A lot will have to happen before Europe has to lend the helping hand to USA with a reversed Marshall plan :-) But who knows. This time the frontline of the war (with Covid-19) and damage is everywhere, also in America. There are predictions that unemployment in USA could reach higher levels than those reached during the Great Depression...Not saying that Europe will do better.. Funny parallels with the rush on toilet paper, "like the households that grabbed all the toilet paper from store shelves, some institutions see the surge in demand as a reason to take more dollars than they now need." [https://www.cnbc.com/2020/03/19/a-global-rush-into-the-us-dollar-is-driving-extreme-market-moves-and-a-temporary-shortage.html]
  2. That feels like something I don't want (as a European). I can imagine there are countries that really don't like USA Fed as the world's central bank. But I am also wondering, what is the difference with what they already had, the Fed has always held accounts for banks and foreign Central Banks, correct? Couldn't it be that the system works both ways and is somehow much more a 'decentralized' network, where the current status quo is that the Fed and the USD are the most powerful and therefore appear on top of the pyramid. Like a bi-directional (but not acyclic) graph where you hold one node (the Fed/USD) up, i.e. still forming a pyramid, but temporary, not definite
  3. No it's not (yet). It's xx-coin from Elixxir (https://xx-coin.io/ / https://xx.network/), I personally think it's got some good potential. I also got some gold, for a longer time, since 2000 or something. But it was 'virtual' or 'Giraal' gold, existing only in my account at the bank. They had to stop this type of asset because it was no longer allowed by regulations. 1st April it will be definitely sold, so a week ago I bought some real physical gold (at https://www.amsterdamgold.com/). Seems I was just in time, as it is no longer possible. It's hard to purchase physical gold these days...
  4. That's like saying (as many on this forum can) "I have told you in 2014 to buy XRP when the price was $0.005. And now, for only $365,- I will tell you about the new coin I know of". But seriously, I do know of a coin which is (pre)valued at $0.35 (coincidence?) yet with a maximum number of coins of 1 bln. So that makes $350 mln, but who knows, maybe the newspaper made an error in their calculations. If you tell me the name of the newsletter, I will tell you the name of the coin
  5. I'm trying to understand how these swaps work. From the link above the following quotes: So do I understand correct that Fed lends money to other (central?) banks and in return receives collateral from the other central bank? Question then is, against what exchange price is this done (is this some sort of a OTC transaction?) and is the collateral 'printed money' or is it already existing money? Edit: I'm already gaining some more insight at the moment, we're talking collateral here, which rings some DeFi bells. So the collateral will stay at the US Central Bank until the debt is payed off. Then another question pops up, what happens when the collateral is no longer sufficient (i.e. dollar rises too much in value or counter-currency drops too much in value)..Can it be liquidated?
  6. I can't imagine people still want to hoard USD, while so incredibly much QE by the government(s) these days. I would say these are the last contractions of the USD as the world reserve currency, but that's probably overly dramatic and as usual will turn out to be not true
  7. A lot of stable coin initiatives are alive on the Ethereum network, lots of them use mechanics to facilitate borrowing, lending, exchanging using collateral techniques and generally are placed under the nomen 'DeFi' (somewhat 'the next big thing in crypto', currently sized at 1bln USD in crypto held in collateral). It will be interesting to see the effects of this one project on the XRPLedger, as the XRPLedger has good DEX capabilities (speed, orderbooks, autobridging). Most of these projects have a system where the liquidity provider adds to the collateral and is somehow incentivised in doing so (If you wonder how or where these 8% interest rates come from that you see offered in the space, this is it). Asset price mostly is determined by Oracles, but there is one project that I find particularly interesting. It's called uniswap. Uniswap determines price purely by market incentives. There is no orderbook and no oracle, the price is determined in a completely decentralised way. And it works, it is really fascinating :-) For inspiration, check out the website and paper to see how it works: https://uniswap.io/ , https://uniswap.info/
  8. It's an interesting thought, but a list of randomised nodes might not be a good idea. It has been found that in order to be save with your UNL, an overlap of 90% in UNL validators is necessary. But who knows, maybe the current validators have secretly made an agreement together to include a fixed list of secret validators next to the well known UNL That would work, but it would be security by obscurity, not the best .. I was thinking of keeping up a backup list of validators, ordered somehow by quality. If a validator on the UNL would fail for some rounds his place could be filled with the first on the backup list. But I haven't worked it out further, not sure if it would work. The proposed solution described in the link below is the opposite, it creates a negative list on the ledger:
  9. Ok, I'm not a professional consensus designer, just having a interest in the topic, so I hope my wording is ok. But what I mean is: What I understood is that not that long ago almost 6 validators were brought to their knees because of some spam attack and some other coincidental happenings (which I don't know what they were). So sabotaging could possibly be done by either spamming the network with messages, or otherwise you could try to a classic ddos on the IP-ports of the validators in question or target their locations (granted you must know where they are located or on which IP, but that seems not entirely impossible, knowing who the owners of the validators are). I don't think badly formed transactions will bring the network down, but if not enough validators are available to reach a quorum of 80% then the network will halt, because no new ledgers will be created. If the network doesn't continue or is halted, then it is no longer 'alive'.It could be revived though after some time, e.g. by changing the UNL If you compare with the current POW from Bitcoin or Ethereum, you could argue that for POW it doesn't matter if you bring a lot of mining-pools down, the liveness of the network is guaranteed because every node can become a miner, it doesn't need intervention from a central party. Network might slow down, though, because the needed hash-power is less available. In that regard it is comparable with the liveness of XRPL, both XRPL-consensus and POW are in danger of temporary halting the network by bringing elements in the network down, which might take some time to fix. But the difference is that in POW there is no need for additional agreement, new miners just start mining. in XRPL-consensus we need agreement on a new or adjusted UNL
  10. I kinda agree that the correctness / validity of the network is sound and that there is no incentive from within the network to be gained by attacking the network. But considering the liveness of the network: An attacker can sabotage the network if he wants to. Reasons why to attack can be as simple as 'hate' (still some of that available in toxic blockchain universe), political (not in my country) or incentives from outside the network. DDOS-ing or sabotaging the network (disable >20% of the validators from the dUNL) could devalue the price of XRP, an event that can be made profitable in other ways outside the XRPLedger network. That said, an argument could be made that this 'liveness' issue can also be solved in others ways than an incentive model like POW or POS. If you are ok with - Ripple singlehandedly changing the d(ynamic)UNL such that >80% of the validators are available again or - Allowing the network to be down for a longer period until all important nodes adjust themselves manually to another agreed upon UNL, then we're fine and we do not need incentives. But I think there is still room and need for improvement, so imo, argument made, but not conclusive.
  11. A milestone has been reached in the formation of the de-facto default UNL. The UNL consists now of 35 validators of which only 6 are owned by ripple. This is 17% of the validators, meaning Ripple no longer has veto on the amendment voting! The new validators are: - digifin.uk - rippleitin.nz Below the complete list: UNL at https://vl.ripple.com: 01 - nHBtDzdRDykxiuv7uSMPTcGexNm879RUUz5GW4h1qgjbtyvWZ1LE => n9LCf7NtwcyXVc5fYB6UVByRoQZqJDhrMUoKnr3GQB6mFqpcmMzg => validator.ripple.com 02 - nHUzum747yqip3HWSgzSNHNMjmLUqhroNVWidSRTREswEVhKNQEM => n9KQRiTw9LnSsVN2tv4guAqQ2KKUYmxnhT48QU2bbx8KmFGaUxTd => validator.ripple.com 03 - nHUon2tpyJEHHYGmxqeGu37cvPYHzrMtUNQFVdCgGNvEkjmCpTqK => n9JebyUXwBa5GoYJQ6AbupoMKyE2zaiR3FTfDTMkxpMMv1KPmQEn => validator.ripple.com 04 - nHU2Y1mLGDvTbc2dpvpkQ16qdeTKv2aJwGJHFySSB9U3jkTmj4CA => n9K2FpCqZftM1xXXaWXFPVbEimLX6MEjrmQywfSutkdK1PRvqDb2 => validator.ripple.com 05 - nHDDasc9BHNB99PW8KUduS8Phqg8NPUmjufzMU6HGGDMUH2xNpPh => n9L2y9THhdubapafmt7b2TRuhRUfPf1anchmiFyFSKBiaK3BEAwY => validator.ripple.com 06 - nHUUrjuEMtvzzTsiW2xKinUt7Jd83QFqYgfy3Feb7Hq1EJyoxoSz => n9LLqqH1cVFPjEnQYFQ6DooxuhHPQxwXgMjDGrpJ6pb1WGDoi76Q => validator.ripple.com 07 - nHUkp7WhouVMobBUKGrV5FNqjsdD9zKP5jpGnnLLnYxUQSGAwrZ6 => n9MzwWa4dwdZkRzj6XmihBG4ymGtMPd12cLjfhKwx5Hoqeu6WEgy => validator1.worldlink-us.com 08 - nHU95JxeaHJoSdpE7R49Mxp4611Yk5yL9SGEc12UDJLr4oEUN4NT => n9JtY9MqUcwKWenHp8WoRobFRmB2mmBEJd1ruJmhKGKAwtFQkQjb => flagshipsolutionsgroup.com 09 - nHUCCckfXVBdoounaU7JVnfdPdMXEeetwH8VdCBXD996BaVZ8WdJ => n9KiJP9wcJheTs6187LB8SP6Pw1UghKUQLgq4RmMKheTzvVhmesM => ripple.telinduscloud.lu 10 - nHUFzgC9fDw2MEDaiv9JMdBFhtJ6DMKoUCpS8gPGi6tkfbqmTyis => n94RChC3yKSHyXUerLYE1sjm13eP7hucSNpoZZTVgq4UtAiZAcgP => www.bahnhof.se 11 - nHBidG3pZK11zQD6kpNDoAhDxH6WLGui6ZxSbUx7LSqLHsgzMPec => n9KaxgJv69FucW5kkiaMhCqS6sAR1wUVxpZaZmLGVXxAcAse9YhR => bitso.com 12 - nHBgiH2aih5JoaL3wbiiqSQfhrC21vJjxXoCoD2fuqcNbriXsfLm => n9KhsMP6jKFQPpjJ9VwqyZSwrL4shdX9YknRwmsAVL1RNVrx4jLm => www.attokyo.com 13 - nHUcNC5ni7XjVYfCMe38Rm3KQaq27jw7wJpcUYdo4miWwpNePRTw => n9LEDYRJMx23ikoZS6YefTPuvLzNh56nXqpsavakWi2FivUEAkaq => rabbitkick.club 14 - nHUXeusfwk61c4xJPneb9Lgy7Ga6DVaVLEyB29ftUdt9k2KxD6Hw => n9KHXifDfimGs2CREvbRrAfjnoWcwjMCC8u8KLRTtrRAYk1ktSxX => validator.xrptipbot.com 15 - nHUd8g4DWm6HgjGTjKKSfYiRyf8qCvEN1PXR7YDJ5QTFyAnZHkbW => n9KSXAVPy6ac8aX88fRsJN6eSrJ2gEfGrfskUVJJ7XkopGsKNg9X => brex.io 16 - nHB8QMKGt9VB4Vg71VszjBVQnDW3v3QudM4DwFaJfy96bj4Pv9fA => n9J2hKPRZ9bUmsBD6d1j16G2P1arMxfASgSKYpoK9dRpJEuD3Joz => bithomp.com 17 - nHDwHQGjKTz6R6pFigSSrNBrhNYyUGFPHA75HiTccTCQzuu9d7Za => n9KKQUgUwXAAh7LKKjQos85vr19EvWghM13oBXurpvmRgEPZJ7XE => coil.com 18 - nHUpJSKQTZdB1TDkbCREMuf8vEqFkk84BcvZDhsQsDufFDQVajam => n9LFSE8fQ6Ljnc97ToHVtv1sYZ3GpzrXKpT94eFDk8jtdbfoBe7N => data443.com 19 - nHUVPzAmAmQ2QSc4oE1iLfsGi17qN2ado8PhxvgEkou76FLxAz7C => n9J1GJHtua77TBEzir3FvsgWX68xBFeC8os3s5TkCg97E1cwxKfH => ripple.ittc.ku.edu 20 - nHUT6Xa588zawXVdP2xyYXc87LQFm8uV38CxsVzq2RoQJP8LXpJF => n9Lq9bekeVhCsW8dwqzfvKsqUiu9Qxvwk9YmF2hxkBJjNrGNL5Fw => blockchain.korea.ac.kr 21 - nHB5kpvUaEpvCtwu31fMf6dTuuCNnWRctWrV3UEZ9rbtPdpvbUvJ => n9MtAgMDVFxEgzYsmZKNBYS4vTx76xSSD78tFdZFcL27aeXeeECQ => ripple.ntt.com 22 - nHULqGBkJtWeNFjhTzYeAsHA3qKKS7HoBh8CV3BAGTGMZuepEhWC => n9MZ7EVGKypqdyNguP31xSqhFqDBF4V5FESLMmLiGrBJ3khP2AzQ => shadow.haas.berkeley.edu 23 - nHUfPizyJyhAJZzeq3duRVrZmsTZfcLn7yLF5s2adzHdcHMb9HmQ => n9M2anhK2HzFFiJZRoGKhyLpkh55ZdeWw8YyGgvkzY7AkBvz5Vyj => xrp.unic.ac.cy 24 - nHBSUZJnqK5BRu3bWAmebfkETNeEFmU7sm3DXzCuEYzRkAEdxuTy => n9MUYTDQbd5BqxRiU8JuYoDAD9Trjzvd9VWfVYadgwqmxREjvRe5 => validator.xrpchat.com 25 - nHUFE9prPXPrHcG3SkwP1UzAQbSphqyQkQK9ATXLZsfkezhhda3p => n9J67zk4B7GpbQV5jRQntbgdKf7TW6894QuG7qq1rE5gvjCu6snA => alloy.ee 26 - nHUFCyRCrUjvtZmKiLeF8ReopzKuUoKeDeXo3wEUBVSaawzcSBpW => n9Lqr4YZxk7WYRDTBZjjmoAraikLCjAgAswaPaZ6LaGW6Q4Y2eoo => ripple.kenan-flagler.unc.edu 27 - nHUnhRJK3csknycNK5SXRFi8jvDp3sKoWvS9wKWLq1ATBBGgPBjp => n9LbDLg9F7ExZCeMw1QZqsd1Ejs9uYpwd8bPUStF5hBJdd6B5aWj => peerisland.com 28 - nHDB2PAPYqF86j9j3c6w1F1ZqwvQfiWcFShZ9Pokg9q4ohNDSkAz => n94RJmUKMJHTmuXhNYsFUwje9a9hD3Rw3dESntBDeonJLCjAEbMZ => aloha.xrpscan.com 29 - nHDH7bQJpVfDhVSqdui3Z8GPvKEBQpo6AKHcnXe21zoD4nABA6xj => n9MSTcx1fmfyKpaDTtpXucugcqM7yxpaggmwRxcyA3Nr4pE1pN3x => ripplevalidator.uwaterloo.ca 30 - nHUpcmNsxAw47yt2ADDoNoQrzLyTJPgnyq16u6Qx2kRPA17oUNHz => n94D6X6oFGyuvWpSjGwv3rmGSPSi5gNEVCDwnEc8arLC6HnqfEhn => isrdc.in 31 - nHUryiyDqEtyWVtFG24AAhaYjMf9FRLietbGzviF3piJsMm9qyDR => n9KAE7DUEB62ZQ3yWzygKWWqsj7ZqchW5rXg63puZA46k7WzGfQu => www.bitrue.com 32 - nHUED59jjpQ5QbNhesXMhqii9gA8UfbBmv3i5StgyxG98qjsT4yn => n9KcVtcHZThHainPdHC7CkQKZMEVjAcRujV2CMKdKHk65Ewsawsu => crcm-xrp.blockdaemon.com 33 - nHDDE4Y3z5EE2VDDYrzheYQ4xC3F29SJsKT4dqhX4iyTLhuWgZnp => n9KXj6AkXsMiPKgTs6axKn93CVKDmLsPch8QFZNA9xsGkQo3w5bk => xrp.coinfield.com 34 - nHUvzia57LRXr9zqnYpyFUFeKvis2tqn4DkXBVGSppt5M4nNq43C => n9KNmrXo9gK3ucZy8KHKFM113ENGv6uyukS6Bb7TtuvEx98SdwMS => digifin.uk 35 - nHUcQnmEbCNq4uhntFudzfrZV8P5WLoBrR5h3R9jAd621Aaz1pSy => n9Jb7jTyvyDNm4oN5tEtQYorevWcPCaYuj6X81TzcNqHkuwtXatR => rippleitin.nz
  12. True but in that case you want to make market in only one direction. If you want to make market in both directions you will need to have both assets. Consider that you have to rebalance at one point
  13. That depends on your point of view. How about a EUR/USD market maker ?
  14. Imo, market makers make money by offering a price somewhere in the order book that is higher than their own estimate of the correct price (and then of course that price will have to be captured). If for example the complete spread is below the estimated correct price, then you will not make money selling it for any of those prices in the spread. They benefit, but it solely depends on which asset you want to express your benefits in. Say you trade USD and XRP. Which one do you prefer? Do you value one above the other? If you consider a perfect market, then both prices are at their equilibrium and you should prefer not one above the other. You should only be interested in the little margin you will get from selling the one asset for the other.
  15. Both actions are 'market taking' and will enlarge the spread between buy and sell. If you sell at the initial exchange, it will be at the sell price and not at the 2 ticks up 'buy' price. So, imo your story would only work if (other) market makers would work to minimise the enlarged spread caused by the buying on the initial exchange (and then setting a price based on the median of the spread). And on the other exchange the reverse would happen, so basically, in my view ODL would not directly lead to a higher price, just liquidity that leads to more liquidity. There is maybe the theory of Adam Smiths 'Invisible hand' but my interpretation of that is that in a competitive free market and good liquidity the price will reach its equilibrium. That does not say anything about the height of the price, but the price could rise because of its increased utility
  16. 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..
  17. 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/
  18. 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.
  19. 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
  20. 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
  21. 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
  22. 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.
  23. 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
  24. 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/
  25. 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) })
×
×
  • Create New...