mDuo13

Ripple Employee
  • Content count

    193
  • Joined

  • Last visited

  • Days Won

    18

mDuo13 last won the day on January 27

mDuo13 had the most liked content!

About mDuo13

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. 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.
  2. 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.
  3. If it's anything like the five-bells-ledger, you might need to manually set the "minimum_allowed_balance" to "-infinity" (or some other very-negative number) on the admin account. I haven't used ilp-kit yet though.
  4. This is a doc issue. See https://github.com/ripple/rippled-historical-database/issues/132 for the follow-up. Basically there's a new step necessary to set up the tables but the installation instructions haven't been updated yet.
  5. 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.)
  6. P.S. check out the byline in https://ripple.com/build/ripple-ledger-consensus-process/ (an article which has been up for years)
  7. 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.
  8. Payment Channels (PayChan) is in a good state and Ripple plans to enable it very soon. The hard engine work is done; we're just working out the client support (RippleAPI support in particular) before we go enabling it. SusPay already has client library support so it'll be coming sooner. As mentioned in the rippled 0.50.0 announcement, Ripple's validators are gonna start voting in favor of SusPay and TickSize with the expectation they'll get turned on Feb. 21. We also hope to turn on CryptoConditions (an upgrade to SusPay that provides compatibility with Interledger Protocol's Crypto-Conditions) before the end of March. I think you miiiiight be confusing the transaction cost (XRP) with transfer fees (issuances only). See Fees (Disambiguation) for a refresher if that's confusing. The OwnerPaysFee amendment doesn't do anything to XRP or the transaction cost. It just makes it so that transfer fees—the % fees set by issuers that apply when transferring issuances to different addresses—are paid by the owner of the asset regardless of whether a Payment or OfferCreate consumes the offer. (Currently transfer fees are included in a Payment's overall cost, so the Payment sender has to cover them with their SendMax value. The person placing the original offer pays the fee if it gets consumed by an OfferCreate but not if it gets consumed by a Payment transaction. We want to make it more consistent and have person placing the original offer always pay the transfer fee, if there is one.) No matter what, the person sending a transaction is the one who has to pay the XRP transaction cost. You can't fund a new address using a Payment Channel; the receiving address has to already be funded when the channel is created. Tickets are a feature we thought up a long time ago when we first started designing multi-sign. The plan was, a Ticket is a transaction that consumes a sequence number as a placeholder, without doing anything else. Later on, you can submit a transaction that reuses the Ticket's sequence number, consuming the ticket. That way, you can do stuff like, start collecting signatures for a big multi-signed transaction but you can still submit other transactions successfully in the meantime. (One workaround for now is you can use a higher sequence number for the multi-signed tx and send any "normal" transactions using the in-between sequence numbers while you're waiting for all the signatures to be ready. Then when you're ready you can send no-op transactions for any remaining in-between sequence numbers. Another workaround is to just use a different address for hard-to-collect multi-signed transactions than for one where you want to submit lots of transactions with a short turnaround time.) As with anything that messes with sequence numbers and transaction processing, it's important to get it perfect so there's nothing to exploit. Perhaps more importantly, this use case is hypothetical and rare enough that it's a lower priority than other amendments right now.
  9. Completely personal opinion here, but I also don't think that researching activity on a public ledger should be considered doxxing. One of the things that excites me most about the Ripple Consensus Ledger is that it's a public ledger so this stuff is possible. Obviously it's just guesswork until someone confirms things officially. But I'm sure NBAD went public knowing full well that this is possible. It does get kind of bad if people start making lots of decisions based on loose speculation, affecting the price of XRP based on fictions or actually prying into the private lives of Ripple employees or whoever based on stuff you can't confirm. (For a comparison, don't be like that journalist who outed a bunch of Olympic athletes by going on Grindr in Rio. That was a tasteless and needlessly hurtful thing to do.) But, by all means, if you can figure out which accounts are which and figure out what settings they're using, feel free. Again, all the statements in this post are my personal opinions. They are not official Ripple policy.
  10. To clarify, ~XRP-II isn't strictly related to Jed. "XRP II, Inc" is Ripple's wholly-owned subsidiary that exists solely for legal XRP sales. I'm not a lawyer, so I don't know the details, but I know this makes it easier to be in compliance with U.S. law. As for this trade, I've got nothing I can say on the matter (I'm personally about as in the dark as the rest of you. I do know that Brad G. was recently in Japan and did some interviews with Japanese media, so maybe you'll hear more about SBI soon. That could easily be a coincidence with this transaction/transfer/whatever-it-is though.)
  11. It's 10 "significant digits", not overall digits. As I understand it, the qualities are represented by a mantissa and an exponent (think scientific notation) so the XRP:BTC price can be represented as 6.44×10^(-12), only using 3 significant digits. By default, rippled supports 15 significant digits, so it actually makes a distinction between 0.00000000000644 and 0.00000000000644000000001. If you set the TickSize to 10, then those two would be considered equivalent.
  12. 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.
  13. Not every rippled server has or should have a public-facing API. (In fact, we recommend that validators don't.) Some organizations, like Ripple, run a public-facing API as a public service, but that's not really necessary for the network to function. Basically the worst you can do is to bombard all the public servers. It would be like hiring people to line up and clog all the public bathrooms in a city. Sucks for people who need to use the bathroom in the public, but it's a nonissue if you have a bathroom in your home/office.
  14. Is it legal? Yes, of course. Is it good manners? Certainly not. I think it's something like banging your fist on shatterproof glass just to test that it's shatterproof. You probably won't break it, but the people nearby still won't be happy that you're going around banging on their windows. P.S. if you really insist on testing the stability of the network, you should try spamming the testnet first, and publish the schedule of your "attack" in advance. That's at least closer to good manners.
  15. I don't know for sure, but my understanding is that rippled caches a small number of transactions that failed with retriable errors (ter* codes) to be reused later. I suspect it's a fixed-size cache so rippled just drops them freely if the cache fills up, according to some simple heuristic like keeping the most recent ones. And of course it doesn't relay the transactions to the network while they're being held in the cache, but it does relay them if they succeed on the retry. So the worst you can do is force other people's temporarily-failed transactions to get dropped from the cache, which is at most a minor inconvenience, and it only affects people using the same rippled server as you. So either you deal with this possibly happening on a shared server, or you run your own rippled and don't have this problem anymore. The reason this feature exists is to make transaction submission easier for pretty much exactly the case you encountered, except also including the version where constructing and submitting the transactions is done by some automated system instead of by hand. Maybe you have some system that wants to create several transactions from a specific address, and something gets shuffled around so several transactions get submitted out of order but right after one another. (Maybe the http connection for one of them randomly drops and reconnects; maybe you construct the transactions in parallel and one of the earlier ones takes longer -- it doesn't really matter.) If you're running your own rippled server, you don't have to worry about the exact order since it should "just work" if you submit them around the same time.