Search the Community

Showing results for tags 'rippled'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Ripple
    • Please Read Before Posting
    • Press
    • General Discussion
    • Technical Discussion
    • Marketplace
  • Interledger Protocol
    • Interledger Protocol Discussion
  • Other Technology
    • Alt-Coins and Non-Ripple Fintech
  • More
    • Off-Topic
    • Meta
    • Languages

Calendars

  • Ripple Events

Found 16 results
Minimum search term is 4 characters long. Can't find what you want? Click here for the custom google search instead.

  1. I overlaid the RCL validator map from https://charts.ripple.com/#/topology to a map of the US showing major cities and thought it might be fun for everyone to do some speculation. It got more interesting than I anticipated. I know IP mapping isn't 100% accurate but I think this gives some insights and I'm sure others can come up with more. Also, keep in mind the size of the dot indicates the number of connections for that validator. Using Ripple as a control you can see a few validators in the SF area that would represent their connections. The giant dot in Southern Kansas seems to be due to this: http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ The giant dots in southern WA are maybe another IP mapping issue, but I believe there are server farms in that area. The small validator in Boston seems to offer another control as it seems that would be MIT. Seems to be a bit of dedicated processing power near Seattle. Microsoft maybe? Curious about all the power in Dallas/Houston. Look at Washington DC. If there are any positive indicators that Ripple may be the first crypto approved for interbank settlement in addition to the tweets, extensive compliance team, Faster Payments situation, etc. @papa Pointed out that Washington DC has the most connections. I count 6 validators with what looks like more than 2x the connections in the Silicon Valley area. This is obviously the headquarters for the Federal Reserve (I only mention that because of #8). The validators in Dallas/Houston are what sparked my interest in this, but as I fell down the rabbit hole the most interesting thing I've found as I've dug in a bit is that of the 12 Federal Reserve Banks throughout the country, seven of them have validators (SF, KC, DAL, NY, CHI, ATL, BOS). The exceptions are Minneapolis, Philadelphia, Richmond, Cleveland, and St. Louis. Philadelphia does have a validator in PA not too far away, but it wasn't right on the dot. Not trying to make outlandish assertions, but that's interesting! #8 makes me believe there is a decent chance the fed is already watching these tests. How would banks have the confidence to use XRP in live trials if the Fed wasn't watching. Seems to make sense. Also make sense that they would run a validator so they can audit the transactions. You know they want that kind of control and visibility. Also makes sense as to why DC would have more connections by far than any other city. Still curious about Houston, Southern WA and those validators defaulting to Kansas. Any Ripple partners in Houston? That's all I got. Didn't expect to go so crazy, but hopefully you guys enjoy.
  2. Looking at ripple network topology, one can see that there are some nodes whose IPs are not know (i.e. location not know). How did they manage to hide their IP and how to go about doing this for myself? Tried setting peer_private=1 in rippled.cfg file but what it did is made the server respond with "InsufficientNetworkMode", perhaps suggesting that it is not syncing up any more. It would be nice to be able to hide IP from topology page, since there is no need for that if it's only for you. Noticed that straight after setting up a rippled server, there where almost immediately failed attempts to ssh log in from China. Do not have to be a genius to deduce where they got my server IP from...
  3. Hi Folks. I have installed Rippled on my Ubuntu distro AWS m3.2xlarge (26 ECUs, 8 vCPUs, 2.5 GHz, Intel Xeon E5-2670v2, 30 GiB memory, 2 x SSD 80 GiB Storage Capacity) instances. I am just experimenting with Rippled and have limited experience with node.js and C++. What I am doing now is testing the basic rippled commands using $ /opt/ripple/bin/rippled <COMMAND> After I executed the first command using $ /opt/ripple/bin/rippled account_currencies I got the following message "Loading: "/home/ubuntu/rippled.cfg" and nothing happens. I have also updated the rippled.cfg (using vim) with the following command: { "command": "account_currencies", "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", "strict": true, "ledger_index": "validated" } - source: https://ripple.com/build/rippled-apis/#account-currencies No results. Am I doing something wrong? Any help would be greatly appreciated. PS: anyone has a the source code to generate public and secret keys for paper wallet storage? Thanks guys, Closingbell2012
  4. Which type of AWS instance is suitable for rippled (only home research purpose) - getting mixed opinions: 1. t2.2xlarge (Variable ECUs, 8 vCPUs, 2.4 GHz, Intel Xeon Family, 32 GiB memory, EBS only) 2. m4.2xlarge (26 ECUs, 8 vCPUs, 2.4 GHz, Intel Xeon E5-2676v3, 32 GiB memory, EBS only) 3. m3.large (6.5 ECUs, 2 vCPUs, 2.5 GHz, Intel Xeon E5-2670v2, 7.5 GiB memory, 1 x 32 GiB Storage Capacity) 4. g2.2xlarge (26 ECUs, 8 vCPUs, 2.6 GHz, Intel Xeon E5-2670, 15 GiB memory, 1 x 60 GiB Storage Capacity) Thanks folks.
  5. Hello guys, looks like the orderbooks are not being built with offer autobridging. I just validated it at https://ripple.com/build/websocket-tool/# REQUEST: { "id": 4, "command": "book_offers", "taker": "rDb6qVhDdAybg9ARF2Yy64AAdk17Bi4M2q", "taker_gets": { "currency": "BTC", "issuer": "rKxKhXZCeSDsbkyB8DVgxpjy5AHubFkMFe" }, "taker_pays": { "currency": "BRL", "issuer": "rfNZPxoZ5Uaamdp339U9dCLWz2T73nZJZH" }, "limit": 3 } RESPONSE { "id": 4, "status": "success", "type": "response", "result": { "ledger_current_index": 29005704, "offers": [ { "Account": "rwSrs1WCfRZPaPx7tqHToQFqyjobMPrgkJ", "BookDirectory": "A183825144B5D679B197CDCDA3E44DDF14F55F3591AF0C58580DBB55D3F68000", "BookNode": "0000000000000000", "Flags": 131072, "LedgerEntryType": "Offer", "OwnerNode": "0000000000000001", "PreviousTxnID": "9744DED4BB1833AAC463D8CC3BD29D028097A7738AE4F925A416186F6660D743", "PreviousTxnLgrSeq": 29005673, "Sequence": 34535, "TakerGets": { "currency": "BTC", "issuer": "rKxKhXZCeSDsbkyB8DVgxpjy5AHubFkMFe", "value": "0.512" }, "TakerPays": { "currency": "BRL", "issuer": "rfNZPxoZ5Uaamdp339U9dCLWz2T73nZJZH", "value": "1978.957824" }, "index": "0D60320194196138FC5D16723DF35AD1628ECA57B9C99C8051502DB39FE36C14", "owner_funds": "1.327867740457333", "quality": "3865.152" } ], "validated": false } } Charts:
  6. HI there! I'm trying to build a stock RippleD Server on CentOs 7 and I'm facing some issues. RippleD is up and running as a Linux Service, but strangely I'm unable to connect via the WSS interface... I receive a 403 error! Please note that when using WS it works perfectly but I would like to use WSS for security reasons. RippleD Config: validators.txt RippleD Log: NodeJS program that is trying to connect to RippleD: NodeJS Log: Do you guys have any clue what I'm doing wrong? Why the hell am I receiving a 403? Thanks a lot for your help!!!
  7. https://ripple.com/dev-blog/rippled-0-50-0/ And we're planning on voting for TickSize and SusPay so that both get enabled on Feb 21.
  8. When running rippled on Centos 6 using the yum package, you may encounter this error: Or something to the effect that 1024 file descriptors are available and 4096 were requested from rippled, so it shut down. To fix this error, open /etc/security/limits.conf and at the bottom of the file add: Next, open /etc/sysctl.conf and at the bottom of the file add: Run ulimit -Ha to check if open files has been updated to 10240, such as: Execute service rippled start and it should operate correctly.
  9. Background Originally, the FlowV2 amendment was planned to replace rippled’s payment processing engine with a more robust and efficient implementation. It was previously expected to become active on Wednesday, 2016-08-24. FlowV2 Was Vetoed The rippled team found a flaw in FlowV2 while testing. As a result, the Ripple network has vetoed the new payment engine amendment. A corrected version of the payment processing engine has been created and is now undergoing further testing. It is scheduled to be included in a future version of rippled as an amendment called Flow. This demonstrates the robustness of Ripple’s amendment process. The review period and governance code with vetoing work as intended. Action Recommended No action is currently required. However, Ripple recommends that validator operators also veto the FlowV2 amendment to ensure it does not regain a majority. To veto the amendment, add the following, single line, under the [veto_amendments] stanza to the rippled.cfg file on validators: 5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 FlowV2 Learn, Ask Questions, and Discuss Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing: https://ripple.com/build/ Other resources: The Ripple Forum: https://forum.ripple.com/ The Ripple Dev Blog: https://ripple.com/category/dev-blog/ Ripple Technical Services: support@ripple.com
  10. The FlowV2 Amendment is now open for voting. This amendment replaces the payment processing engine with a more robust and efficient rewrite called the FlowV2 engine. The new version of the payment processing engine is intended to follow the same rules as the old engine. However, the new engine occasionally produces different results due to floating point rounding. The FlowV2 Engine also makes it easier to improve and expand the payment engine with further Amendments. Ripple’s validators will vote in favor of the FlowV2 amendment. We expect the new feature to become active on Wednesday, 2016-08-24. Actions Required If you operate a `rippled` server, you should upgrade to version 0.32.1 by Wednesday, 2016-08-24 for the best performance. Note: A previous version of this post incorrectly stated that backend software must be updated to construct transactions for the new payment processing engine. The process of creating and submitting transactions for the FlowV2 payment engine is the same as for the previous payment engine. Impact of Not Upgrading If you operate a `rippled` server but don’t upgrade to version 0.32.1 by Wednesday, 2016-08-24 (when FlowV2 is expected to become available via Amendment) then: Your server will become "amendment blocked" and unable to process transactions or evaluate the validity of ledgers. For instruction on updating `rippled` on supported platforms, see: https://ripple.com/build/rippled-setup/#updating-rippled For other platforms, please compile version 0.32.1 from source. For details, see https://wiki.ripple.com/Rippled_build_instructions Learn, Ask Questions, and Discuss Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing: https://ripple.com/build/ Other Resources * The Ripple Forum: https://forum.ripple.com/ * The Ripple Dev Blog: https://ripple.com/category/dev-blog/ * Ripple Technical Services: support@ripple.com
  11. rippled version 0.32.1 Ripple is proud to announce the release of rippled version 0.32.1, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to version 0.32.1 by Wednesday, 2016-08-24, for the best performance. Highlights of this release include: A new, optional WebSocket implementation based on Beast. See below for details. An improved version of the payment code, which we expect to be available via an Amendment named "FlowV2" on Wednesday, 2016-08-24. See below for details. Actions Required If you operate a rippled server, you should upgrade to version 0.32.1 by Wednesday, 2016-08-24, for the best performance. If you have backend software which constructs and submits transactions to the Ripple network, you need to adapt it to correctly use the network’s new payment engine. Impact of Not Upgrading If you operate a rippled server but don’t upgrade to version 0.32.1 by Wednesday, 2016-08-24, when FlowV2 is expected to become available via Amendment, then your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network. Any rippled server operator running versions prior to 0.32.1, will also become amendment blocked. For supported platforms, see Updating rippled on supported platforms. The md5sum for the rpm is: 5dcdcef01f3cfc452b0b503eaaeb07bb The md5sum for the source rpm is: 3180fca1e83001307346f85628823a9c For other platforms, please compile version 0.32.1 from source. The first log entry should be the change setting the version: commit 1ff972fbd3b82f0f7062f05f64f1abd5e274a7bc Author: Nik Bougalis <nikb@bougalis.net> Date: Fri Jul 29 12:52:26 2016 -0700 Set version to 0.32.1 Network Update The Ripple operations team plans to deploy version 0.32.1 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Thursday, 2016-08-04. The deployment is expected to complete within 4 hours. The network will continue operating during deployment and no outage is expected. Learn, ask questions, and discuss Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing. Other resources: The Ripple Forum The Ripple Dev Blog Ripple Technical Services: support@ripple.com XRP Chat Full Release Notes The rippled 0.32.1 release includes an improved version of the payment code, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name FlowV2, and a completely new implementation of the WebSocket protocol for serving clients. You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source. New and Updated Features An improved version of the payment processing engine, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name “FlowV2”. The new payments code adds no new features, but improves efficiency and robustness in payment handling. The FlowV2 code may occasionally produce slightly different results than the old payment processing engine due to the effects of floating point rounding. Once FlowV2 is enabled on the network then old servers without the FlowV2 amendment will lose sync more frequently because of these differences. Beast WebSocket A completely new implementation of the WebSocket protocol for serving clients is available as a configurable option for rippled administrators. To enable this new implementation, change the “protocol” field in rippled.cfg from “ws” to “ws2” (or from “wss” to “wss2” for Secure WebSockets), as illustrated in this example: [port_ws_public] port = 5006 ip = 0.0.0.0 protocol = wss2 The new implementation paves the way for increased reliability and future performance when submitting commands over WebSocket. The behavior and syntax of commands should be identical to the previous implementation. Please report any issues to support@ripple.com. A future version of rippled will remove the old WebSocket implementation, and use only the new one. Bug fixes Fix a non-exploitable, intermittent crash in some client pathfinding requests (RIPD-1219) Fix a non-exploitable crash caused by a race condition in the HTTP server. (RIPD-1251) Fix bug that could cause a previously fee queued transaction to not be relayed after being in the open ledger for an extended time without being included in a validated ledger. Fix bug that would allow an account to have more than the allowed limit of transactions in the fee queue. Fix bug that could crash debug builds in rare cases when replacing a dropped transaction. (RIPD-1200) Remove incompatible OS X switches in Test.py (RIPD-1250) Autofilling a transaction fee (sign / submit) with the experimental x-queue-okay parameter will use the user’s maximum fee if the open ledger fee is higher, improving queue position, and giving the tx more chance to succeed. (RIPD-1194)
  12. This notice is for all validator operators, and may be relevant to gateways that utilize the Authorized Account feature. The new TrustSetAuth amendment is open for voting now. This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Accounts. With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the other addresses to take action. Without the amendment, currency holders must first create the accounting relationship with the issuer by setting a limit with a TrustSet transaction. Ripple’s validators will vote in favor of the TrustSetAuth amendment, and we expect the new feature to become active by 2016-07-19. For more information, see the following articles in the Ripple Developer Center: Authorized Accounts: https://ripple.com/build/gateway-guide/#authorized-accounts Amendments: https://ripple.com/build/amendments/ To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: https://groups.google.com/forum/#!forum/ripple-server
  13. https://ripple.com/dev-blog/rippled-0-32-0-released/ Ripple is proud to announce the release of rippled version 0.32.0. This release introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to the new version. Highlights of this release include: The transaction queue now supports batching and can hold up to 10 transactions per account, allowing users to queue multiple transactions for processing when the network load is high. This encourages liquidity for XRP since important transactions now have a more reliable way of getting into the ledger. For more information, see Queued Transactions in the Ripple Developer Portal. The server_info and server_state commands now include information on transaction cost multipliers. Customers who want to robustly submit transactions now have additional tools for accurately setting the fee based on changing network conditions. Furthermore, the fee command is now available to unprivileged users. For more information, see the rippled API Method Reference in the Ripple Developer Portal. There’s a new WebSocket implementation based on Beast. Use of this implementation is optional. A future version of rippled will make this WebSocket implementation the default, with the old implementation removed. Read the complete release notes in GitHub. Actions Required If you operate a rippled server, you should upgrade to version 0.32.0 for the best performance. If you have backend software which constructs and submits transactions to the Ripple network, you may need to adapt it to correctly use the network’s new transaction queue mechanism. Impact of Not Upgrading If you operate a rippled server but don’t upgrade to version 0.32.0, your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network. For instruction on updating rippled on supported platforms, please see Updating rippled in the Ripple Developer Center. The md5sum for the rpm is: 1b37fd80fd869e42a715f17a9e30c81a. The md5sum for the source rpm is: d43f4d371416b213d6197fb1c630cf44. For other platforms, please compile version 0.32.0 from source. See rippled Build Instructions in the Ripple Wiki for details. The first log entry should be the change setting the version: commit d22eb0caa25ecfbd373cc9af0347e56031a23646 Author: seelabs <scott.determan@yahoo.com> Date: Fri Jun 24 11:30:09 2016 -0400 Set version to 0.32.0 Network Update The Ripple operations team plans to deploy version 0.32.0 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Wednesday, 2016-06-29. The deployment is expected to complete within 4 hours. Learn, ask questions, and discuss Ripple supported documentation including detailed example API calls and web tools for API testing are located on the Ripple Developer Portal: https://ripple.com/build/ Other Resources: Ripple Official Forum: https://forum.ripple.com/ Ripple Dev Blog: https://ripple.com/category/dev-blog/ Ripple Technical Services: support@ripple.com XRPChat (This forum)
  14. https://ripple.com/dev-blog/multi-signing-will-soon-available/ The multi-signing amendment is currently supported by the majority of voting validators on Ripple, and is scheduled to become active on the protocol on Monday, 2016-06-27. For more information, please see the multi-signing documentation in the Ripple Developer Portal: How to Multi-Sign MultiSign Amendment Information To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: https://groups.google.com/forum/#!forum/ripple-server UPDATE: As of 2016-06-27T11:34:41Z (ledger 22178817), multi-signing is now enabled!
  15. Just today I published the documentation for a bunch of new feature stuff that's coming in rippled 0.31.0. (Right now we're still tracking down the last few bugs in the release candidates, but the feature set is finished and the release will be out probably any day now.) It's been a long road for multi-signing in particular, with the first preview promising that it was "coming soon" as of March 24, 2014. Yeesh! But this time, we really mean it: multi-signing is getting real. We're not... quite... there yet, though, and part of the reason is that 0.31.0 is the first time we're going to truly use the Amendments system for rolling out new network features in a decentralized fashion. This is a big step in our roadmap towards encouraging a decentralized web of trust in the validation network, because it means that the network will be able to smoothly roll out new features without interruptions or a central authority managing them. You can read more about Amendments on the Ripple Dev Center. But! There's one other thing before Multi-Sign happens, and that's an amendment called "Fee Escalation." We haven't talked it up as much, but this change has also been in a long time coming. A while back, you may recall that the cost to send a transaction increased from a typical price of of 10 drops to 10,000 drops of XRP. That's because we realized that, with the network as it was, it had become possible to intermittently DDoS the network without spending a fortune in XRP -- the transaction cost reacted slowly enough to changes in conditions that the network was already in trouble by the time the costs became unbearable. For many months, we've been running our validators with a band-aid fix, with the "load" multiplier artificially cranked up to 1000× in order to maintain network stability. That's why the first Amendment we support will be Fee Escalation -- a change that makes it actually possible to pay a higher transaction cost to make sure your transaction gets processed sooner. Now, when there are a lot of transactions in the current ledger, the server will start queuing up additional transactions for the next ledger instead of trying to squeeze them all in at once -- and the order will be determined by how much XRP those transactions destroy. Not only that, but you can still squeeze into the current open ledger if you pay even more XRP -- but the requirement scales exponentially, so it won't be worth it for long! The long and short of it is that the network should be more resilient against DDoS attacks, while affording more flexibility in the amount of XRP you spend sending transactions (based, presumably, on how urgent your transactions are). With any luck -- and this is not a guarantee, but I'm pretty sure it'll happen -- we'll be able to turn off the artificial "1000×" load knobs and return the minimum transaction cost back down to a truly miniscule amount. See the "Open Ledger Cost" section in the documentation for the details. That finally brings us back to Multi-Signing. It's going to be a few weeks out even after the release gets finalized, so you'll have plenty of time to figure out how it works in order to start multi-signing the instant the feature goes live. In fact, if you're really excited to try it out, you can practice how to multi-sign a transaction using rippled in stand-alone mode. You can also test out other stuff in stand-alone mode, without having to interact with the real network, whether you want to replay old ledgers or test out new features. (Stand-alone mode is not a new feature, but the new documentation should make it much easier to use.) This has been a big project (over 40 commits just to documentation!) and there are a few more changes not even mentioned here. (There might even be some minor improvements to rippled 0.31.0 that haven't made their way into the docs yet.) So, let's not quite declare victory before the release is live -- but get your funny hats and party poppers ready, because version 0.31.0 is going to be a big deal. As always, feedback is deeply appreciated, and I'm glad to offer clarifications for anything that doesn't make sense to you. And, just like rippled itself, our documentation is open-source, so you don't have to be a Ripple employee to contribute!
  16. Rather than continue to derail TWarden's UNL security blanket thread, I decided it would be a good idea to share knowledge and collect information on people's experiences with running rippled. We can see what kinds of specs and settings people have had success or problems with, and go from there. I'll start with my own experience: I have a home desktop PC which I use for my daily computing needs. I built the computer in 2009 and have upgraded it slightly over the years. Since late January 2016, I've been running rippled as a validator more or less continuously. System specs: CPU: 2.66GHz Intel Core i7 "Bloomfield" CPU RAM: 16GB Corsair XMS3 (what can I say, it was a Black Friday sale!) Disks: System partition is on a 80GB Intel X-25M SSD. My rippled's database is on my 2x3TB 7200 RPM disks in software RAID1 using mdadm. I think they're Hitachi-branded? OS: Arch Linux x86_64 (latest Linux kernel, which I've updated a few times in the time I've been running the validator) Network: I'm wired to a cheapo 10/100MBit Netgear ethernet switch and use my house's residential broadband. Settings: I'm using the default settings from the rippled-example.cfg, except for adding my validation seed. The automatic online delete seems to work just fine. Maintenance: Basically, the only maintenance I do is to upgrade to a new version of rippled when one comes out. So far I haven't had any problems with disk space: rippled seems to purge old ledgers often enough to stay within a reasonable amount of disk usage. Usage patterns: I occasionally run RPC commands against rippled for testing / work purposes, but by and large the daemon is dedicated to validating. I do use the machine for my daily computing and I've noticed that the process tends to use up as much RAM as it can when my computer is idle, but it quickly yields it to other programs when I'm actively using the computer. There hasn't been any major adverse effect on my general computing performance. Meanwhile, my validation agreement percentage has been hovering around 98% with few exceptions during that time.