Jump to content

Guest1

Silver Member
  • Posts

    723
  • Joined

  • Last visited

  • Days Won

    3

Guest1 last won the day on October 29 2018

Guest1 had the most liked content!

3 Followers

About Guest1

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Guest1's Achievements

  1. I'm taking it from the point of view that Deposit Auth means exactly those two words in plain English. As you say, I'll try it out to see if it works. I have no doubt it will.
  2. I would like to only receive payments, orders, trust line creation from specified XRP addresses and no other XRP addresses. Is this possible? For example, there may be certain malicious XRP addresses associated with hacking and a legal entity may not want to be associated in any way. However, if a transaction is initiated form such a malicious XRP address, the transaction will be shown in the destination address and the Tx permanently printed on the XRPL.
  3. Perhaps I've misunderstood how seq numbers work. If you could kindly look at the below and see where I'm going wrong, that would be much appreciated. Here is a hypothetical situation with two central locations firing transaction requests for my XRP account to two different rippled servers: *lets assume my XRP account already has a sequence number 125 prior to the following events. Location A -> Requests the last account sequence number for my XRP account from rippled Server A -> Server A returns value 125 -> transaction X is created by Location A with seq incremented by one = 126 and submits request to Server A Location B -> Requests the last account sequence number for my XRP account from rippled Server B before transaction X from Location A was propagated via Server A to Server B -> Server B returns value 125 as it does not yet know about transaction X -> transaction Y is created by Location B with seq incremented by one = 126 and submits request to Server B -> by the time this transaction is received by Server B, assume that transaction X from Location A has been completed and propagated -> Server B returns tefPAST_SEQ error due to seq 126 now being a past sequence number.
  4. So what would be the best way to fire multiple transaction requests from say 10 transactions per second from each of say 10 different servers (100 transactions per second across 10 servers) all from the same XRP address, while somehow keeping track of the sequence number across all the transaction requests so that none of them return a "tefPAST_SEQ"? Would all the transactions first need to be channeled to a central message queuing server of sort (Redis? Kafka?) where a counter variable is used to keep track of the sequence number and increment by one for each of the rapidly incoming transactions?
  5. Hey @Julian_Williams, the website address has been changed quite a while ago to: http://www.xrpcalculator.com/ Enjoy!
  6. Convolutional Neural Network (CNN) at its very best. Ideally:
  7. I know that some form of a hidden ledger theory was previously known to the community and many people told me it was debunked. I have an alternative theory and it would be appreciated if you @BobWay could have a read and let me know if it makes sense or if it's not possible/feasible. ------------------------------------------------------------------------------------------------------------------------------------------------------ How Ripple can create (or possibly already have created) a hidden ledger, and subsequently turn the switch on to redirect the volume to the public ledger. Step 1 - Create another copy of XRP Ledger Test Net, henceforth referred to as 'Hidden Ledger' Current Test Net address: https://s.altnet.rippletest.net:51234 Example Hidden Ledger address: https://s.altnet.xrphiddenledger.net:51234 (just an example to illustrate my point - no dns entry for this actually exists) Step 2 - Make a educated guess about the total circulating supply of XRP: - Take total 99.xx billion supply - Deduct escrowed XRPs - Deduct sum of XRPs in wallets that have been reasonably dormant (e.g. 80%+ of wallet balance not traded) for the last 1 year or longer Step 3 - In the Hidden Ledger, limit the total number of XRPs to the total circulating supply of XRP from Step 2 above, in order to reasonably simulate the short-term real-world XRP supply and price dynamics. Step 4 – Mimick the total number of UNLs to the current number in the public XRP Ledger by launching additional computer instances in the cloud that are accessible only by Ripple. Configure these servers as close to real-world as possible. Step 5 - Provide the Hidden Ledger address from Step 1 to all the current and prospective partners (including NDA partners), and provide them instructions on how to direct daily transactional volumes to this Hidden Ledger for testing. Step 6 (continued) Such information may contain API related details such as the Websocket Server address, format of the JSON message (e.g. {wallet address: '', transaction type: '', etc}, and API function names to send transactions to the Hidden Ledger Step 7 – Ensure that access to the Hidden Ledger is confined to these institutions only by making use of firewall / security groups and network access control lists (NACLs) that only allow specific IP addresses to connect. Step 8 – Set up stress test by requesting all participants to direct ALL volumes to Hidden Ledger over 24-48 hours. e.g. DTCC, CLS, ACI, TARGET2, as well as central banks, R3 and Hyperledger. Combined volumes may potentially be in the order of USD 20+ trillion PER DAY. Step 9 - Stress test the Hidden Ledger environment throughput (max 1500 TPS) and observe the impact on the XRP price when the volume is at its peak. Step 10 – Tweak the price of XRP (e.g. $500 - $1500) as well as the frequency of transactions (e.g. frequency of bulk settlements) such that the price of XRP is stable during such stress tests. This gives an idea of the final value of XRP required for total volume. Step 11 – Perform such stress test from Step 9 and Step 10 for a single participant only and observe the price impact on XRP. Do this for each participant. Step 12 – Perform any additional tests in the Hidden Ledger such as the impact of including a test version of Cobalt or any other tests as deemed necessary Step 13 – Make sure to keep the Hidden Ledger private so that such tests are not observable to the retail market at all times at all costs. Step 14 – Provide the Hidden Ledger participants with the address of the real-world public XRP Ledger ('wss://s1.ripple.com:443') and, if necessary, provide instructions on how to change the address from the Hidden Ledger to the public XRP ledger. Step 15 – Perform a gradual switch over from the Hidden Ledger to the Public Ledger by asking each participant to change the address from the former to the latter, while closely observing the actual vs expected impact on the retail market dynamics and the price of XRP.
  8. - XRP + Cobalt is the only way in the foreseeable future that can settle 6,300 trades per second for five continuous hours. - Hence we are waiting for Cobalt (+ regulation) for XRP adoption at mass-scale - If payments are recorded on the digital ledgers in real-time but settlements do not happen real-time, this potentially creates a backlog of settlements and a havoc in the making. Hence R3, DTCC they need Ripple + XRP + Cobalt.
  9. I have the following javascript code to obtain wallet XRP balance. I would like to filter this balance by only 1 destination tag so that I get the wallet balance just for that specific destination tag. Does anyone know how to do this in javascript by modifying the code below? ------------------------------------ const RippleAPI = require('ripple-lib').RippleAPI; const api = new RippleAPI({ server: 'wss://s.altnet.rippletest.net:51233' }); const myAddress1 = <XRP wallet address>; api.connect().then(() => { console.log('getting account info for', myAddress1); return api.getAccountInfo(myAddress1); }) .then(info => { console.log(info); console.log('getAccountInfo done'); }) .then(() => { return api.disconnect(); }) .then(() => { console.log('done and disconnected.'); }) .catch(console.error);
  10. Just a small correction: XRP "wallet" will be unobtainable by most (assuming minimum threshold of 20 XRP does not change)
  11. Just need to remember that potential of XRP drastically increases once the news hits the public that trillions will be bridged (moved) via XRP, potentially in the order of double digits to triple digits XRP price. Such a model helps to assess in your XRP selling strategy. If you know the potential is e.g. triple digits, it may be possible you wouldn't sell 100% of your stack when XRP is $3 for example as in the back of your mind you have taken into the possibility of XRP price reaching such a potential in the future.
  12. Take a simple case: Daily transaction volume = 100 trillion Circulating supply = 50 billion XRP Average number of times a single XRP is traded in a day = 5 Price of XRP is roughly 100 trillion / (50 x 5 billion) = $400 per XRP I don't care whether the subtleties of this estimate is incorrect or not. In this case all I need to know is that a reasonable range for the price of XRP would be in the order of hundreds if trillions of dollars are transacted in XRP
  13. Yes, Ripple is engaging with SWIFT, ACI, the IMF, World Bank, etc to get trillions per day transacted in XRP. Whether their model is a well-educated guess or not, we can certainly deduce that they are thinking of the price of XRP in the order of thousands when all this plays out in their favour. This is why David Schwartz said "don't miss the next Ethereum". And you are right. We should be asking ourselves "what can we take away from such a model despite it not bring a perfect representation of reality?"
  14. and I haven't received your response to this. If you think someone else's model is crap, then create your own model and bring it here. End of discussion until then.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.