Jump to content


Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Ripple Address
  1. mDuo13

    Trust Line is not getting removed

    Removing trust lines can be a little confusing. Sometimes it's out of your control, because if someone else opens a trust line to you or modifies the settings on their side of your trust line to them, the trust line object will stick around and still show up. You don't have to pay the owner reserve for it as long as your side is: Your limit is 0 Your balance is 0 (or negative, meaning you've issued to them, which would be unusual) All the settings are default: you haven't frozen it, you haven't enabled¹ rippling, you haven't changed the quality settings When both sides meet this criteria, the trust line gets automatically deleted. Usually, gateways don't do anything to change trust lines out of the default state, so if you opened the trust line to a gateway, you can probably get rid of it just by setting the limit to 0 and spending your balance. ¹The "default" setting for rippling depends on your account's DefaultRipple value. Normally "DefaultRipple" is off so the "NoRipple" flag's default state is on. If you flip DefaultRipple, then "rippling enabled" is the default setting for your trust lines.
  2. mDuo13

    rippled 0.90.1 released

    rippled 1.0 is still in development. "beta 4" is the latest dev build, which came out 3 days ago. We're still adding features, but things that are already in: A new API command for managing the shard store Improvements to looking up checks, escrow, and payment channels in ledger data Example configuration for connecting to the test net More consistent handling of undefined flags (making sure transactions don't use flags that are reserved for future use) Fully moving from scons to cmake for compiling Better handling of alternate ledger chains (so we don't have "32750 is the earliest ledger" hard-coded) Various under-the-hood optimizations and cleanup There are other things that haven't made it into the build yet, but I won't talk things up in advance just in case they don't make it in time for v1.0. Don't want to make promises I can't keep!
  3. mDuo13

    Set trust line for cold wallet?

    (1) creating a trust line to a cold wallet—as in, the hot wallet is the one with the nonzero limit, as it should be—doesn't need the cold wallet's interaction at all unless you're using authorized trust lines. (2) setting trust is exactly the same as every other transaction. You sign a TrustSet transaction, you get a transaction blob, you move the tx blob to an online machine (for example by QR code as you mentioned), and you submit the blob from an online machine. There's nothing about TrustSet that's different from any other transaction type like Payment or Offer in this regard. Every transaction can be created offline. You may need to manually input some data for the transaction (like the address you want to trust, or the current Sequence number of the cold wallet if it doesn't match what you've been keeping track of offline because, say, a transaction you previously sent didn't get accepted to a validated ledger). But that's not different for trust, either.
  4. mDuo13

    Are you running a validator?

    I used to run one, but my hard drive was getting old and it was starting to lag noticeably. (Also, for a little while I couldn't compile the updates on Arch Linux because the system's boost library was out of date. That was before we had instructions for compiling whatever boost version you need.)
  5. mDuo13


    Maybe something like, it got a retriable error the first time, then rippled internally retried it and it succeeded, but ripple-lib also retried submitting it and that's when it returned tefARLEADY? There could be a benign race condition or bug in ripple-lib or your own code that caused it to be submitted twice. (rippled definitely sometimes holds transactions that fail with "ter" codes and retries them.) In any case, it's perfectly safe to submit the exact same signed transaction multiple times. The meaning of "tefALREADY" is that the transaction has been added to a ledger already (maybe not validated yet) so in other words, that's rippled saying, "yes, yes, I got it, this transaction has been processed already, relax!"
  6. I know it's very tempting to say, "We have a blockchain, so let's use it for everything," but you can probably figure out where I'm going when I phrase it that way. It's good to think outside the box, but you have to do your research on what similar things are already out there and what each system's pros and cons are. Blockchain is an ingenious system for solving one problem—a decentralized system where no one party can be trusted to maintain the system state. It's not nearly as good for solving many of the other problems out there. The XRP Ledger's consensus protocol makes tradeoffs to work under certain circumstances: Not all participants in the consensus system are known in advance, and different participants may have different ideas about who's trustworthy. The UNL system gives a little bit of flexibility to add new participants piecemeal while providing some guarantees about what topologies maintain a consistent global state. (Of course, recent research shows that it's not as flexible as we thought, thus why Cobalt.) Participants are running on unknown hardware in unknown global locations. For this reason, there's a hard-coded 2 second minimum delay in consensus to make sure that the process doesn't become dominated by whichever validators run on the fastest computers. But a whole 2-second delay is a pretty massive amount of latency for many other kinds of automation. You'd have to rip that out to lower your latency, but at the point where you're cutting up the core mechanics of the algorithm, the question is where do you stop? Similarly, on the topic of malware, I don't think blockchain is going to save you. Suppose you have some critical system that uses a blockchain to inform its decisions. Ultimately, there's one subsystem or computer or controller or something that's in control of the valves of your nuclear reactor or whatever it is. If that system gets infected, it's game over, no matter what else is going on. Sure, you can say it'll only open the valve if some consensus of XRP Ledger servers agrees it should do so, but if it's infected, what's to stop the malware from just imitating the signal that the XRP Ledger service was supposed to send? The valve doesn't understand things like transactions, hashes, and signatures. And the valve has no way of knowing if a system is infected. If an infected system says, "Yep, the signature checks out, this is 100% a legit transaction approved by consensus and there's nothing suspicious at all," then the valve is opening. In other words, you don't have to compromise a decentralized system if you can compromise an endpoint.
  7. https://ripple.com/dev-blog/rippled-version-0-90-1/ Hotfix release that patches some crash bugs (including several reported by Guido Vranken, whose work is impressive). No new features or other changes. Along with the release itself, Ripple is starting to vote in favor of the Checks, DepositAuth, and fix1513 amendments, so expect those to turn on in 2 weeks. (Note to self: update the "Known Amendments" page with the updated expected time)
  8. Funny, if you look at the code linked by that issue, it's been updated to list the additional types... I wonder if the API's not running the latest code, or if the problem is elsewhere?
  9. The answer to the first question is "almost" and the answer to the second question is "no". You must sign transactions to trade on the XRP Ledger. You may sign those transactions using a signing library without running your own rippled server, then submit the signed transactions to a public rippled server, and that's safe & secure. Basically, if you sign the transactions using JavaScript, you don't need to run rippled. Of course, you may still get benefits out of running your own rippled server since you don't have to share with everyone else like you will if you only use the public servers, but the maintenance burden is definitely lower using the public servers. In JavaScript, the library that has signing is RippleAPI , also known as ripple-lib. If you're using C++, you can use ripple-libpp to sign the transactions. There aren't any other supported signing libraries right now. (If you want to implement signing in another language, that would be quite an undertaking.) And as I warned before, if you're calling rippled's sign method via anything other than localhost, be sure you use an encrypted connection (HTTPS/WSS not HTTP/WS) or intermediaries might "overhear" your secret. On localhost, unsecured HTTP/WS is fine because the message never leaves your own machine. The "submit" method —if you're submitting already-signed transactions—is OK even over unencrypted HTTP/WS because those signed transactions don't contain anything secret.
  10. It's very likely that making it easy to move money will cause money to move a lot more often. It's very hard to know by how much. If you consider snail mail vs. email as a point of comparison, the numbers are inspiring.
  11. What tulo said is all true. Also, you don't have to write JavaScript code to trade on the decentralized exchange. You can use rippled's JSON-RPC interface from any language that has an HTTP client, including Python. For example, here's some code I wrote to query a rippled instance directly from Python: https://github.com/mDuo13/txsplain/blob/master/txsplain.py#L191-L215 The biggest advantage of JavaScript is that there's an official library that (among other things) can create signed transactions natively in JS so you don't have to be running your own rippled instance to get trusted signing. If you're using any other languages, you basically have to run your own rippled server if you want to get secure signing. IMPORTANT WARNING ON SIGNING: Don't use the "sign" command of rippled instances you don't control, because whoever runs the server can save your secret and use it to take control of your account. Same goes for the "submit" command in sign-and-submit mode. And even if you own the server, don't use HTTP (do use HTTPS) if the rippled is not running on the same computer or your own sub-network. HTTP traffic isn't encrypted, so random intermediaries could read the unencrypted traffic (with say, a packet sniffer) and also learn your secret. HTTPS traffic is safe as long as it's configured correctly. (An example of incorrect configuration would be if you use a self-signed cert and you don't verify that the rippled is using that exact same cert or CA; in that case a man-in-the-middle attack could present itself to you as if it's your own rippled server using a different cert.) One other important thing to keep in mind when trading on the XRP Ledger's decentralized exchange is that transactions are only processed when a new ledger closes (approximately once every 4-5 seconds), so you can't do "high frequency" trading. If a particularly juicy trade appears in one ledger, you are fighting with everyone else who notices it within about a 4-second window. Oh, and https://ripple.com/build/reliable-transaction-submission/ is worth a read, so you can be sure when you submit a transaction that it'll reach a final outcome (succeed or fail) within a sensible timeframe. That said, good luck, and welcome to the realm of XRP Ledger traders.
  12. mDuo13

    Host application on XRP

    Those instructions are slightly outdated because they don't cover the validator list site settings. For a personal test network, you can remove the validator list site stanza and hardcode the validator keys to trust. I won't go into detail, because generally speaking, Ripple does not want to make it easy to start parallel XRP Ledger networks. (Most of the time, the test net is plenty. The exception, which matches this case, is if you really want to test differences in the consensus algorithm itself.) You may want to read https://ripple.com/build/stand-alone-mode/ to get a better sense of how to run rippled in testing mode with a new genesis ledger, since there are some gotchas. For starters, all amendments will get enabled starting with ledger index 2. For another thing, the default reserve settings are different than the production ledger's settings. There are a also couple edge cases that work differently when you're not missing ledgers before 32750 as the production ledger history is (I don't remember all those offhand).
  13. There's a reason we're not incentivizing people to run validators. An incentive is a way to encourage people to take certain behaviors. Which behaviors? Well, the ones you're incentivizing, of course! Right? Except, you probably aren't incentivizing the behaviors you think you are. Incentivization prompts behavior that maximizes the reward and minimizes punishment. This isn't always the thing that you wanted to reward. If you shout at your puppy for pooping in the house, he still has to go but now you're scary, so he'll only do it when you aren't looking. If you give a dolphin fish for picking up trash, it'll stockpile trash and rip it into small pieces so it can get more fish. If you teach an A.I. to play tic-tac-toe, it might discover the most reliable way to win is to crash its opponent. Not to mention that incentivizing charitable behavior sometimes causes people to view it less charitably. If you make alcohol illegal, you might just prompt crime to get organized. A long time ago (before I started at Ripple, actually), the company tried to incentivize a developer community by giving users XRP if they authenticated their GitHub account. Within hours, they received a phone call from GitHub's offices, asking Ripple to stop DDoSing their new user sign-up. If you give Bitcoin out to people for confirming new blocks of transactions, you might end up with a tiny number of mega-mining pools, who'd rather charge higher fees than process more transactions. A certain other Ripple employee put it more succinctly: We don't want bad things to happen to the XRP Ledger because we rewarded people for the wrong thing. In fact, we don't even want to throw away XRP on incentivizing something that's merely neutral. The point of the XRP Ledger is to provide a public good that benefits everyone it can. Ripple could pay people to run validators. But where's that pay coming from? XRP's supply is finite, so they couldn't get paid forever. They might threaten to stop running validators, endangering the network if they weren't being paid anymore. Or they might simply stop if the pay wasn't sufficient anymore. Either way, that's bad for the network if it happens. As long as running a validator isn't too expensive or difficult (things we're still working on improving), then we're confident the people and institutions who should run validators will end up doing so for their own and the public benefit.
  14. The "request" method that uses is an in-progress new method for making raw requests to rippled in rippled's native websocket format. That method, and the subscription event handling, are not final right now and not really documented yet (to my knowledge) outside of the stuff you see on GitHub. I did (just now) update the RippleAPI docs on https://ripple.com/build/rippleapi/ for v0.19.0, which includes Checks functionality.
  15. mDuo13

    Ripple Data API v2 rate limit

    I don't think the Data API v2 has formal rate limits right now. I've overheard that the Ripple data team has had problems with some people/businesses taking advantage of that, so we're likely to impose proper rate limits in the future. And yes, the rate of "OfferCreate" and "OfferCancel" type transactions definitely outstrips the rate of "Payment" transactions in the XRP Ledger. I think that's mostly a nature of the beast; trading is kind of speculative and freeform while payments generally only happen when you need to move your money from one place to another. Especially since there aren't many merchants who accept XRP (Ripple has not exactly pursued that use case so far), there's not as many opportunities to pay people.