Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


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. The "canonical order" is the order the transactions are executed in, when a ledger closes. (Transactions are always executed in canonical order in closed and validated ledgers. In the open ledger, transactions are executed in the order they arrived instead. This is why transactions that tentatively failed can succeed and vice versa.) So if the transactions that make it into a ledger are 5 transactions from different accounts and 6 transactions from tulo, the canonical ordering is something like this: Take tulo's first transaction (by sequence number) and add it to the 5 transactions from different accounts Sort this set by transaction hash Start at a pseudo-random point in this set, using the final contents of the ledger as the seed value so everyone picks the same pseudo-random value Execute the transactions in order from the chosen starting point, looping around to the beginning until you've executed all the transactions in this set Now sort tulo's remaining transactions and sort them by sequence number Execute those transactions in order from lowest sequence to highest Maybe it would make more sense to visualize it like this: Transactions in the ledger: a, b, c, d, e, t1, t2, t3, t4, t5, t6 Set of transactions to be executed first: a, b, c, d, e, t1 Set of transactions, ordered according to a random starting point (for example, d): d, e, t1, a, b, c Tulo's remaining transactions: t2, t3, t4, t5, t6 Canonical order: d, e, t1, a, b, c, t2, t3, t4, t5, t6
  2. Also, just a clarification on Eik's post regarding trying to pack transactions into the same ledger so that one of them executes before the transaction you're front-running: It doesn't help to send multiple transactions from a single address. As I recall, if a sender has multiple transactions with different sequence numbers in a ledger, everything past the first gets bumped to the end of the canonical order (and then sorted by sequence). If the transactions have the same sequence number, you have no control which one makes it into the ledger (and it increases the chance that none of them will) so you're not increasing your chances that you'll get one in before the targeted transaction. You could do the same thing with separate sending addresses for each transaction without encountering this issue, but: - it becomes harder to make sure that only one of them succeeds - you're on the hook for funding the reserve of that many more accounts
  3. If the transaction you want to front-run makes it into the open ledger of enough servers, it'll pass consensus and make it into the next validated ledger. At that point, you can hope that the canonical ordering randomly favors you, but that's not reliable. You can't kick a transaction "back into the queue" from the open ledger on one server. You might be able to race it to the open ledger on other servers.
  4. This makes me wonder if you could make an ILP Connector as a contract on Etherium.
  5. To my understanding, this is correct, but I've only glanced tangentially over the C++ code for it. Front-running via the transaction queue might be possible, but I think it's probably too costly to do profitably. The idea would be: Monitor for incoming transactions you might want to front-run (e.g. if you see a big order coming you buy and resell to that order at a higher price). When you see such a transaction, you force it to go into the transaction queue rather than the open ledger. This is easier said than done: You have to submit a whole lot of meaningless transactions with high transaction cost (adding up to a lot of XRP) The meaningless transactions would have to be sent from many different addresses, since any one address can have at most 10 transactions in the queue at once. Holding enough XRP to satisfy the reserve of all these accounts would be even more expensive. You can't kick a transaction out of an open ledger after it gets in, so you'd actually have to race the transaction across the net, submitting all your meaningless transactions to other rippled servers before they process the transaction you "saw" in step 1. This would be easier if the transaction you want to front-run got put in the queue rather than the open ledger at first. That would mean it's only possible to front-run transactions when the ledger is busy and the sender of the transaction didn't care to pay extra to get their transaction in fast. Keeping the open ledger full all the time would be crazy hard and expensive, basically DDoSing the RCL, because the open ledger's available spots increase when lots of transactions are making it in. While the transaction you want to front-run is in the queue, you submit the meaningful transaction(s) that are supposed to do the actual front-running business, paying higher transaction costs so you can cut in line. Then you wait for the transaction you front-ran to exit the queue... Profit! Unless the sender of the transaction took any countermeasures: If they notice they got queued and are worried about being front-run, they could submit a new equivalent of the same transaction with a higher transaction cost to get into the open ledger before your front-running transactions do. If they set the LastLedgerSequence aggressively enough, you don't have much time to do this; in fact, if their LLS is low enough their transaction will never get queued at all. In short, front-running via the queue seems like it would only be possible in some rare situations, and it wouldn't be cheap. I wouldn't try it.
  6. Well, the complaints are always more controversial! I think Ripple's done a good job of establishing itself as "different approach" than Bitcoin. Speaking of controversial, I'm starting to believe that one of the things Ripple has done right is not to decentralize too early. Otherwise, bug-fixing patches would be big, possibly consensus-halting, hassles. I also think Ripple was right to elevate its approach from making "one ledger to rule them all" to making one great ledger and focus on making ledger interoperability more seamless. ( with ILP)
  7. You guys mostly have it. (I'm trying to improve the docs on this stuff right now, but I'm also splitting time with core Interledger specs and other projects. As our new tech writer gets up to speed I should be able to do a better job with that.) Sukrim's way of describing it is largely correct but I find the analogy to be somewhat unintuitive. Here's a summary of how it works: - First, you set up a payment channel to some specific receiver and fund it with XRP. Only XRP is supported, not issued currencies (for the time being). The XRP that you fund is set aside from your normal balance, so it can't be spent at all while the payment channel is open. - At any time, you can sign "Claim" messages that give some of the XRP from the channel to the receiver in that channel. The receiver can submit any claim message they have to receive that much XRP from the channel. They can't get more than was set aside in the channel, of course. - The sort of tricky part is, as a receiver you can redeem any number of claims in any order, but the total amount you receive is equal to the largest one only. So, say you redeem a claim for 4 XRP and then a redeem a claim for 6 XRP in the same channel. The first time you receive 4 XRP and the second time you'll receive 2 XRP. Or you could just not redeem the first claim, and redeem the 6XRP claim for the full 6 all at once. The cool thing is this basically gives the receiver the confidence to say, "Well, I'm definitely going to get at least 4 XRP, but I don't need to withdraw it right away and I don't have to worry that the XRP won't be there when I do." - Creating claims, sending them, and verifying that they're valid are all things that happen outside of the actual ledger. The only parts where the RCL actually gets involved are (a) when the channel is set up, (b) when you redeem money, and (c) after the channel expires or gets otherwise closed. So there's literally no limit, from RCL's perspective, on how many claims you can issue. As long as the person only redeems the largest (probably most recent) Claim, it doesn't matter how many intermediate steps they went through. In practice, the practical limit is how many signatures you can generate (on the sending side) and verify (on the receiving side) per unit time, with verification typically being the harder part. For maximum efficiency, use Ed25519 signatures, which have been demonstrated at ~100,000 signatures/second on a decent desktop processor. And since any number of people could be doing the same thing on their own computers and you can start to see how PayChan actually enables baaaasically unlimited transactions per second. - If a channel runs out of the XRP that was funded for it, it closes automatically next time any transaction touches it. If the sender sets an expiration on the channel, then any transaction that touches the channel after the expiration closes it and returns unclaimed XRP to the sender. If the receiver doesn't care about a channel anymore they can close it right away. You can't redeem a Claim after a channel is closed. - When the payment channel is first set up, the sender specifies a "Close Delay" on it which limits how fast they can close the channel. It's really important that the receiver checks that the close delay is long enough for them to notice and redeem any Claims they're holding onto if the sender decides to close it, so beware of that.
  8. 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.
  9. 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.
  10. 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. 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.
  12. 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.
  13. 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.
  14. 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.)
  15. P.S. check out the byline in (an article which has been up for years)