Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


mDuo13 last won the day on September 15 2016

mDuo13 had the most liked content!

About mDuo13

  • Rank
    Advanced Member
  • Birthday

Profile Information

  • Gender
    Not Telling
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. @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).
  10. 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.
  11. Yeah that's pretty much how that works. When the sender creates a channel, they set aside enough XRP equal to the channel's max value. As long as the channel is active, that XRP can only (a) go to the recipient of the channel or (b) stay in the channel. When the receiver redeems a claim, XRP leaves the channel and goes to the receiver. When the channel closes, any XRP not claimed goes back to the sender. So in a sense, the channel's "balance" decreases over time when the recipient redeems claims against it. (Or, it stays the same because nobody redeems any claims.) The channel's maximum value is static for the entire lifetime of the channel, and the XRP backing that max value is locked up in the payment channel until it closes. I think the creator can also close out a channel before its expiration, but there's a waiting period or something. I'm not sure the details on that one. (It's on my to-do list.)
  12. It wouldn't be a trivial change to make XRP divisible to more decimal points, but it would be doable. In the scenario where that became necessary, I'm sure we could make it happen. I suppose it's possible there could be some sort of perverse incentives like with Bitcoin's block size problem, but it's hard to picture enough validators really benefiting from creating sub-drop XRP denominations. But also, as stated before, at an expected rate of thousands of years before that happens, we actually can leave that for future generations to worry about if it ever does come up in reality. Personally, I think the small amount of indefinite inflation built into Stellar and Dogecoin is a nice feature. On the other hand, there is a certain rather nice elegance to saying, this is all the XRP there will ever be, the end. It's great because it doesn't get more predictable than that. Historically, Ripple Labs kind of screwed that up by making it hard to predict the releases of XRP into the general supply. We've made a lot of strides recently to fix that, like locking up founders' XRP and issuing the company's "50 billion left at the end of 2021" guidance.
  13. It's definitely going to be interesting to see how all financial institutions in all corners of the world end up getting licensed and connected to one another. It's especially interesting in developing countries whose financial services sectors are just starting to enter the digital age. I'm fairly confident that the Interledger Protocol or something like it will be really appealing and useful for all these institutions to deal with one another, especially if it really lets them team up and take on the huge Old World financial institutions that are currently the gatekeepers of international commerce. I wish the article went into greater detail about how the Tanzanian mobile money companies achieved "wallet-to-wallet" compatibility in their money offerings.
  14. My understanding (and this is not a guarantee) is that we plan to enable both SusPay and PayChan soon™ after the Flow amendment gets enabled. Given that each amendment takes 14 days of uninterrupted support to become enabled, and we expect Flow to become enabled October 20, the absolute earliest that SusPay and PayChan could be enabled is November 3rd. Historically, we've encountered far more delays and blockers due to our cautious approach to network management, so it will probably be later than that but still this year.
  15. Payment channels took a while for me to grok, but now that I do I think they're awesome. To clarify the "redeeming multiple claims" thing, my understanding is that you can claim anything in any order, but if you've already settled a claim on the same payment channel then you only get the difference between how much you claimed before and how much your receipt is worth now. If you try to redeem a claim for less than you've already settled, nothing happens. So basically you can only cumulatively receive as much as the largest claim you have. So if I give you claims for 10, 15, and 20 XRP, you can do any of the following (and more combinations): Redeem the 20 XRP claim and be done Redeem the 10-claim for 10 XRP, then redeem the 15-claim for an additional 5 XRP, then redeem the 20-claim for another 5 XRP, totaling 20 XRP. Redeem the 10-claim for 10 XRP, then redeem the 20 XRP, totaling 20 XRP. Redeem the 15-claim for 15 XRP and then wait to redeem the 20 XRP at any later date before the payment channel expires. If you let the payment channel expire, you only end up with 15 XRP. If I decide that the payment channel is useful, I can renew it. (You can't renew it on your own, though.)