Jump to content


  • Content count

  • Joined

  • Last visited

About riptidel

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Upstate NY
  • Ripple Address
  1. This is false. Patent Claims are prioritized by filing date, but "prior art" is not just limited to filed patents: https://en.wikipedia.org/wiki/Prior_art#Duty_of_disclosure https://www.uspto.gov/web/offices/pac/mpep/s2128.html An example from the gov website: "A THESIS PLACED IN A UNIVERSITY LIBRARY MAY BE PRIOR ART IF SUFFICIENTLY ACCESSIBLE TO THE PUBLIC" ---- In any case, I'd be interested in hearing more as this story develops. I'm curious as to what JP Morgan's angle is. Their legal team must know about the prior art & Ripple, so I'm guessing this is more of a negotiating tactic than anything else. After all JP Morgan has far more legal resources and $$$ at hand than Ripple does, this may be an attempt to force Ripple to waste precious resources fighting this or negotiate with the bank with favorable terms, especially at this critical stage of the game. JP Morgan has been doing this as long as they existed, trying to "influence" inventors and small businesses through patent and other litigation is not new to them.
  2. riptidel

    Greetings from Upstate NY

    Hello! Long time xrpchat lurker, finally began posting in the last month (mostly technical questions and such). Big XRP fan, I have experience with the three big boys of the crypto world (BTC, ETH, XRP) and XRP is definitely the best (fastest, most transparent, etc). I also take issue with the "centralized" notion, anyone can run a validator and vote on amendments, not to mention that any deterrence from the "group think" mentality of other coins is heavily ostracized by those communities (just look at BCH...). That being said I have nothing against BTC/ETH, and have to give those much credit for getting crypto this far (it's just time for XRP to take over 😀) In any case, I'm here in part to advocate a network monitor / statistical analyzer I'm working on called Wipple. Basically it's a mechanism through which one can follow and independently audit the XRP ledger. The project is still in it's early stages, but much headway has been made, and I'm currently using it to run hourly/daily/weekly/monthly reports of network activity (see the website for those). It is "open source" but not "free software" as I'm looking to monetize it at some point, I recently left my 11+ year job as a software engineer at a major tech corporation to work on this full time, and need some sort of income to pay the bills! I'd like to make it free software eventually though, once a revenue stream has been established. That being said, I'm looking for contributors, who are interested in sharing the work, but also any profits that may come from it down the line (though don't enter this assuming guaranteed profits, there are still many '???' between then and now). Ideally we would be able to collaborate in person or via video chat, things are so much easier that way, but I'm willing to work with anyone with a positive attitude and willing to work hard to make their dreams happen. If you're interested just shoot me a PM or reply here and we can discuss collaboration ideas further. In any case, great to see all the awesome activity on these boards and am really excited in seeing the XRP community grow!
  3. As a followup here is the Wipple PR modifying the code to check the ledger sync status and close / reopen the socket: https://github.com/movitto/wipple/commit/a48416005ae385dfa778fd40f034b2073b2e4323 I am using the Ruby websocket-client-simple library for this: https://github.com/shokai/websocket-client-simple Though a PR is needed for that to work: (connection needs to be established in a non-blocking manner) https://github.com/shokai/websocket-client-simple/pull/23
  4. So I spent some time investigating a solution to this issue. Took me all weekend (though partly due to other priorities, why can't I code 24x7?! 😀) I _believe_ the issue is due to the rippled server restarting the listening sockets when it gets swamped. This seems to be the case as in my rippled log I periodically see messages similar to "Server:NFO Opened 'port_wss_public' ... " after many "View of consensus changed during establish status" and "By the time we got XYZ no peers were proposing it" messages. The websocket library I am using did not gracefully handle this sort of situation (it wasn't detecting the socket close, perhaps rippled is not gracefully closing it or perhaps it is due to a socket timeout which did not elapse or similar). In any case to work around this I implemented the solution describe above. Employing a 'monitor' thread, I simply wait the amount of time we 'expect' a ledger to be closed / validated (plus a grace period) and then manually close / reopen the server connection. It may fail a few times as the server connection is not open right away and ready but by retrying the operation until success, we are able to reconnect and subscribe to the new ledger stream. Yes it's a bit of a hack and not the most elegant solution, but it works for now! Hope this helps anyone in the same situation. Any additional thoughts / analysis would be more than appreciated (especially from those who are "more in the know" wrt rippled internals). Happy hacking!
  5. Hello everyone and happy Friday! I have a quick question WRT to subscribing to various streams via rippled: https://ripple.com/build/rippled-apis/#subscribe I'm running a very lightweight rippled instance on a VPS, where I'm periodically seeing the warning "View of consensus changed during establish status=establish, mode=wrongLedger". I chalk this up to limited resources on the server (it does satisfy the minimum requirements for rippled but barely) resulting in it not being able to keep up with the network. It's not a huge deal though as it almost always resumes normal operations in < 1min. During this time client queries via the websocket return InsufficientNetworkMode: {"error"=>"noNetwork", "error_code"=>17, "error_message"=>"InsufficientNetworkMode", "id"=>1, "request"=>{"command"=>"ledger", "expand"=>true, "id"=>1, "ledger_index"=>"validated", "transactions"=>true}, "status"=>"error", "type"=>"response"} Again this is not a big deal as I can detect this and connect to an alternate server (s1.ripple) or just wait, but I noticed that no such information is coming across an established subscription. Specifically when I issue the 'subscribe' command with 'streams' set to ['server', 'ledgers'] I see ledgers until the consensus event as described above, after which point I do not see any more messages (not even the InsufficientNetworkMode). Even the server resumes it's activity in the interim, no more messages or ledgers are received and the subscription connection sits idle. So my question is, is there any way to detect this issue from an existing subscription stream, outside of waiting for the 'expected' time a new ledger comes and if it does not, try disconnecting / reconnecting until the next one is received? Any help would be much appreciated
  6. Cool, that's what I figured. I'm using the v2 api for a few things (it's defintely convenient) but prefer to rely on querying my own rippled instance for data when possible. Afterall ripple labs have states that their rippled instance + v2 api are made public in "good spirit" though should not be queried heavily (afterall the xrp ecosystem is p2p so it's best to use that!) Thanks for the response. I figure the only way to distinguish between new issuances and regular trading activities for gateways that _don't_ conform to the opsec (eg use the same address for both) would be to monitor their transaction stream, then check there balances on activity for changes in non-xrp amounts. If any issued by the address are different, one can conclude that those are new issuances / remmitances (correct me if I am mistaken or if there is an easier way).
  7. Good day, I have a quick question with regard to gateway addresses (I apologize if it has been asked before). According to the ripple documentation: https://ripple.com/build/gateway-guide/#liquidity-and-currency-exchange My question is: Does the rippled software have any technical limitation prohibiting an issuing address from one that can creating offers / etc? And if so is this restriction enforced at the transaction level? (eg do not accept offers from this address as it is an issuer or do not allow address to become an issuer as it has outstanding offers). I ask because I am developing some XRP analysis software myself (http://wipple.devnull.network/) and currently am tracking new gateway issuances (and those that are redeemed) by monitoring gateways payment transactions in non-xrp currencies. If rippled allows gateway issuing addresses to perform other activities outside of this (or if it does not verify this at the transaction level incase of bad actors who modify the code) then the issuances / remittance statistics collected could be skewed. Appreciate any info
  8. Does anyone have a video? 😄
  9. riptidel

    Wipple XRP Report: Week of 2018-05-07

    Awesome, thanks for the feedback everyone, and appreciate the donation. . I've recently left my full time engineering job at <major tech corp> (nearly 12 years there!) to work on this and similar technologies full time so every bit helps! Be sure to regularly check the site, I'm currently expanding the stats generated and plan more exciting features in the near future!
  10. Wipple XRP Report: Week of 2018-05-07 Generated using the Wipple XRP Analysis Framework (donations are appreciated, see the report for how to contribute!)
  11. Just wanted to shout out with a quick update of the progress done in the last few weeks since the initial announcement. First and foremost, the project has been renamed to Wipple and can be found at http://wipple.morsi.org/ Besides bug fixes and UI improvements, ledger integration has greatly been expanded in the latest release, with versions and transactions being persistently tracked. The UI currently renders the cumulative sum of recent payments send in different currencies across the network. In addition to this, validator benchmarking has been added, with backed workers periodically pinging registered validators for response time, and long term performance reporting and tracking on the roadmap for the near future. The current results are rendered in the UI though we aim to provide options to run reports for offline access at some point. There are also many more various tweaks and additions which can be found in the project repo. Stay tuned for more updates!
  12. @tulo yes, it simply dispatches to the official ripple-lib using nodejs. Figure that is the best / simplest solution until a native solution has been thoughourly vetted. @zenkert I was actually going for a retro theme with this one. Afterall everything 80's is cool these days! I agree that some users will have different requirements and need a UI and/or Web Interfaces. This implementation targets power users who are looking for a simpler stack (one with less potential attack vectors). That being said, I'm not adverse to different frontends either, perhaps a generic wallet management / chain analysis framework with pluggable frontends would be a cool way to go! Thanks for the feedback so far, looking forward to what's coming! -Mo
  13. Guilty until proven innocent? :-D All the source code is on my personal github for audit, plus it's pretty easy to see who I am from there. - Mo Morsi (professional computer engineer living /working in NY) http://mo.morsi.org
  14. Greetings and happy Rippling ! Long time lurker, first time poster. I'm pleased to announce the first alpha release of XRRP, the newest XRP wallet on the scene! XRRP is geared to provide a minimalist, user-friendly, XRP Account Manager and Ledger explorer, built ontop of a vetted & hardened stack. http://xrrp.morsi.org What's in the box: - A full-featured XRP Wallet and Key Manager, complete with secure storage and payment mechanisms - Market integration, query for XRP quotes against multiple exchanges / intervals - Ledger explorer - view account distributions, tags, and more - Real time network monitor and status reporting - A powerful and extensible framework which can be used to build custom analysis plugins and remittance applications Why another XRP wallet you might ask? While existing solutions are useful and address various use cases, none provide the security and robustness needed by today's Crypto-[Banker|Trader|Quant]. XRRP is an easy-to use text-based application, built onto of NCurses, a well-maintained interface library with over 30 years of development! This means to manage your funds, you don't need a web browser, you don't even need a graphical user interface, both of which present unnecessary attack vectors for XRP fund managers who are concerned about security (which should be all of them). With XRRP you can interact with the blockchain using the minimal number moving components, while still using a human friendly interactive interface. All of this, while being Open Source ! But a picture is worth a thousand words (see attached) More information can be found at the project website http://xrrp.morsi.org, including complete installation and usage instructions for multiple platforms. The project is still in its early stages and much more development and many new features are on the roadmap so stay tuned!