Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by mDuo13

  1. Yep: Set the "Balance" to 8 in the PaymentChannelClaim transaction and the "Amount" to 10. It'll redeem the 8 and leave the 2 for later. (You can use the same signed claim to take the remaining 2 in another PaymentChannelClaim transaction later if you decide to)
  2. I apologize for confusing everyone with my previous example about the transaction ordering. I misunderstood how the current implementation works and I had filled in my gaps in understanding with elements from the previous implementation that did not apply. (Specifically, the part where an account's first transaction was separated from its remaining transactions was a feature of the old algorithm that I had incorrectly assumed was part of the new algorithm.) It was careless of me to post an explanation without confirming my understanding first. I think the discussion we are now having is: is front-running still feasible (in other words: profitable) under the current transaction ordering rules? and secondarily, if so, what should be done about it? Personally, I'm not convinced either way right now. The only way one could definitively prove one way or the other would be to demonstrate a profitable front-running system; saying it can't be done is a devil's proof: we can always think up new techniques that might be viable and each would have to be proven ineffective individually. The lack of evidence (that is, that nobody is doing it currently) is suggestive that front-running isn't profitable, but certainly not proof. So before we go about changing the canonical ordering system at the center of consensus, let us think about the current situation. Donch proved that front-running was viable under the previous system by doing it and documenting how in detail. For the record, the tl;dr of his approach was this: Since transactions were ordered primarily by hash, he would sign the same instructions multiple times to get the lexicographically lowest hash he could, during the gap between ledgers. (It helped that he could use Ed25519 signing, which is pretty fast.) Then he'd only submit the one with the lowest hash value. Since nobody else was doing this, he had a high probability of his transaction appearing early in the ledger, where it could immediately consume the cheapest orders that were placed on the books in the previous ledger iteration. Aside: One "solution" that would not have needed changes to the protocol would be for everyone to do the same thing to compete for lexicographically-lowest hash, making it much less profitable to do so. That would be needless complexity for users and a waste of computing power, so we changed the protocol. The new algorithm is different from the old algorithm in the following key ways: Instead of each account's first transaction executing before any account's second or further transactions execute, all transactions from an account now execute as a group. This seems to be the change tulo is concerned about, since now you can probably get two or more transactions in before a "targeted" transaction rather than one. Instead of being sorted by hash, transactions are sorted by "account XOR'd with a pseudo-random value" (the hash of the consensus set, I think?) To head off confusion here: no, different accounts don't have properties that would make them come earlier with any consistency, so you can't really game this.
  3. 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
  4. 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
  5. 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.
  6. This makes me wonder if you could make an ILP Connector as a contract on Etherium.
  7. 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.
  8. 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)
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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. 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.
  15. 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.
  16. 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. P.S. check out the byline in (an article which has been up for years)
  18. 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.
  19. 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.
  20. 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.
  21. 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.)
  22. And we're planning on voting for TickSize and SusPay so that both get enabled on Feb 21.
  23. 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.
  24. 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.
  25. 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.