Jump to content

mDuo13

Ripple Employee
  • Content count

    360
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by mDuo13

  1. mDuo13

    Securing Validators - Nikb

    Good question and to be honest I don't have the answer for you at the moment. I believe Ripple's ops team does some stuff with DNS(?) since s1.ripple.com for example doesn't consistently direct to the same server, but I do not have the technical details yet. I'll be sure that information is in the eventual published article on this.
  2. Ripple's decentralization plan is to find reliable businesses and organizations with a long-term interest in supporting the XRP ecosystem by running validators—or just hub servers that others can use to pass messages around. When those sorts of entities run validators well, Ripple will add them to its recommended validator list. (rippled servers with default settings automatically follow Ripple's recommended validator list.) For every two non-Ripple validators that get added to Ripple's recommended list, Ripple plans to remove 1 Ripple-run validator from the recommended validator list. Running a validator as a third party or individual helps the XRP Ledger indirectly in several ways: It helps set a standard for performance, so we can measure these businesses up to appropriate expectations. By providing feedback on the process, challenges, and guidelines for running validators, we can build more institutional knowledge on how to run a validator properly. The community can, collectively, test many more possibilities than any company can alone. Whether it's hardware specs, hosting providers, configuration settings, or network architectures, the more things the community tries out the more specific we can recommend things to businesses to reduce uncertainty and smooth out the process. As a corollary to this, if you run a validator, you should talk about your experience! What did you do? What hardware and operating system did you use? What went wrong or was confusing? How'd it go? If you stopped, why? If you're still running one, what kind of metrics have you collected from it? Honest, properly operating validators provide a backdrop for detecting dishonest or buggy behavior in validators.
  3. mDuo13

    Securing Validators - Nikb

    Thanks for highlighting it! Also, I've been meaning to do this for ages, so here, I tossed together a (rough) network diagram of what it looks like to configure public facing servers as a proxy in front of a private peer validator: In addition to speaking peer protocol to the outside network, your servers may or may not have a port for rippled API access. Obviously, don't expose an admin interface to the world at large. Your validator probably shouldn't expose any API access to the outside world. (You probably want admin access on localhost so you can debug/admin the server from an SSH session or whatever.) The load balancer and multiple clustered public facing servers are optional. You can also do a simplified architecture with just a single rippled server speaking through the firewall to the outside world. Peer protocol is a binary protocol so HTTP(S)-only load balancers won't be able to handle that. Anyway, this isn't thoroughly reviewed or official, so take the appropriate precautions. There will be an official version eventually.
  4. How does Heleum know which currencies are appreciating and how long those currencies are going to continue to do so?
  5. mDuo13

    New Ripple developers' site

    Yep, we worked very hard on putting developers.ripple.com together. (Pretty soon, ripple.com/build will be replaced with a redirect to the new site.) That introduction to the XRP Ledger article has been around for a while (published https://ripple.com/build/xrp-ledger-introduction/ back at the beginning of March) but the new site gives us a much better opportunity to highlight it By the way—if you see anything buggy-looking, or if there are technical areas you'd like to understand better, let us know. We're here to help! We've got some ideas already on what needs documenting, but feedback from the community certainly helps us calibrate our priorities. Here's to another great year for XRP!
  6. It's probable that any confusion on whether xRapid can use non-XRP currencies is a result of the product evolving over time. There was a beta of xRapid that could use BTC instead of XRP as an intermediary currency. It worked OK, but BTC didn't offer much price advantage, and having multiple intermediary currencies added some complication and limitations so we've since removed the ability of xRapid to use BTC as an intermediary. As it exists today, xRapid always uses XRP. It's not fundamentally required to be that way, but XRP works best so that's how it is at the moment. In contrast, xCurrent uses whatever (generally fiat) currencies the institutions hold in their systems already. It's about orchestrating atomic swaps between two or more institutions. The "or more" is important there as that's where you may find future-xRapid appear as an intermediary in an xCurrent-powered transaction.
  7. I'm happy that Zagone didn't fall for Mr. Walker's provocations, and kept his cool. That's part of the Ripple brand, strategy, and ideals: calm, humble confidence and fundamental strength built from cooperation and measured, rational thought. Ryan Zagone is a consummate professional and I'm proud to be working on the same side. Also, this first post would be easier to follow if you made it clear precisely what video you were referring to. Maybe you should include a link to the actual talk?
  8. 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)
  9. 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.
  10. 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!
  11. 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.
  12. 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.)
  13. mDuo13

    tefALREADY

    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!"
  14. 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.
  15. 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?
  16. 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.
  17. 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.
  18. 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.
  19. 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).
  20. 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.
  21. 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.
  22. 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.
  23. mDuo13

    Personal Validator / Server

    You may want to do some more reading. Adding a validating server wouldn't impact TPS positively. (I believe the main limits on TPS are disagreements between servers, and the slowest trusted validator's time doing things like verifying signatures... assuming the trusted validators all have sufficient I/O to meet their needs.) Most likely, adding a new validator will have no effect, although it could in theory decrease TPS by increasing the communication overhead with the other servers on the network. Right now the XRP Ledger isn't that close to capacity on throughput, though, so the easiest way to increase TPS is by... sending transactions. Right now, most people who're running their own rippled server are either businesses like exchanges that offer XRP, or individuals running arbitrage bots to trade in the decentralized exchange that's built into the XRP Ledger—or trade in off-ledger exchanges and bridge the gaps between them. (I know there are least a couple people who make a tidy income doing that kind of stuff.) I'd love to see more creative, interesting uses of the XRP Ledger. If you're a data scientist, you may want to look at the Data API and see if the stuff they're collecting interests you. That code's mostly open source, so you can even run your own historical database if you want to pull the data locally and analyze it yourself (although I think some of the import scripts for certain types of data are closed-source).
  24. mDuo13

    Could you imagine the fudstorm if...

    Hey, curing (one person's) hunger and ending (one person's) homelessness are real problems. They're just, you know, small scale. That said, I don't know of any big real-world problems that can be fixed with quantum computers. There probably are some, but it may be that nobody has figured out yet what problems really need quantum computing algorithms, outside of some cryptography things. Right now, the really fascinating thing about computer science is that most problems are about figuring out what approach can achieve the outcome you want with the fewest unexpected consequences, not so much about how to make things go faster. For better or for worse, it's become as much about figuring out humans as figuring out math.
  25. The quorum and the UNL overlap are different (albeit related) things. The overlap is something like, "If my UNL has validators A through J and your UNL has validators C through L, then we have 80% overlap (8 validators in common out of 10 each)". The quorum is, "If I see 8 of my 10 validators declare a consensus for ledger 100, then I'm declaring ledger 100 validated". These papers don't change the rules for the preferred quorum, which remains at ~80%. They do change the expectations for overlap (topology) requirements though. The disappointing result of this consensus research is that a fork between two rippled servers is technically possible if the UNLs of those servers, or the UNLs of the validators they trust, don't all have >90% of the same trusted validators in them. When the original Ripple consensus whitepaper was published, its authors thought that servers only had to have >40% UNL entries in common with one another. What they failed to account for was the possibility that a malicious validator could send contradictory messages to different servers. The peer-to-peer network broadcasts messages between a bunch of servers (even non-validators pass on messages) so the original authors thought you would easily notice that a validator was acting maliciously if it sent contradictory messages to different parties. The standard rule in the research is that you may not notice this because the unreliable network might drop the contradictory messages in such a way that the contradictory messages don't both reach you, or the network could delay some of the contradictory messages long enough that you don't realize there's foul play going on until it's too late and you've already taken action. In short, when network conditions are bad, the UNL topology has to be a lot more interconnected than we thought, or malicious actors could cause a fork. The good news is: first, the current plan, using a validator registry (the list site), is safe, because anyone using the validator registry has 100% overlap with everyone else who's doing the same. (It makes it harder to open things up to multiple validator registries, though—if those registries don't have >90% of the same entries on them, then forks would be possible.) The other good news is that we (well, mostly Ethan) have come up with a new algorithm called Cobalt that only needs >60% overlap and also has some other neat properties, like that you don't have to worry so much about the UNLs of the servers in your UNLs.
×