mDuo13

Ripple Employee
  • Content count

    195
  • Joined

  • Last visited

  • Days Won

    18

Reputation Activity

  1. Twarden liked a post in a topic by mDuo13 in Gatehub/PBG XAU IOU   
    This is a good point. And, I think, this situation is what the Trust Line Quality feature was meant to address. Unfortunately, Trust Line Quality is hard to use. For now, the simple recommendations I have are:
    - Don't trade XAU.Gatehub and XAU from another (ISO-compliant) gateway using the same address
    - If you do trade XAU.Gatehub and XAU from another gateway using the same address, be absolutely sure that NoRipple is enabled on all your XAU trust lines.
  2. mDuo13 liked a post in a topic by cmbartley in Chatline of the day   
    Ripple is not a disappointment, it's a shining star in this space. The price of XRP has been a disappointment. We'll see if that changes.
  3. Xi195 liked a post in a topic by mDuo13 in SusPay was vetoed   
    The status "vetoed" in that output just means your validator is not vetoing it. It doesn't say there, but Ripple's are.
    To be explicit, "veto" in this context means "not voting for it and thus de facto voting against it." An amendment can never be "permanently vetoed" but it can be removed from future versions of the software, which makes it very unlikely to pass. (People could either run the old versions of the software or explicitly configure their validators to vote in favor of an amendment the software doesn't know -- but that's about it.)
     
    Oh, I should mention, yes, Escrow is just a consolidation of SusPay and CryptoConditions. We might change the names of a few things (e.g. SuspendedPaymentCreate might get renamed to EscrowCreate; that's TBD) but otherwise it'll be the same.
  4. mDuo13 liked a post in a topic by T8493 in Encryption vs Quantum Computing   
    Ed25519 won't necessarily help you in this case:
    Ed25519 uses one specific elliptic curve and the length of its keys is fixed (you cannot choose longer keys as you can with e.g. ECDSA or EdDSA in general). If ECDLP can be solved quickly (on relatively general curves), then maybe both ECDSA and Ed25519 can be considered broken (the same attack on ECDLP could break both Ed25519 and ECDSA). Regarding P=NP.
    If P=NP, this doesn't automatically imply that the current cryptography is practically broken. If someone finds the polynomial algorithm with the running time O(n^10000) for some NP-complete problem (e.g. SAT), then this algorithm is pretty much useless for all practical purposes. 
    Integer factorization is not known to be a NP complete problem, but the cryptographic algorithms still rely on it.....
     
     
     
  5. xtrapower liked a post in a topic by mDuo13 in Encryption vs Quantum Computing   
    Until computer scientists solve the question of whether P=NP, cryptography will be a field relying on guesswork: "This operation is easy, but we think the reverse is very hard, so nobody can figure this out in a reasonable amount of time unless they figure out an easy way to do the hard reverse operation." There are some questions that we've proven can be solved "easily" with quantum computers, and others that are more uncertain.
    My understanding is that SHA-256 and SHA-512, the hash functions at the core of Bitcoin and Ripple, very well might remain secure even after quantum computers are commonplace. Then again, unexpected advances in math could break these hash functions without even relying on quantum computers.
    ECDSA is an elliptic-curve signature system; it may or may not be broken by practical quantum computers, but it's more likely to survive than RSA and other signing systems based on prime numbers.
    Ripple uses ECDSA by default for a lot of functionality, but already has support for Ed25519, which is a more recent signing scheme that is generally considered to be better than ECDSA for a few reasons (runs much faster and branches less, which makes it harder to mess up implementing, etc.). Users who don't trust that ECDSA won't be secure enough for them can switch to Ed25519 keys already without even changing their main address. So Ripple already has the infrastructure to add more signing schemes and let users migrate to the new key/signing types. Adding more would be a relatively simple update. (We probably wouldn't disable old signing schemes because that would take away the only means of accessing accounts that are only authorized by the "outdated" key types.)
    Transaction fees won't help - the cracking for this kind of thing would occur offline. You would just copy-paste the address/public key you want to generate, then run a bunch of calculations to try and figure out what it is. Nobody else would know you were even trying.
     
  6. xtrapower liked a post in a topic by mDuo13 in Encryption vs Quantum Computing   
    Until computer scientists solve the question of whether P=NP, cryptography will be a field relying on guesswork: "This operation is easy, but we think the reverse is very hard, so nobody can figure this out in a reasonable amount of time unless they figure out an easy way to do the hard reverse operation." There are some questions that we've proven can be solved "easily" with quantum computers, and others that are more uncertain.
    My understanding is that SHA-256 and SHA-512, the hash functions at the core of Bitcoin and Ripple, very well might remain secure even after quantum computers are commonplace. Then again, unexpected advances in math could break these hash functions without even relying on quantum computers.
    ECDSA is an elliptic-curve signature system; it may or may not be broken by practical quantum computers, but it's more likely to survive than RSA and other signing systems based on prime numbers.
    Ripple uses ECDSA by default for a lot of functionality, but already has support for Ed25519, which is a more recent signing scheme that is generally considered to be better than ECDSA for a few reasons (runs much faster and branches less, which makes it harder to mess up implementing, etc.). Users who don't trust that ECDSA won't be secure enough for them can switch to Ed25519 keys already without even changing their main address. So Ripple already has the infrastructure to add more signing schemes and let users migrate to the new key/signing types. Adding more would be a relatively simple update. (We probably wouldn't disable old signing schemes because that would take away the only means of accessing accounts that are only authorized by the "outdated" key types.)
    Transaction fees won't help - the cracking for this kind of thing would occur offline. You would just copy-paste the address/public key you want to generate, then run a bunch of calculations to try and figure out what it is. Nobody else would know you were even trying.
     
  7. Xi195 liked a post in a topic by mDuo13 in SusPay was vetoed   
    The status "vetoed" in that output just means your validator is not vetoing it. It doesn't say there, but Ripple's are.
    To be explicit, "veto" in this context means "not voting for it and thus de facto voting against it." An amendment can never be "permanently vetoed" but it can be removed from future versions of the software, which makes it very unlikely to pass. (People could either run the old versions of the software or explicitly configure their validators to vote in favor of an amendment the software doesn't know -- but that's about it.)
     
    Oh, I should mention, yes, Escrow is just a consolidation of SusPay and CryptoConditions. We might change the names of a few things (e.g. SuspendedPaymentCreate might get renamed to EscrowCreate; that's TBD) but otherwise it'll be the same.
  8. xtrapower liked a post in a topic by mDuo13 in Encryption vs Quantum Computing   
    Until computer scientists solve the question of whether P=NP, cryptography will be a field relying on guesswork: "This operation is easy, but we think the reverse is very hard, so nobody can figure this out in a reasonable amount of time unless they figure out an easy way to do the hard reverse operation." There are some questions that we've proven can be solved "easily" with quantum computers, and others that are more uncertain.
    My understanding is that SHA-256 and SHA-512, the hash functions at the core of Bitcoin and Ripple, very well might remain secure even after quantum computers are commonplace. Then again, unexpected advances in math could break these hash functions without even relying on quantum computers.
    ECDSA is an elliptic-curve signature system; it may or may not be broken by practical quantum computers, but it's more likely to survive than RSA and other signing systems based on prime numbers.
    Ripple uses ECDSA by default for a lot of functionality, but already has support for Ed25519, which is a more recent signing scheme that is generally considered to be better than ECDSA for a few reasons (runs much faster and branches less, which makes it harder to mess up implementing, etc.). Users who don't trust that ECDSA won't be secure enough for them can switch to Ed25519 keys already without even changing their main address. So Ripple already has the infrastructure to add more signing schemes and let users migrate to the new key/signing types. Adding more would be a relatively simple update. (We probably wouldn't disable old signing schemes because that would take away the only means of accessing accounts that are only authorized by the "outdated" key types.)
    Transaction fees won't help - the cracking for this kind of thing would occur offline. You would just copy-paste the address/public key you want to generate, then run a bunch of calculations to try and figure out what it is. Nobody else would know you were even trying.
     
  9. Xi195 liked a post in a topic by mDuo13 in SusPay was vetoed   
    The status "vetoed" in that output just means your validator is not vetoing it. It doesn't say there, but Ripple's are.
    To be explicit, "veto" in this context means "not voting for it and thus de facto voting against it." An amendment can never be "permanently vetoed" but it can be removed from future versions of the software, which makes it very unlikely to pass. (People could either run the old versions of the software or explicitly configure their validators to vote in favor of an amendment the software doesn't know -- but that's about it.)
     
    Oh, I should mention, yes, Escrow is just a consolidation of SusPay and CryptoConditions. We might change the names of a few things (e.g. SuspendedPaymentCreate might get renamed to EscrowCreate; that's TBD) but otherwise it'll be the same.
  10. xtrapower liked a post in a topic by mDuo13 in Encryption vs Quantum Computing   
    Until computer scientists solve the question of whether P=NP, cryptography will be a field relying on guesswork: "This operation is easy, but we think the reverse is very hard, so nobody can figure this out in a reasonable amount of time unless they figure out an easy way to do the hard reverse operation." There are some questions that we've proven can be solved "easily" with quantum computers, and others that are more uncertain.
    My understanding is that SHA-256 and SHA-512, the hash functions at the core of Bitcoin and Ripple, very well might remain secure even after quantum computers are commonplace. Then again, unexpected advances in math could break these hash functions without even relying on quantum computers.
    ECDSA is an elliptic-curve signature system; it may or may not be broken by practical quantum computers, but it's more likely to survive than RSA and other signing systems based on prime numbers.
    Ripple uses ECDSA by default for a lot of functionality, but already has support for Ed25519, which is a more recent signing scheme that is generally considered to be better than ECDSA for a few reasons (runs much faster and branches less, which makes it harder to mess up implementing, etc.). Users who don't trust that ECDSA won't be secure enough for them can switch to Ed25519 keys already without even changing their main address. So Ripple already has the infrastructure to add more signing schemes and let users migrate to the new key/signing types. Adding more would be a relatively simple update. (We probably wouldn't disable old signing schemes because that would take away the only means of accessing accounts that are only authorized by the "outdated" key types.)
    Transaction fees won't help - the cracking for this kind of thing would occur offline. You would just copy-paste the address/public key you want to generate, then run a bunch of calculations to try and figure out what it is. Nobody else would know you were even trying.
     
  11. xtrapower liked a post in a topic by mDuo13 in Encryption vs Quantum Computing   
    Until computer scientists solve the question of whether P=NP, cryptography will be a field relying on guesswork: "This operation is easy, but we think the reverse is very hard, so nobody can figure this out in a reasonable amount of time unless they figure out an easy way to do the hard reverse operation." There are some questions that we've proven can be solved "easily" with quantum computers, and others that are more uncertain.
    My understanding is that SHA-256 and SHA-512, the hash functions at the core of Bitcoin and Ripple, very well might remain secure even after quantum computers are commonplace. Then again, unexpected advances in math could break these hash functions without even relying on quantum computers.
    ECDSA is an elliptic-curve signature system; it may or may not be broken by practical quantum computers, but it's more likely to survive than RSA and other signing systems based on prime numbers.
    Ripple uses ECDSA by default for a lot of functionality, but already has support for Ed25519, which is a more recent signing scheme that is generally considered to be better than ECDSA for a few reasons (runs much faster and branches less, which makes it harder to mess up implementing, etc.). Users who don't trust that ECDSA won't be secure enough for them can switch to Ed25519 keys already without even changing their main address. So Ripple already has the infrastructure to add more signing schemes and let users migrate to the new key/signing types. Adding more would be a relatively simple update. (We probably wouldn't disable old signing schemes because that would take away the only means of accessing accounts that are only authorized by the "outdated" key types.)
    Transaction fees won't help - the cracking for this kind of thing would occur offline. You would just copy-paste the address/public key you want to generate, then run a bunch of calculations to try and figure out what it is. Nobody else would know you were even trying.
     
  12. Xi195 liked a post in a topic by mDuo13 in SusPay was vetoed   
    The status "vetoed" in that output just means your validator is not vetoing it. It doesn't say there, but Ripple's are.
    To be explicit, "veto" in this context means "not voting for it and thus de facto voting against it." An amendment can never be "permanently vetoed" but it can be removed from future versions of the software, which makes it very unlikely to pass. (People could either run the old versions of the software or explicitly configure their validators to vote in favor of an amendment the software doesn't know -- but that's about it.)
     
    Oh, I should mention, yes, Escrow is just a consolidation of SusPay and CryptoConditions. We might change the names of a few things (e.g. SuspendedPaymentCreate might get renamed to EscrowCreate; that's TBD) but otherwise it'll be the same.
  13. Xi195 liked a post in a topic by mDuo13 in SusPay was vetoed   
    The status "vetoed" in that output just means your validator is not vetoing it. It doesn't say there, but Ripple's are.
    To be explicit, "veto" in this context means "not voting for it and thus de facto voting against it." An amendment can never be "permanently vetoed" but it can be removed from future versions of the software, which makes it very unlikely to pass. (People could either run the old versions of the software or explicitly configure their validators to vote in favor of an amendment the software doesn't know -- but that's about it.)
     
    Oh, I should mention, yes, Escrow is just a consolidation of SusPay and CryptoConditions. We might change the names of a few things (e.g. SuspendedPaymentCreate might get renamed to EscrowCreate; that's TBD) but otherwise it'll be the same.
  14. Xi195 liked a post in a topic by mDuo13 in SusPay was vetoed   
    The status "vetoed" in that output just means your validator is not vetoing it. It doesn't say there, but Ripple's are.
    To be explicit, "veto" in this context means "not voting for it and thus de facto voting against it." An amendment can never be "permanently vetoed" but it can be removed from future versions of the software, which makes it very unlikely to pass. (People could either run the old versions of the software or explicitly configure their validators to vote in favor of an amendment the software doesn't know -- but that's about it.)
     
    Oh, I should mention, yes, Escrow is just a consolidation of SusPay and CryptoConditions. We might change the names of a few things (e.g. SuspendedPaymentCreate might get renamed to EscrowCreate; that's TBD) but otherwise it'll be the same.
  15. Xi195 liked a post in a topic by mDuo13 in SusPay was vetoed   
    The status "vetoed" in that output just means your validator is not vetoing it. It doesn't say there, but Ripple's are.
    To be explicit, "veto" in this context means "not voting for it and thus de facto voting against it." An amendment can never be "permanently vetoed" but it can be removed from future versions of the software, which makes it very unlikely to pass. (People could either run the old versions of the software or explicitly configure their validators to vote in favor of an amendment the software doesn't know -- but that's about it.)
     
    Oh, I should mention, yes, Escrow is just a consolidation of SusPay and CryptoConditions. We might change the names of a few things (e.g. SuspendedPaymentCreate might get renamed to EscrowCreate; that's TBD) but otherwise it'll be the same.
  16. ElMoskito liked a post in a topic by mDuo13 in Example of code for pseudo circular payments   
    There's also the RippleAPI Beginners Guide, which has some working code samples of accessing the network. It doesn't have anything specific to do with circular payments, but the "pseudo-circular" payments are just regular payments with specific pathsets provided. (To be honest, I'm not sure exactly what Donovan is doing to find and consume these paths in a circular fashion; he's one of the more advanced RCL developers out there so he may be doing some fairly non-standard and complex stuff.)
  17. jn_r liked a post in a topic by mDuo13 in List of possible NBAD Ripple accounts   
    P.S. check out the byline in https://ripple.com/build/ripple-ledger-consensus-process/ (an article which has been up for years)
  18. rippleric liked a post in a topic by mDuo13 in A Big Update!   
    it's literally my job
  19. R8102V1D2D liked a post in a topic by mDuo13 in A Big Update!   
    With the Ripple Solution we're selling, it chooses a trusted notary automatically according to some simple rules. The protocol itself is indifferent to how you make your decision as long as you choose.
  20. Ashishkel liked a post in a topic by mDuo13 in A Big Update!   
    @rippleric: I think we'll have to see in real life if RCL is more useful in atomic or universal mode transactions, but I think universal makes sense.
    To use Atomic Mode, everyone involved in the atomic-mode transaction has to agree on a set of ILP Notaries (also called ILP Validators, since they serve a kind of similar role to rippled validators) to approve and coordinate the transactions. The notaries can be picked differently for each transaction, if desired, so you don't have to continue to agree on the same notaries in the long term, but you do need to agree for the one transaction.
    In Universal Mode, payments can fail, but the system has incentives designed so that the connectors are the ones who take the loss, and generally only if one of the ledgers they're using fails. Connectors can price the risk of failure into their rates across ledgers, so everyone still ends up ahead in the long run. (At least, that's how it's supposed to work. Doubtless someone will make a mistake somewhere and end up losing lots of money at some point. That's pretty much inevitable with any new financial system. We're pretty confident there are no exploits in the protocol itself.)
    There's also Optimistic Mode, which just assumes that payments will succeed. It's, uh, actually useful in some special cases?
    Since the RCL is already decentralized, redundant, and has long-term validators, it provides very reliable operation. In Universal Mode, that's a valuable quality for a ledger to have (and fast settlement time is another nice bonus). So I think RCL will be a pretty good intermediary in Universal-mode transactions, especially in ones connecting to obscure corridors or sources of value.
    It might be worth breaking down this diagram a little more:

    You all have heard of Ripple Connect before, but this is the new version of Ripple Connect that uses the Interledger Protocol (in Atomic Mode) directly. The "ILP Ledger" in this case is an ILP-enabled sub-ledger we package with the Ripple Solution. Each bank runs their own ILP (sub-)Ledger to hold funds that can be transferred to other banks atomically through the Interledger Protocol. Ripple Connect handles the messaging and coordinates the transfers from the bank's core ledger to the ILP-enabled sub-ledger. Then the ILP payment from one bank's sub-ledger to the other bank's sub-ledger happens automatically (and atomically!), using one or more ILP-enabled liquidity providers (aka Connectors) and the other bank's Ripple Connect takes it from there to go from the ILP sub-ledger to the beneficiary bank's core ledger. The ILP Validator (also known as an ILP Notary) can be a single Notary run by either bank or a third party, or it can be an ad-hoc consensus group of Notaries. (So far, we're only using one validator per transaction.)
    For the first version of this whole system, we're having the Liquidity Provider also be run by one of the banks, which is what big banks usually do anyway. Eventually the liquidity provider could be chosen from an approved set of liquidity providers based on the best rate available. I think it should be a pretty painless upgrade to using a network of them, or to switch one liquidity provider for another.
    At no point in this process do the banks need to use the RCL, but it's entirely possible that the liquidity provider can use XRP behind the scenes to reduce exchange rates. I can't promise when we'll have more to say about that, but I'm pretty sure we'll have more to say at some point.
  21. jn_r liked a post in a topic by mDuo13 in List of possible NBAD Ripple accounts   
    I can't promise that NBAD's accounts are set up this way (I honestly don't know for sure), but Ripple's recommendation for RCL setups as described in the Gateway Guide, does not include any "mutual trust" relationships. The issuing address (aka cold wallet) trusts no one; the operational addresses (aka hot wallets), and standby addresses (warm wallets) all trust the issuing address. For cross-currency situations, the authorized liquidity provider accounts trust one issuing address for each currency.
  22. mDuo13 liked a post in a topic by Roborovskii in B4 you give up on Ripple or XRP ask urself the Question...   
    Several years ago... but you only just started this account in Dec 2016 (a month ago), which coincides with the influx of FUD in the forum. There has been much FUD introduced lately, and many from new account like yours. I can understand the negativity coming from familiar old names, and from those, their concerns are backed up and rational. Yours is purely ungrounded FUD.

    From my perspective, the influx is purely from short-term (short sighted) specs, or from polo fear mongers (or "bitcoiners") trying to suppress the positive development at Ripple. These people use price as their basis, not fundamentals. They probably lack the mental capacity to understand the fundamentals in the first place. Their motives are fuelled by jealously and fear. Too much has been invested in BTC.

    Comparing XRP's price performance to other crypto coins is redundant. While most cryptos can be pumped (and have likely been), XRP having a large % holding by Ripple guards against pumps. Many see that % holding as negative, I see it as a protection against the pumpers in crypto land providing stability to the price. Fear mongering that Ripple could dump XRP into the market is also unfounded. The very fiat currency that you own can also be printed to infinity; wouldn't you also be afraid that your govt would do that? I guess not. It's the faith in the country or govt that keeps the value of fiat currency afloat; and like-wise for XRP, the all star team that is behind it.

    Many XRP holders who have mostly been quiet don't follow the daily or weekly fluctuations. That is why they don't post. We put what we can afford for the longer term and know the risks involved. I have not posted much at length in the recent months, and even made jokes about the price performance in 2016; but the FUD here is getting out of hand. Long term holders know the fundamentals and ignore the short-term FUD. Yes the price is still low. Isn't it a good thing then for you? What's the downside? And how much upside is there? Look at the fundamentals.
  23. jn_r liked a post in a topic by mDuo13 in List of possible NBAD Ripple accounts   
    I can't promise that NBAD's accounts are set up this way (I honestly don't know for sure), but Ripple's recommendation for RCL setups as described in the Gateway Guide, does not include any "mutual trust" relationships. The issuing address (aka cold wallet) trusts no one; the operational addresses (aka hot wallets), and standby addresses (warm wallets) all trust the issuing address. For cross-currency situations, the authorized liquidity provider accounts trust one issuing address for each currency.
  24. mDuo13 liked a post in a topic by RafOlP in List of possible NBAD Ripple accounts   
    I find it really amazing that they are using RCL and giving out public info about their implementation.
  25. MikeF liked a post in a topic by mDuo13 in rippled 0.50.0 released   
    https://ripple.com/dev-blog/rippled-0-50-0/
    And we're planning on voting for TickSize and SusPay so that both get enabled on Feb 21.