Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by mDuo13

  1. Make sure you're upgraded to 0.50.2 if you're using WSS. Version 0.50.0 has a bug with wss connections. Otherwise I don't see anything obviously wrong with your code, so I'm not sure.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. This is a doc issue. See 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.
  7. 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.)
  8. P.S. check out the byline in (an article which has been up for years)
  9. 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.
  10. 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.
  11. 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.
  12. 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.)
  13. And we're planning on voting for TickSize and SusPay so that both get enabled on Feb 21.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. Ripple doesn't peg the price of XRP to anything and we don't try to manipulate the price (other than attempting to increase the long-term value of the currency). Frequently we're as surprised by daily currency movements as the general public is.
  19. There hasn't been anything published on this recently. (I've been too busy on ILP-related stuff to do much more than tread water on new RCL featuers, not getting to the backlog of complicated RCL concepts that have been around a while.) But one thing that might help you with the understanding is that there are two things called "quality" in the RCL: Offer quality is basically just the rate of exchange, used to rank orders for the same currency pair. It's literally just TakerPays divided by TakerGets. This is what tick size limits. Trust line quality, aka "quality in/out", lets you personally value issuances at more or less than face value, which is mostly useful if you allow rippling, but the math on it gets confusing very quickly. There's not much client support for trust line quality (Ripple Trade never supported it) and the documentation for it sucks because I still can't keep them straight in my head no matter how many times I ask @JoelKatz to refresh my memory. In all likelihood, the docs for trust line quality will continue to be extremely low on the priority list because trust line quality is kind of a perfect storm of unimportant: it relates to issued currencies and rippling, both of which we think are less and less important in the post-ILP RCL, and it's not widely used or understood so there's no demand for it.
  20. It's not constraining the digits of the amounts, it's constraining the digits of the "quality" aka the ratio between the prices of the two currencies to be traded. If I offer to sell 100 EUR.SomeGateway for 1000 XRP, that's a quality of 0.1 in the XRP:EUR.SomeGateway market. If David offers to sell 3.333333 EUR for 33.3333 XRP, that's still a quality of 0.1 even though the absolute amounts have different significant digits. If his offer comes after mine, it gets placed below mine. If Nik offers to sell 100.00001 EUR.SomeGateway for 1000 XRP, that's a quality of 0.10000001 in the same market. Since Nik's offer is of higher quality, it's ranked above David's and mine even if our offers were on the books first. The problem is, even though Nik's offer is technically better, the amount you get if you consume part of Nik's offer is essentially the same because that extra few fragments of a cent isn't likely to add up to anything that can be redeemed for real value. So basically Nik got to cut in the line by offering nothing of value. Then if Nik's order-sniping bot and someone else's start fighting over the top of the XRP:EUR.SomeGateway market, they can go back and forth for quite a while, placing bids that are microscopically better than each other without ever adding up to being better enough that any real person would care which offer they took. This occupies a bunch of disk space (all transactions are in the history forever!) and means processing a bunch of transactions that aren't valuable. Even though Ripple can handle that traffic (as it does today!), it's wasteful to conduct business that way. Enter tick sizes. If EUR.SomeGateway sets their tick size to 3, then Nik's offer is rounded down to 0.100 quality, same as mine and David's, which means Nik's offer gets placed after ours. If he wants to actually claim first place in the order-book line, he's going to have to outbid us by an amount that's at least sort of significant. If he's content with the price where it is, he can let his offer sit in line. It's not solving a really big problem, but it does make life easier for traders and network nodes.
  21. T8493 is correct -- transaction ordering is still deterministic (it has to be!) but is now harder to game. Basically the rule for how transactions from different addresses are ordered is now dependent on the contents or hash of the ledger itself (I don't remember exactly what) instead of being mostly based on alphabetizing the transaction hashes. Regarding signing with a different k, my understanding is that rippled does not pay any specific attention to that. It only checks that the signature is valid for the transaction fields. However, I think the identifying hash is calculated for the transaction including the signature so it's not considered the exact same transaction unless the signature is identical. If you change the signature, the resubmitted version is "competing" with the first submission to be included in a ledger because they have the same sequence number. That's probably fine because the main reason you'd resubmit a transaction without changing anything else is that it just didn't get distributed to enough servers because of some sort of temporary condition (e.g. your connection dropped while you were sharing it with the first rippled). If you're changing anything else about the transaction, like its LastLedgerSequence (because enough time passed between the initial submission and the resubmit that the old LastLedgerSequence has already passed or is about to) then it's basically a new transaction in that case also.
  22. Thanks for covering this! I know it has only a passing mention in the official materials, but I haven't found time to do a better write-up.
  23. CL is so much more responsible, patient, objective, calm, and altruistic, that I feel it's an insult to Chris to compare him to Steve Jobs. I'm sad to see Chris leaving his current title to spend time with his family. (Can't really blame him, but I'll miss him!) That said, I can't think of anyone more qualified than Brad to take over as CEO, and it makes even more sense when you consider that this transition has mostly happened already.
  24. @Duke67, one thing that I notice about your validator in the chart is that yours has very high disagreement, which is unusual. It's common to get low "agreement" and also low "disagreement" which means your server is working fine but had less uptime than the other servers. Meanwhile, zero agreement and high "disagreement" usually means your server is running on a parallel ledger (e.g. the testnet). But your server has mid-range values for both, which is very strange. You also have a fairly low number of overall ledgers validated, which suggests the server doesn't have enough resources. Some of that is probably due to a lack of resources, especially RAM. I think 4GB is supposed to be enough, but that's only true if you're using NuDB on a fast SSD. If you're on rotational disks, you should be using RocksDB but you'll need more RAM because you have to keep indexes in memory. Do you know which storage backend you're using? (RocksDB is the default.) Which validators do you have trusted in your UNL, and what's your validation quorum at, if I might ask? Assuming it's set to 3 in the config file, server_state will report 4 on a validator (since it includes itself).
  25. He's in South Africa, actually! (I don't remember which city.) And yes, Adrian is a brilliant writer with a knack for making ILP stuff simple. He also cares a lot about open standards and has done some great work interfacing between Ripple and the W3C.