Jump to content

jn_r

Member
  • Content Count

    554
  • Joined

  • Last visited

Everything posted by jn_r

  1. 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); })
  2. jn_r

    How does coil work?

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

    Ripple Network forked to create SystemD

    I know this discussion has been before, let's not pick it up in this thread. happy to agree that we disagree for now :-)
  4. jn_r

    How does coil work?

    What I can see, you receive a JWT token with the following content: { "userId": "xxxxxxxxxxxxxxxx", "throughput": 100000, "currency": "USD", "scale": 9, "iat": 1547251202, "exp": 1548460802 } iat is issued time, exp is expiration time. When the token is expired a new request is done and coil can recalculate and maybe change the throughput. I am not sure what the frequency of the 0.0001 USD payment is, seems like +/- 30 seconds. You do not have control over this yourself, coil calculates all this for you.. I also see that a call is then made to the SPSP (simple payment service provider) https://twitter.xrptipbot.com/<name> in this case - and according to ILP protocol it returns - the -lowlevel- ILP account, which is hosted at strata. Now that this endpoint is known, a low-level BTP (Bilateral Transfer Protocol) message is sent to coil's ILP-endpoint to start the actual ILP-payment. this payment is then repeated every 30 seconds. hmm, hope I interpreted that correct and if at all understandable :-) I have some foreknowledge as I did some research on ILP previously. If you read through the ILP-github it is all there, it's just not that easy
  5. jn_r

    Understanding Validator relationships

    no problem @WrathofKahneman I don't know either what they exactly are and am curious/interested to find out more. - The assumption that they do not trust the real UNL I am not sure that is correct. Maybe some of them just can't keep up with the network, but on the other hand I think they would then not propose a new transaction set, so maybe your assumption is right. - If the forked network would choose to trust the real UNL at some point, then they should 1) forget about their current history and then 2) start again by receiving ledgers from the UNL validators.But I haven't tried this out yet myself, would love to hear from some ripple-representative.
  6. jn_r

    Understanding Validator relationships

    They would only process if they have reached their own quorum from their own UNL. Maybe they deliberately try to create a fork, have maybe 3 other validators in their UNL doing the same thing. They would send out the agreed upon transaction set over the rippled network, but as nobody is following them, it will just be in thin air
  7. jn_r

    How does coil work?

    only for twitch and youtube. If you want to see for yourself, open a chrome browser (and be coil-enabled), open the 'inspect' window (alt-cmd-i on a mac) and in there the tab 'network'. filter on 'coil'
  8. jn_r

    How does coil work?

    Ok, so I did some network-debugging on a youtube session and it is not option 3 but option 1: 1) The chrome-extension makes a call to an url-service from coil to receive the corresponding content creator's ILP-endpoint and then makes the ILP-payment They call an endpoint at the coil website where they request the corresponding ILP-payment-pointer that is linked to a certain youtube website. And then respond with the ILP-payment-pointer, which then can be used by the coil-extension. Must say, I am a bit disappointed by this, since they do this for every youtube call I make, which is a bit of a privacy thing. I'd rather have seen option 3 implemented.. Edit: I also did a network-debug session on a twitch session and there the same happens. First a call to coil to retrieve the ILP pointer. The difference is that now a payment-pointer at coil is provided ($spsp.coil.com/twitch/< twitch-account >) so it basically works as I previously described, the payment from browser to coil is ILP and then from coil to twitch I can't see, but it will be based on the twitch/bit system.
  9. jn_r

    How does coil work?

    I wouldn't say collaboration. I think if they use your google-account that it's just a generic property field (but I haven't found it yet) of your google-account that coil uses to place your ILP-paymentpointer in
  10. jn_r

    How does coil work?

    I don't know how twitch works. Do you receive twitch bits? The coil page mentions: In that case I think the connection from coil-extension to coil-ILP-provider is ILP, but coil will then be the endpoint and send the Twitch Bits (what a name) via their own system. But if you use youtube it is different, you actually receive the funds in you ILP payment pointer. I have tested that (connecting my sons google-account and watching his youtube channel) and I received some XRP in my xrp-payment-pointer.
  11. jn_r

    Ripple Network forked to create SystemD

    I disagree. Keeping history will allow verifying that the validators are not misbehaving. There was a tweet thread on this subject where Nik also joined in. Not sure where best to start that thread, but this is one of those tweets: Key in this is that you need a previous ledger (read - history) to be able to calculate the next ledger Edit: But besides that, I'm not sure the reason why they started the fork. Imo you should fork only if you disagree with the current status of a chain and can not come to consensus about the current way things are going. That would mean that they would have discussed their improvement points with Ripple and the community, and could not come to consensus, but I doubt that has happened
  12. jn_r

    How does coil work?

    If you are a content creator and want to start receiving payments from Coil you need to provide your Payment Pointer. You can create one at xrptipbot. This is your personal ILP endpoint where you will receive payments. When - on the other side - you are part of the coil program and want to pay for monetised content, you download a chrome extension to your browser. When you log-in, you will be able to identify yourself at one of the coil ILP providers. So if you are looking in your browser to web-monetised content, your browser will start the coil-extension, which will use ILP to contact a coil-ILP provider. Because the coil-extension (which is an ILP connector) has a relationship with the coil-ILP-providers (it knows who is logged in at the coil-extension), the coil-endpoint can use you account-money and start an ILP session with the next endpoint. In case that endpoint would be my xrptipbot-account, it would start an ILP-session with the ILP-connector where XRPtipbot is connected to and transfer funds. Now if you also create content on youtube, then you can attach your google account at coil website. It mentions in the FAQ the following: Thus, what I *SPECULATION* think happens, is that the extension sees the account owner (the google account) of the youtube channel I am watching, and somehow resolves that to the ILP-endpoint from the content creator. The problem here is where does the translation from google account to ILP-endpoint takes place. I see 3 options: 1) The chrome-extension makes a call to an url-service from coil to receive the corresponding content creator's ILP-endpoint and then makes the ILP-payment 2) The chrome-extension makes the ILP-payment to a coil-ILP-endpoint with the google account in the name and then coil forwards it again to the content creator's ILP-endpoint (which would mean that 2 separate ILP payments are made) 3) The ILP-endpoint is somehow stored at the google-account and can be directly retrieved by the coil-browser-extension. The extension can then directly make the ILP-payment I have tried the process of attaching my google account and it required for coil to have access to change some setting in my google account. So I suspect that option 3 is the one that is used. (which would also be the most decentralised one..)
  13. jn_r

    Understanding Validator relationships

    https://developers.ripple.com/data-api.html#get-daily-validator-reports Definition of chain: I think it must be rippled validators that are found to be linked to the network - as they are found with the XRPL Network Crawler - but that are not validating the same set as either main net or altnet.. Therefor they are other forks of XRPLedger. It is also interesting to click on the validator link, then you will see that most of them switch from one chain to the other, apparently having difficulties to stay on the same chain
  14. Not on AWS, but a smaller local cloud service provider. I am running on VM. For performance it is better to run directly on hardware, but that is more costly and you have to manage a possible hardware failure, which I think with VM is handled better (comes with the VM solution). I am running VM, on SSD, 6GB Ram and rippled size 'tiny'. This is costing me +/-500 Euro p/y There's also this: https://developers.ripple.com/capacity-planning.html
  15. I am indeed running it in a virtual environment. Happy with what I am provided with for now, but I can imagine it differs per provider:-)
  16. I am running with 6gb mem for quite some time now. The swap memory is being used completely, and not much of the 6gb is free, but it is behaving ok as far as I can tell.
  17. jn_r

    The impossibility of liquidity in xrp

    another one ..
  18. jn_r

    The impossibility of liquidity in xrp

    If really desirable, years from now, when IMF is holding the XRP reserve, and if all validators agree because everyone agrees it is really necessary, then we could build the option of an XRP mint in to the ledger - in control e.g. by IMF. Would that solve the issue? I'm not in favour, but just saying, that is not too difficult to build. But then the question, who gets to decide to whom the new money goes, is it a central organisation like IMF? Or are we going to share it (pro rata) amongst all XRP holders, like Stellar does now? Considering you would share the new money evenly amongst all shareholders - it makes me wonder, why does that help in liquidity? Somehow it only seems to work if the money is not shared evenly, because only then people are left with less value and will want to spend their XRP. Isn't that weird?
  19. jn_r

    The impossibility of liquidity in xrp

    Why not create a picture where both systems are used? In the next couple of years that will be the situation anyways. It is the current positioning of xRapid in RippleNet, banks can pick the best available liquidity option. It will allow for an organic growth of the xRapid solution. If the liquidity halts in the fixed supply settlement system, banks will switch to the monetary elastic system. It will be interesting to see what will happen if Fed decides for QE in this situation. They have no (not much) control over crypto debasement, so I think crypto will tend to deflate and fiat will inflate. What will happen, crypto less liquid, fiat more liquid, will it balance itself out?
  20. jn_r

    The impossibility of liquidity in xrp

    Touche Yet in all my stubbornness I googled further to find this: https://mises.org/library/our-money-based-debt Interesting read - again, although in the comments I see that not everyone agrees. Below is an excerpt from the link that states that fiat money is borrowed and that interest is paid:
  21. jn_r

    The impossibility of liquidity in xrp

    looking at the tweet from Kevin W. Massengill not sure if his statement is correct, but what if it is, and we can state that a crypto-currency is non debt based, would other rules apply for this cryptocurrency?
  22. jn_r

    The impossibility of liquidity in xrp

    I had the ancient Rome inflation in mind (https://mises.org/library/inflation-and-fall-roman-empire is a nice - but long - read). You are probably right that they knew the coins would be worth less. To rephrase, I think the reason why they did it was wrong, they did not do it for the economy as a whole (as our current economist of course do). To quote the final part from the article:
  23. jn_r

    The impossibility of liquidity in xrp

    The consequence of dilution of metal coins was inflation, but I don't think they had the intention to inflate the coin value. They just wanted more money. Current economist want inflation, because it will make money go round (velocity, correct?).
  24. The power of words.. In this case - as an exchange - you have to choose if you want to help Ripple with the regulation by calling it XRP's, or you do not want to help Ripple with the regulation and call it ripples. I do hope the security stuff gets settled soon, so this will become a non-discussion. In the meantime, for words' sake, lets call it 'X R P'
  25. I like the way it is clearly stated above. Unfortunately this and the link you provided are just some of the places on a very big space where statements about the protocol are being made and it might take a while and perhaps some more word fights to make this the new standard. I also had to do a good search in the twitter jungle threads to find where it then actually was proposed that it should be XRP Ledger (XRP), but I found it (here) :-) And that also leads me to the next point, why does Kraken/Jesse say the convention is <protocol> <asset>? I think that is where he is wrong, the convention (also on the kraken website) is <descriptive name> <asset>. Take Lumen <XLM>, Lumen is by no means the name of the protocol. As is US Dollar not the name of a protocol, but the name of the asset, ISO-coded as USD. In that regard, I think the right question is, what is the descriptive name for XRP, or how do we call XRP?
×