mDuo13

Ripple Employee
  • Content count

    206
  • Joined

  • Last visited

  • Days Won

    18

Reputation Activity

  1. Hodor liked a post in a topic by mDuo13 in One Wallet to Rule Them All   
    Why the bird analogy and not a water analogy?
    What size of Ripple Wallet would you like? Thermos, Tub, Pond, Lake, Sea?
  2. mDuo13 liked a post in a topic by Eik in Beautiful explanation of Ripple and its intentions   
    Currently, some of my funds from a deposit via SEPA transaction are 'on hold' at an exchange. This is because I sent an exact same amount some days ago, and the exchange CAN NOT verify it is not a duplicate of my previous deposit. I mean, seriously?!?! Swift literally is a messaging service, much like a homing pidgeon to communicate between a bunch of rusty legacy systems that are too heavy and expensive to replace. So, currently, these homing pidgeons (which btw do not fly on national holidays) are trying to bring across a message saying something like:
    So now let's pray that the confirmation pidgeon arrives at the exchange before I miss out on another 20-30% price increase. Costly this legacy system...
  3. nikb liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.  
  4. Eik liked a post in a topic by mDuo13 in Doubt about PayChan   
    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.
     
  5. Kakoyla liked a post in a topic by mDuo13 in Doubt about PayChan   
    Yep:
    https://ripple.com/build/transactions/#paymentchannelclaim
    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)
  6. nikb liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.  
  7. nikb liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.  
  8. nikb liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.  
  9. nikb liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.  
  10. enrique11 liked a post in a topic by mDuo13 in Official Cold Wallet From Ripple.com?   
    base58 is just one way of representing a number. There are lots of others, including decimal, hexadecimal, and even an alphanumeric passphrase can be interpreted as a number. There are a number of places where rippled accepts several formats and guesses which one you provided.
    It's probably easiest to clarify this with the wallet_propose command which generates the keys for a wallet. (This is an offline operation -- all it does is some math.) If you don't specify a seed value, rippled chooses one randomly. However, if you do specify a seed value, it'll tell you both the secret key and the public address for that key in several different formats. Example:
    If you run the same command but specify 'snoPBrXtMeMyMHUVTgbuqAfg1SUTb' instead of 'masterpassphrase' the results will be the same. You can even use the RFC-1751 format from the response to generate the same key. And if I'm not mistaken, you can also use any of those three formats as the value of the "secret" field when signing a transaction.
    Here's a breakdown that should help:
    Seed value: Just about any number (including anything that can be represented as a number). Trim this to size and you have a secret key. Secret key: A 128-bit (16 byte) number that you keep secret, and use to sign transactions. Anyone who knows the seed value for an account has full control over that account*. When rippled represents these in base-58 it prefaces them with the value 33 which maps to the letter s in Ripple's base-58 dictionary, so secrets look like this in base-58: "snoPBrXtMeMyMHUVTgbuqAfg1SUTb". You use this to generate a public key. Public key: A 264-bit (33-byte) number that can be used to "easily" validate any signature from the corresponding secret key. It's "hard" to figure out a secret key or to create a valid signature using just a public key and past signatures. (Basically you have to make a completely insane number of guess-and-check attempts.) Typically these are represented in hexadecimal. (See the SigningPubKey field of a transaction.) You always have to tell people your public key eventually in order for them to be able to validate your signatures. However, both Bitcoin and Ripple actually put the public key behind one more layer of abstraction:  You use the public key to generate an account address. Account ID: a 160-bit (20 byte) number that is derived from a public key using a hash function (technically two, the RIPEMD160 of SHA256) and prefixed with the value 0 which maps to the letter "r" in Ripple's base58 dictionary. Account Address: the Account ID, encoded in base58 with a 4-byte checksum (SHA-256 of SHA-256 of the account ID). This is an easily reversible step that just makes it easier to read and write addresses (big numbers) for human consumption. *The exception is that the owner of an account can disable the master key if they have a regular key(pair) set, in which case you have to know the regular keypair's secret key to control the account.
    All it takes in order to create an account in Ripple is sending 20 XRP to a validly-formed address (that is, it's a number that fits in 160 bits and the error checking is good). If an account hasn't been created yet, it's not in the ledger, and you'll get a not-found error if you try to check its account info, trust lines, transaction history, etc. However, you can subscribe to an account that doesn't exist yet (and if your subscription is still active when the account gets funded, you'll get notified).
    Sending a transaction just requires a seed value or secret key, and access to a rippled server. You write some transaction instructions, use ECDSA to sign the message** (curve=secp256k1), and attach your signature, valid pubkey and address to the transaction. Then RCL checks several things:
    The signature matches the transaction instructions The signature matches the pubkey The pubkey matches either (a) the address of the account sending the transaction, or (b) a regular key address previously stored in the ledger by the account sending the transaction In the case of 3a, it also checks that the account hasn't disabled its master key. ** rippled also has experimental support for the EdDSA algorithm using the ed25519 curve. It works basically the same way. Technically the Ed25519 public keys are 32 bytes instead of 33, so they're prefixed with the byte 0xED to make them a consistent size with the secp256k1 keys.
    A note on "black hole" addresses: Typically if you have a validly formed address, that's because you started with a seed value and went through all the steps. But it's also possible to just start with a public key and generate a valid address from there. Addresses are typically pretty random because they're based on hash function output, which is basically indistinguishable from random noise. If an address seems incredibly unlikely to be random (for example, rrrrrrrrrrrrrrrrrNAMEtxvNvQ) then it's likely that you generated that address from something that wasn't a real output of RIPEMD160 of SHA-256, which means it's a guessing game to figure out what input could generate that output -- and again, that's a problem that's incredibly hard to solve, involving a ridiculous number of guess-and-check attempts. (Bitcoin mining is based on a variation of that same problem.) And even if you figured out what public key could generate such a nicely ordered output, you still have to solve a ridiculously-hard elliptic curve problem to figure out what the secret key is. So, chances are, nobody in the world actually knows or will ever guess the secret key that would give them full control over rrrrrrrrrrrrrrrrrNAMEtxvNvQ or other "unlikely" accounts like that. We call these addresses black holes, because in all likelihood, any XRP they receive is lost forever.
    Now if you've read this far, here's a fun side project you can try:
    Start with a list of most common passwords. Use those as seed values to generate Ripple keys and addresses (wallet_propose). Check the ledger to see if any ill-advised schmucks have funded those addresses. (Here's a freebie: rU1HdiNbCJTdBJhGa22B76QCuDSVBCWGNj is the address for the secret key 'trustno1' but it doesn't exist.) If you find one that does exist, check whether the master key is disabled. (If it is, the Flags value of the account bitwise-AND 0x00100000 is a nonzero value) If the master key is not disabled, then you have full control over that account, and you can take any XRP or other currencies it holds. Now, actually taking it might be legally considered theft and/or computer fraud, so maybe think twice about actually taking it. (Personally, I would view it as the digital equivalent of picking up money from the street, but a jury might think differently.) There are plenty of other things you can do with full control of an account, like sending embarrassing Memos or setting the account's Domain field to point back at your favorite website.
  11. nikb liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.  
  12. mDuo13 liked a post in a topic by Eik in Front-running (?) and other questions   
    Looking at transaction hashes and TransactionIndex in recent ledgers using e.g. Data API v2 Tool, we can easily see that the entire execution ordering is (pseudo-)random, and not in a cyclic ordered loop, starting at a pseudo random point as suggested by @mDuo13.
    Example ledger (Transaction hash  - Transaction index)
    06DA... - 30
    08E3... - 3
    11E3... - 15
    13CF... - 42
    14FE... - 13
    160A... - 23
    1FEB... - 11
    ...
    I guess that shows for sure now that front-running by working the transaction hashes is indeed not possible anymore.
    I am relieved that I can't think of more ways that front-running can be performed
     
  13. mDuo13 liked a post in a topic by RafOlP in One Wallet to Rule Them All   
    Hello guys, I like this thread.
    Though I have to say that there are opensource wallets out there that never received a single pull request from the community.
    This sends one of the following messages (or both):
    The community does not have enough technical resources available for contributing There is no consensus over which wallet to focus efforts on If "1", then we are not able to have a wallet project.
    If "2" this thread is helpful since it can generate consensus enough to mobilize a critical mass of resources that can put a wallet up.
    I hope we are in "2".
    Links for some opensource wallets:
    https://github.com/ripplerm/ripple-wallet
    https://github.com/rippex/ripple-client-desktop
    https://github.com/jatchili/minimalist-ripple-client
    https://github.com/Autodidactic-I/TheWorldExchange
    https://github.com/yxxyun/ripple-client-desktop
    https://github.com/yxxyun/ripple-wallet
  14. Eik liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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
  15. tulo liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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
  16. tulo liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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
  17. tulo liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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
  18. enrique11 liked a post in a topic by mDuo13 in Microsoft Bletchley project, "Similar to Codius suggested by Ripple"   
    I think lucky makes it sound a whole lot better planned and intentional than the reality actually was, but it is pretty cool when something like this falls into place.
  19. fh13 liked a post in a topic by mDuo13 in RCL + Ethereum for decentralized exchange   
    This makes me wonder if you could make an ILP Connector as a contract on Etherium.
  20. Eik liked a post in a topic by mDuo13 in Doubt about PayChan   
    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.
     
  21. fh13 liked a post in a topic by mDuo13 in RCL + Ethereum for decentralized exchange   
    This makes me wonder if you could make an ILP Connector as a contract on Etherium.
  22. Eik liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.
  23. tulo liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.
  24. Eik liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.
  25. tulo liked a post in a topic by mDuo13 in Front-running (?) and other questions   
    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.