mDuo13

Ripple Employee
  • Content count

    180
  • Joined

  • Last visited

  • Days Won

    17

Reputation Activity

  1. mDuo13 liked a post in a topic by Morty in How Would XRP - The Token - Behave outside of the Ripple Network ?   
    An example of XRP being used out of its native habitat, would be exchanges like poloniex.  The XRP just stays put in a poloniex ripple wallet and XRP (xrp tokens) can be freely traded on polo's internal ledger. There are no ripple fees because the real XRP is sitting static in a wallet and poloniex can then charge their own fees on the trading of xrp tokens.
  2. D-fault123 liked a post in a topic by mDuo13 in Transaction failed with terPRE_SEQ but still executed   
    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.
  3. Professor Hantzen liked a post in a topic by mDuo13 in Transaction failed with terPRE_SEQ but still executed   
    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.
  4. D-fault123 liked a post in a topic by mDuo13 in Transaction failed with terPRE_SEQ but still executed   
    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.
  5. D-fault123 liked a post in a topic by mDuo13 in XRP price stabilization/pegging   
    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.
  6. D-fault123 liked a post in a topic by mDuo13 in Transaction failed with terPRE_SEQ but still executed   
    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.
  7. D-fault123 liked a post in a topic by mDuo13 in Transaction failed with terPRE_SEQ but still executed   
    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.
  8. mDuo13 liked a post in a topic by Professor Hantzen in How to replay ledgers with rippled   
    I've followed the instructions for running rippled in stand-alone mode using the command line, as supplied here on the Ripple Developer Center.  To recap:

    1) Start rippled.
    2) Wait until rippled is synced.
    3) Retrieve the ledger I want to replay, and the one previous to it, using the "ledger_request" command.  Repeat the command a few times until both ledgers have been retrieved as exampled here on the Ripple website under the "Commandline (success)" tab.  This part seems to work fine, I get all of the responses described, in the correct order.
    4) Shutdown rippled (using "rippled stop").
    5) Start rippled in stand-alone mode specifying the ledger to replay.  The command is:  "rippled -a --load --ledger [some_historical_ledger_index]"

    I can't get to step 6, which is "Manually advance the ledger", as step 5 fails with the following error:

    2016-Dec-22 20:09:08 LedgerMaster:NFO Validation quorum: 3
    2016-Dec-22 20:09:08 Application:NFO Loading specified Ledger
    2016-Dec-22 20:09:08 Ledger:DBG Ledger not found: WHERE LedgerSeq = [some_historical_ledger_index]
    2016-Dec-22 20:09:08 Application:ERR The specified ledger could not be loaded.

    Any ideas?
  9. mDuo13 liked a post in a topic by tulo in The Fate of Fees   
    Black hole addresses are addresses that none has the secret key, so the'll actually result with XRP in it but noone will ever be able to use them...it is something that litterally annoys my mind. I'd prefer to see them destroyed that in the limbo, because they still are shown in the total XRP in circulation. 
  10. mDuo13 liked a post in a topic by nikb in The Fate of Fees   
    Transaction fees aren't sent to blackhole addresses: they are, actually, destroyed.
    When processing a transaction, if you sum up the XRP moving, you'll see that more XRP went in than came out and the difference is an amount that is exactly equal to the fee that's paid.
    Additionally, the ledger contains a counter that indicates how many XRP are in existence; that field is reduced exactly by the fee amount with every transaction.
  11. D-fault123 liked a post in a topic by mDuo13 in XRP price stabilization/pegging   
    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.
  12. D-fault123 liked a post in a topic by mDuo13 in XRP price stabilization/pegging   
    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.
  13. D-fault123 liked a post in a topic by mDuo13 in XRP price stabilization/pegging   
    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.
  14. dzham liked a post in a topic by mDuo13 in "Multi-Signing in Ripple: Q&A with David Schwartz"   
    The way Multi-Signing currently works in the Ripple Consensus Ledger, you define a weight for each signer when you set up the signer list, and you set up a target "threshold" for the list. When you look at a multi-signature, you add up the weights of all the signers in it, and if they equal or exceed the threshold, then the multi-signature is enough to authorize the transaction. That gives you much more flexibility than some fixed rule like, "you need a majority of signatures."
    Signer weights are unsigned 16-bit integers, so you can use values 1 through 65535. The threshold is an unsigned int in the range (1, sum of signer weights) inclusive. FUN FACT: With the current values for max signers (8) and max weight (2^16 - 1), the current de facto maximum threshold is 524280.
    Example:
    If you want to do, "Monica can sign for me, as long as either Warren or Asheesh approve, but Warren and Asheesh can't sign without Monica," then you could set your signer list as follows:
    Members:
    - Monica (Weight: 2)
    - Warren (Weight: 1)
    - Asheesh (Weight: 1)
    Threshold: 3
    So Monica + Warren = 2+1 >= 3. Monica + Asheesh is the same, but Asheesh + Warren (1+1 < 3) so Asheesh and Warren can't sign for you unless Monica also does.
     
    That's multi-signature weights for you. There are still some cases that you can't do, but it's way more flexible than simple "M-of-N" signing. And I'm not even going into the details that David was discussing about other features like how Ripple's multi-sign is designed so that members can change their keys independently. (But that's another cool feature.)
  15. tomxcs liked a post in a topic by mDuo13 in Tick size amendment #1922   
    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.
  16. KarmaCoverage liked a post in a topic by mDuo13 in Tick size amendment #1922   
    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.
  17. tomxcs liked a post in a topic by mDuo13 in Tick size amendment #1922   
    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.
  18. tomxcs liked a post in a topic by mDuo13 in Tick size amendment #1922   
    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.
  19. tomxcs liked a post in a topic by mDuo13 in Tick size amendment #1922   
    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.
  20. tomxcs liked a post in a topic by mDuo13 in Tick size amendment #1922   
    It's not constraining the digits of the amounts, it's constraining the digits of the "quality" aka the ratio between the prices of the two currencies to be traded.
     
    If I offer to sell 100 EUR.SomeGateway for 1000 XRP, that's a quality of 0.1 in the XRP:EUR.SomeGateway market. If David offers to sell 3.333333 EUR for 33.3333 XRP, that's still a quality of 0.1 even though the absolute amounts have different significant digits. If his offer comes after mine, it gets placed below mine.
    If Nik offers to sell 100.00001 EUR.SomeGateway for 1000 XRP, that's a quality of 0.10000001 in the same market. Since Nik's offer is of higher quality, it's ranked above David's and mine even if our offers were on the books first.
    The problem is, even though Nik's offer is technically better, the amount you get if you consume part of Nik's offer is essentially the same because that extra few fragments of a cent isn't likely to add up to anything that can be redeemed for real value. So basically Nik got to cut in the line by offering nothing of value.
    Then if Nik's order-sniping bot and someone else's start fighting over the top of the XRP:EUR.SomeGateway market, they can go back and forth for quite a while, placing bids that are microscopically better than each other without ever adding up to being better enough that any real person would care which offer they took. This occupies a bunch of disk space (all transactions are in the history forever!) and means processing a bunch of transactions that aren't valuable. Even though Ripple can handle that traffic (as it does today!), it's wasteful to conduct business that way.
    Enter tick sizes. If EUR.SomeGateway sets their tick size to 3, then Nik's offer  is rounded down to 0.100 quality, same as mine and David's, which means Nik's offer gets placed after ours. If he wants to actually claim first place in the order-book line, he's going to have to outbid us by an amount that's at least sort of significant. If he's content with the price where it is, he can let his offer sit in line.
     
    It's not solving a really big problem, but it does make life easier for traders and network nodes.
  21. tomxcs liked a post in a topic by mDuo13 in Tick size amendment #1922   
    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.
  22. mDuo13 liked a post in a topic by RafOlP in How to securely sign offline TRADE transactions?   
    If you don't want to calculate rates every time and want to sign an order to buy a certain asset you can sign a payment transaction to yourself ordering to deliver the asset you wanna buy using the partial payment flag. The transaction will spend your asset getting the most it can of the asset you instructed to deliver.
  23. mDuo13 liked a post in a topic by hypostatization in "They've basically dropped blockchain"   
    Payments are perhaps overemphasized, distracting from the greater value of Ripple. Cryptocurrency contributes most to payments where trust is problematic. Darknet markets are an example of where cryptocurrency is inherently extremely useful, representing a context where never trusting anyone is ideal. Environments that facilitate legally compliant payments, however, simply do not share the same problem. It is quite the opposite. Financial institutions are essentially in the business of calculated trust. Cryptocurrency based payments do not add advantage or efficiency to that model, but Ripple does.
    A trust problem still exists. It is a granular concern. Instead of not being able to trust anyone, FIs must concern themselves with not being able to trust everyone. It is simply not feasible to appropriately calculate trust for all potential parties to all potential transactions. Ripple shines here. It enables transactions through chains of trusted intermediaries. Ripple allows FIs to leverage their existing trust relationships, instead of suggesting that they would somehow be better off to abandon those existing networks of value. ILP broadens the network reach of Ripple, and institutions, but the trust solution of trust relationships and pathfinding remains uniquely within the RCL.
    A payment still occurs under the hood when Ripple works its magic, but the magic is not the payment itself.
  24. mDuo13 liked a post in a topic by D-fault123 in "They've basically dropped blockchain"   
    Dunno about blockchain being dropped, but @warpaul sure did drop the mic.
  25. mDuo13 liked a post in a topic by lucky in "They've basically dropped blockchain"   
    Oh my gosh, what Ripple has been telling us for over a year now is true!
    XRP is optional, ILP is what gets banks on board of their infrastructure.