mDuo13

Ripple Employee
  • Content count

    225
  • Joined

  • Last visited

  • Days Won

    18

Reputation Activity

  1. mDuo13 liked a post in a topic by karlos in FAQs: The Answers   
    As mentioned here, we are compiling the FAQs for Ripple with the common concerns/objections. Here are the questions, and my example answers. This is only my small attempt to answer the questions, please write your own! Critique these responses and correct them. I'm sure there any many good points that have not been addressed yet. Make sure you "like" the answers you want to see included in the final guide!
    I think this will be an invaluable resource for the community. Whenever a newbie has a common question, we can refer them to this guide. The FAQ will be included in the Links & Resources section for easy reference. We will also start promoting the Links & Resources section more prominently for joining members. 
    Once all the best response have been compiled, I will create a new "Page" with the final version. 
    ________________________________________________________
     
    Common questions and concerns about Ripple
    XRP is pre-mined
    Using the term "pre-mined" is a bit misleading, as Ripple does not involve mining to secure the network. All the XRP that that can ever exist (100 billion) were already created at inception. Mining is very costly in terms of energy and the environment, and is not very effective at distributing a currency fairly (i.e. due to mining cartels). 
     
    Ripple owns 60% of all XRP
    Ripple (the company) currently has custody of the majority of XRP. Having those XRP on hand gives Ripple the advantage of being able to incentivise the network to create growth, liquidity and new markets. Whilst other crypto markets move toward currency centralisation because of mining, the Ripple network is moving in the opposite direction, slowly distributing XRP each month. Once the escrow is completed, Ripple will only hold around six billion XRP (or 6% of the total supply) to use freely (see here)
     
    Ripple can sell one billion XRP a month under the lockup
    Under the terms of the escrow, 55 billion XRP are locked up, with one billion per month available to grow the network. There will be 55 individual lockup contracts of one billion XRP each; each contract will expire on the first day of every month. Whatever hasn't been spent at the end of the month will be put into a new escrow account at the back of the queue. However, this does not mean Ripple intend to sell one billion XRP per month. Currently (and for many years) Ripple has been distributing around 300 million XRP per month. (see here). Ripple has proven after many years it can distribute XRP in a responsible manner.
     
    Ripple can make as many XRP as they want (a.k.a printing money)
    The maximum amount of XRP that can ever exist is 100 billion. This amount is established at the protocol level, and already exists on the ledger today. Soon Ripple will introduce a new amendment that ensures no further XRP can be created, even accidentally (see here). While it is technically possible at this point for Ripple to alter the protocol to create more XRP, once there are enough independent validators this will be impossible.
     
    Banks won't use XRP
    Banks may not yet use XRP, because the laws and regulations have not caught up to digital currencies. However, progress is being made, and already banks have started to hold digital currencies:
    The role of XRP is that of an intermediary currency, and banks may never need to touch XRP for it to play a part in a successful payment. There are significant cost savings to using XRP for payments, however it remains to be seen if banks will choose this option. Banks are under great pressure to increase profit, and XRP definitely increases profit.
     
    Jed wants to crash the price/ suppress the price
    Jed McCaleb was one of the founders of Ripple, but left the company in 2014. At inception he was allocated 8 billion XRP. After leaving he attempted to dump his XRP on the market, and a court case ensued. The aftermath was a settlement agreement where Jed's XRP were locked up and held in custody by Ripple (see here). The terms of the agreement are:
    Under the terms of the agreement, Jed is severely restricted from selling his XRP, and has very little impact on the market. The price of XRP also increased from $0.006 to $0.25, strongly suggesting Jed cannot manipulate the market.
     
    ILP means lack of focus on XRP / Ripple doesn't care about XRP
    Ripple has reaffirmed its commitment to XRP many times. They are actively seeking new liquidity partners, adding XRP to exchanges (Bithumb, Coinone etc) and creating incentives for people to use XRP. It is here to stay. Ripple has several employees who are devoted solely to improving the appeal of XRP (such as the Head of XRP markets).
     
    Ripple is intentionally keeping XRP stable/low. XRP is better for banks if it has low volatility
    It is true that market makers and banks would prefer a stable currency. However banks still stand to save money even with high volatility (see here). 

     
     
    Also, Ripple has stated on several occasions they do not engage in short term price action. (see here)
    They hold a large amount of XRP, and it is absolutely in their best interest to see the price go up, rather than suppress it.
     
    There's no incentive to run a validator/nobody is going to run them
    Although the technical requirements to run a validator are low, it is not a trivial task if you want your validator to participate in any meaningful way. Validators need to show a history of accurate and on time validations. They need to be run by independent parties, regularly updated and kept secure. For these reasons, the list of validators is currently low. Also unlike bitcoin nodes, their is no financial incentive to run a validator.
    However, validators are crucial for keeping the network healthy, and unlike other crypto currencies, only a small amount of  validating nodes are required to run the network smoothly. Because the owners of Ripple validators are driven by the desire to help the network and not strictly for financial reward, validators can be drawn from the wide range of industries: financial institutions, government agencies, and educational bodies. 
    Interest in running a validator is increasing increase over time (see here)
     
    Ripple can freeze funds using the Freeze feature
    The Freeze flag is only available for non-XRP balances. If you own XRP, it cannot be frozen.

    The early ledgers got lost
    The ledger details before 32,570 were lost due to a bug. As of writing, Ripple has completed over 30 million successful ledger closes. The ledgers lost is under 0.1%, and do not affect the operation of the network moving forward.
     
    The founders allocated too much XRP for themselves
    The initial allocation went like this:
    At inception, there were 100 billion XRP created.
    20 billion XRP were given to the founders (Chris Larsen, Arthur Britto and Jed McCaleb)
    80 was given to the company (Ripple Inc)
    While 20% seems large, it is important to remember that a large portion has been donated to charity. Chris Larsen has committed 7 billion XRP to rippleworks (pledge details here). Jed McCaleb has also committed 2 billion to charity (see here).
    Assuming the remaining 11 billion is still in the founders possession and not already sold or donated, they currently own 11% of XRP. Of that 11%, a large portion is locked up under the settlement agreement. For comparison, the unknown "Satoshi Nakamoto" is estimated to have around 1 million bitcoins, or around 4.7% of all bitcoins to sell at any time.
     
    Ripple controls the only validators that matter 
    In order for the network to become properly decentralised/distributed, it needs to reach a critical mass (see here). Once there are enough independent participants, it will be relatively trivial to extend trust across the network. However it vital that this process is done carefully and after third party validating nodes have been properly attested. 
    Ripple has explained its plan to further decentralise the network (see here).
  2. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  3. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  4. bickelaer liked a post in a topic by mDuo13 in Hacking XRP   
    If you were thinking of brute-forcing XRP secrets, I highly recommend you put that effort into studying public key cryptography. Not only do you have a higher chance of cracking someone's secret key before you die of old age, you're also far more likely to develop useful skills that can earn you a lof of XRP in actual legal income.
    Yes, it's entirely possible that someone may invent a new algorithm that makes it far easier to decipher private keys from public signatures. (If they do, no money is safe.) Brute-force ain't gonna get you there, though.
  5. bickelaer liked a post in a topic by mDuo13 in Hacking XRP   
    If you were thinking of brute-forcing XRP secrets, I highly recommend you put that effort into studying public key cryptography. Not only do you have a higher chance of cracking someone's secret key before you die of old age, you're also far more likely to develop useful skills that can earn you a lof of XRP in actual legal income.
    Yes, it's entirely possible that someone may invent a new algorithm that makes it far easier to decipher private keys from public signatures. (If they do, no money is safe.) Brute-force ain't gonna get you there, though.
  6. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  7. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  8. dfault123 liked a post in a topic by mDuo13 in Which Consenus Algorithm Is Fastest At Processing Transactions?   
    I'm pretty sure the reason nobody else (but Stellar of course) uses a "trusted validators" consensus protocol like Ripple's is that it doesn't scale to more validators automatically. The one really big deal with proof-of-work algorithms is they make it so any new server can participate in the validation process with no human intervention or configuration. That's possible because proof-of-work assumes that no malicious party can accumulate more computing power than all the non-malicious parties combined.
    When you look at it that way, it's really impressive because the fact that that Bitcoin and major altcoins haven't had a 51% attack yet is evidence that proof-of-work actually works. Starting from just a handful of servers, Bitcoin now has a huge number of mining servers worldwide participating in its "consensus" process. On the other hand, as we reach later and larger stages with greater understanding, we're now starting to see where it could go wrong. A few mining pools with subsidized electricity have gained inordinate influence over the blockchain. Does this lead to a 51% attack? We'll see. But it certainly does lead to huge backlogs of transactions and wasteful electricity usage.
    Ripple's consensus algorithm, by contrast, requires manual intervention to increase the number of validators. The people who run rippled servers have to manually choose which servers to add to their UNLs; and if they choose poorly, they could end up forking from the rest of the network. (For example, if you edit your UNL to include 20 additional validators that are all ultimately controlled by the same party, that party could dictate which ledgers and transactions your server thinks are validated.) To guarantee a lack of forking, the RCL needs two things: validators' trusted node lists must have sufficient overlap with one another; and the number of maliciously-colluding nodes in those trusted lists must be small enough. The exact math is in the consensus whitepaper, but basically it comes down to: consensus works smoothly as long as everyone in the network has more than 20% overlap in their UNL, and each server works well as long as no more than 20% of the validators in its UNL are malicious. There's also a huge gap between "there are enough malicious nodes to stop consensus" (>20%) and "there are enough malicious nodes colluding to confirm a transaction fraudulently" (>80%).
    There are some major upsides to Ripple's system, aside from the oft-mentioned efficiency & speed things, too. The RCL's consensus algorithm is not vulnerable to the same type of 51% attack, since malicious actors can't participate in the consensus process without convincing validator operators to add the malicious actors' validators to the trusted operators' UNLs. And, if you identify a malicious actor, you can remove that actor from your UNL and ask others to do the same, locking them out of the process. With Bitcoin, the only recourse you have is to amass more computing power to compete, or try to get people to manually recompile the software to blacklist mining servers you don't like. On a more esoteric note, if there's a case where two "cliques" of RCL servers really don't want to trust one another, they can "agree to disagree", remove each others' members from their UNLs, and amicably diverge, intentionally forking the network. (Server operators who are caught in between would have their server correctly report "no consensus" until they chose which clique to follow.)
    Ripple's plan is to move beyond this to a stage where UNLs are completely dynamic, too, which starts with the "Dynamic UNL Lite" code that debuted in rippled 0.60.0. This algorithm introduces the idea of a "validator registry" or "publisher" that lists validators. In the past, we also called this same concept an "attestor". The idea is that someone (probably Ripple first) publishes a list of validators they think are reliable, and you configure your rippled with a publisher instead of configuring your UNL directly. You can also add multiple publishers to choose from all their lists. (Eventually we may add a score attribute to the list format, too.) Your rippled periodically fetches the latest list and updates its UNL automatically to a subset of the results. It's possible to have multiple publishers supporting the same network, as long as their lists of validators have enough overlap. It might also be possible to have a parallel network by using a publisher with a completely separate list. For example, the Ripple Test Net would have its own registry with a completely separate set of validators that are all on the test net.
  9. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  10. dfault123 liked a post in a topic by mDuo13 in Which Consenus Algorithm Is Fastest At Processing Transactions?   
    I'm pretty sure the reason nobody else (but Stellar of course) uses a "trusted validators" consensus protocol like Ripple's is that it doesn't scale to more validators automatically. The one really big deal with proof-of-work algorithms is they make it so any new server can participate in the validation process with no human intervention or configuration. That's possible because proof-of-work assumes that no malicious party can accumulate more computing power than all the non-malicious parties combined.
    When you look at it that way, it's really impressive because the fact that that Bitcoin and major altcoins haven't had a 51% attack yet is evidence that proof-of-work actually works. Starting from just a handful of servers, Bitcoin now has a huge number of mining servers worldwide participating in its "consensus" process. On the other hand, as we reach later and larger stages with greater understanding, we're now starting to see where it could go wrong. A few mining pools with subsidized electricity have gained inordinate influence over the blockchain. Does this lead to a 51% attack? We'll see. But it certainly does lead to huge backlogs of transactions and wasteful electricity usage.
    Ripple's consensus algorithm, by contrast, requires manual intervention to increase the number of validators. The people who run rippled servers have to manually choose which servers to add to their UNLs; and if they choose poorly, they could end up forking from the rest of the network. (For example, if you edit your UNL to include 20 additional validators that are all ultimately controlled by the same party, that party could dictate which ledgers and transactions your server thinks are validated.) To guarantee a lack of forking, the RCL needs two things: validators' trusted node lists must have sufficient overlap with one another; and the number of maliciously-colluding nodes in those trusted lists must be small enough. The exact math is in the consensus whitepaper, but basically it comes down to: consensus works smoothly as long as everyone in the network has more than 20% overlap in their UNL, and each server works well as long as no more than 20% of the validators in its UNL are malicious. There's also a huge gap between "there are enough malicious nodes to stop consensus" (>20%) and "there are enough malicious nodes colluding to confirm a transaction fraudulently" (>80%).
    There are some major upsides to Ripple's system, aside from the oft-mentioned efficiency & speed things, too. The RCL's consensus algorithm is not vulnerable to the same type of 51% attack, since malicious actors can't participate in the consensus process without convincing validator operators to add the malicious actors' validators to the trusted operators' UNLs. And, if you identify a malicious actor, you can remove that actor from your UNL and ask others to do the same, locking them out of the process. With Bitcoin, the only recourse you have is to amass more computing power to compete, or try to get people to manually recompile the software to blacklist mining servers you don't like. On a more esoteric note, if there's a case where two "cliques" of RCL servers really don't want to trust one another, they can "agree to disagree", remove each others' members from their UNLs, and amicably diverge, intentionally forking the network. (Server operators who are caught in between would have their server correctly report "no consensus" until they chose which clique to follow.)
    Ripple's plan is to move beyond this to a stage where UNLs are completely dynamic, too, which starts with the "Dynamic UNL Lite" code that debuted in rippled 0.60.0. This algorithm introduces the idea of a "validator registry" or "publisher" that lists validators. In the past, we also called this same concept an "attestor". The idea is that someone (probably Ripple first) publishes a list of validators they think are reliable, and you configure your rippled with a publisher instead of configuring your UNL directly. You can also add multiple publishers to choose from all their lists. (Eventually we may add a score attribute to the list format, too.) Your rippled periodically fetches the latest list and updates its UNL automatically to a subset of the results. It's possible to have multiple publishers supporting the same network, as long as their lists of validators have enough overlap. It might also be possible to have a parallel network by using a publisher with a completely separate list. For example, the Ripple Test Net would have its own registry with a completely separate set of validators that are all on the test net.
  11. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  12. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  13. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  14. Dizer liked a post in a topic by mDuo13 in Transaction Volatility and FI's   
    If the payment uses ILP and goes Fiat→XRP→Fiat, then the institutions on the sending and receiving side aren't exposed to any volatility risk in XRP exchange rates, but the trader/liquidity provider is the one exposed to the currency risk. For example, liquidity provider Mark agrees to an ILP quote and lock up 400 XRP in exchange for 100 USD. During the time before this ILP quote expires, the price of XRP suddenly skyrockets and that 400 XRP is now worth over 150 USD. Mark is still committed to the previously-agreed 400:100 exchange rate, so Mark ends up losing out on $50 USD worth of value he could've gained by not trading his XRP. Mark has to choose his exchange rates and expiration times to offset and minimize the chance of losing out like that all day long.
    If banks use XRP as a reserve and vehicle currency, they can minimize their exchange costs (consolidating many accounts in different places to just one XRP reserve) but that does mean they take on the volatility risk instead.
  15. LaBelleSaison liked a post in a topic by mDuo13 in Transaction Volatility and FI's   
    The more usage it gets, the lower the volatility should be.
    Also, compared to Bitcoin, XRP settles so fast that you're not exposed to the volatility risk nearly as much.
    That said, it's certainly a concern. If you look at our math on using XRP for currency conversion, we outline a "high-volatility" scenario where XRP is about 2.5× as volatile as the fiat currencies. The nice thing is that you save so much on other costs that it's still cheaper in total to go through XRP.
  16. Dizer liked a post in a topic by mDuo13 in Transaction Volatility and FI's   
    If the payment uses ILP and goes Fiat→XRP→Fiat, then the institutions on the sending and receiving side aren't exposed to any volatility risk in XRP exchange rates, but the trader/liquidity provider is the one exposed to the currency risk. For example, liquidity provider Mark agrees to an ILP quote and lock up 400 XRP in exchange for 100 USD. During the time before this ILP quote expires, the price of XRP suddenly skyrockets and that 400 XRP is now worth over 150 USD. Mark is still committed to the previously-agreed 400:100 exchange rate, so Mark ends up losing out on $50 USD worth of value he could've gained by not trading his XRP. Mark has to choose his exchange rates and expiration times to offset and minimize the chance of losing out like that all day long.
    If banks use XRP as a reserve and vehicle currency, they can minimize their exchange costs (consolidating many accounts in different places to just one XRP reserve) but that does mean they take on the volatility risk instead.
  17. bickelaer liked a post in a topic by mDuo13 in Hacking XRP   
    If you were thinking of brute-forcing XRP secrets, I highly recommend you put that effort into studying public key cryptography. Not only do you have a higher chance of cracking someone's secret key before you die of old age, you're also far more likely to develop useful skills that can earn you a lof of XRP in actual legal income.
    Yes, it's entirely possible that someone may invent a new algorithm that makes it far easier to decipher private keys from public signatures. (If they do, no money is safe.) Brute-force ain't gonna get you there, though.
  18. Dizer liked a post in a topic by mDuo13 in Transaction Volatility and FI's   
    If the payment uses ILP and goes Fiat→XRP→Fiat, then the institutions on the sending and receiving side aren't exposed to any volatility risk in XRP exchange rates, but the trader/liquidity provider is the one exposed to the currency risk. For example, liquidity provider Mark agrees to an ILP quote and lock up 400 XRP in exchange for 100 USD. During the time before this ILP quote expires, the price of XRP suddenly skyrockets and that 400 XRP is now worth over 150 USD. Mark is still committed to the previously-agreed 400:100 exchange rate, so Mark ends up losing out on $50 USD worth of value he could've gained by not trading his XRP. Mark has to choose his exchange rates and expiration times to offset and minimize the chance of losing out like that all day long.
    If banks use XRP as a reserve and vehicle currency, they can minimize their exchange costs (consolidating many accounts in different places to just one XRP reserve) but that does mean they take on the volatility risk instead.
  19. Dizer liked a post in a topic by mDuo13 in Transaction Volatility and FI's   
    If the payment uses ILP and goes Fiat→XRP→Fiat, then the institutions on the sending and receiving side aren't exposed to any volatility risk in XRP exchange rates, but the trader/liquidity provider is the one exposed to the currency risk. For example, liquidity provider Mark agrees to an ILP quote and lock up 400 XRP in exchange for 100 USD. During the time before this ILP quote expires, the price of XRP suddenly skyrockets and that 400 XRP is now worth over 150 USD. Mark is still committed to the previously-agreed 400:100 exchange rate, so Mark ends up losing out on $50 USD worth of value he could've gained by not trading his XRP. Mark has to choose his exchange rates and expiration times to offset and minimize the chance of losing out like that all day long.
    If banks use XRP as a reserve and vehicle currency, they can minimize their exchange costs (consolidating many accounts in different places to just one XRP reserve) but that does mean they take on the volatility risk instead.
  20. Dizer liked a post in a topic by mDuo13 in Transaction Volatility and FI's   
    If the payment uses ILP and goes Fiat→XRP→Fiat, then the institutions on the sending and receiving side aren't exposed to any volatility risk in XRP exchange rates, but the trader/liquidity provider is the one exposed to the currency risk. For example, liquidity provider Mark agrees to an ILP quote and lock up 400 XRP in exchange for 100 USD. During the time before this ILP quote expires, the price of XRP suddenly skyrockets and that 400 XRP is now worth over 150 USD. Mark is still committed to the previously-agreed 400:100 exchange rate, so Mark ends up losing out on $50 USD worth of value he could've gained by not trading his XRP. Mark has to choose his exchange rates and expiration times to offset and minimize the chance of losing out like that all day long.
    If banks use XRP as a reserve and vehicle currency, they can minimize their exchange costs (consolidating many accounts in different places to just one XRP reserve) but that does mean they take on the volatility risk instead.
  21. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  22. Dizer liked a post in a topic by mDuo13 in Transaction Volatility and FI's   
    If the payment uses ILP and goes Fiat→XRP→Fiat, then the institutions on the sending and receiving side aren't exposed to any volatility risk in XRP exchange rates, but the trader/liquidity provider is the one exposed to the currency risk. For example, liquidity provider Mark agrees to an ILP quote and lock up 400 XRP in exchange for 100 USD. During the time before this ILP quote expires, the price of XRP suddenly skyrockets and that 400 XRP is now worth over 150 USD. Mark is still committed to the previously-agreed 400:100 exchange rate, so Mark ends up losing out on $50 USD worth of value he could've gained by not trading his XRP. Mark has to choose his exchange rates and expiration times to offset and minimize the chance of losing out like that all day long.
    If banks use XRP as a reserve and vehicle currency, they can minimize their exchange costs (consolidating many accounts in different places to just one XRP reserve) but that does mean they take on the volatility risk instead.
  23. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  24. Kakoyla liked a post in a topic by mDuo13 in Where is the code that guarantees the maximum amount of XRP?   
    Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of.
    The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570.
    Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  25. Dizer liked a post in a topic by mDuo13 in Transaction Volatility and FI's   
    If the payment uses ILP and goes Fiat→XRP→Fiat, then the institutions on the sending and receiving side aren't exposed to any volatility risk in XRP exchange rates, but the trader/liquidity provider is the one exposed to the currency risk. For example, liquidity provider Mark agrees to an ILP quote and lock up 400 XRP in exchange for 100 USD. During the time before this ILP quote expires, the price of XRP suddenly skyrockets and that 400 XRP is now worth over 150 USD. Mark is still committed to the previously-agreed 400:100 exchange rate, so Mark ends up losing out on $50 USD worth of value he could've gained by not trading his XRP. Mark has to choose his exchange rates and expiration times to offset and minimize the chance of losing out like that all day long.
    If banks use XRP as a reserve and vehicle currency, they can minimize their exchange costs (consolidating many accounts in different places to just one XRP reserve) but that does mean they take on the volatility risk instead.