Jump to content


  • Content Count

  • Joined

  • Last visited


About RareData

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Occupation
    Software Developer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It's only "critical" in the sense that Chrome 72 broke support for U2F, so if you updated your browser, your Ledger, Bitbox, Trezor, Secalot etc. would timeout incorrectly and not work with a few interfaces like XRP Toolkit and MyCrypto. As the new browser and old firmware was no longer compatible after Google's update. That's it. Source: https://support.ledger.com/hc/en-us/articles/360018810413-U2F-timeout-in-Chrome-browser
  2. This is ridiculous... Why don't you just generate a 24 word seed and derive an XRP account/secret "to deposit your XRP" manually. Why on earth would you buy a Ledger Nano S just for deriving an account and then destroy the device? If you take a look at this infographic: https://developers.ripple.com/set-up-secure-signing.html#use-a-dedicated-signing-device You'll see that hardware wallets are meant to be used, not just collect dust. They are literally the only way to achieve trustless transaction signing, without having to trust a computer or phone. Sooner rather than later, you'll e.g. be able to set trust lines (participate in airdrops) and trade on the DEX using your Ledger device. Like everything else with embedded software, including your home router, its firmware should be updated regularly. For hardware wallets, this is to protect against newly discovered vulnerabilities requiring physical access to the device and specialized lab equipment to exploit. Yet, Ledger always patches them, despite their incredibly low probability of affecting anyone. Compared to a software wallet, if your computer or phone with a much larger attack surface is compromised, any running software wallet would be compromised too. Your hardware wallet remains secure, even when connected to a compromised computer or interface. That's part of their security model and the only reason to use one in the first place.
  3. You might be interested in the XRP Toolkit roadmap: https://gitlab.com/xrptoolkit/xrptoolkit-client I really appreciate user suggestions and feedback, feel free to reach out afterwards.
  4. Well, here go you Bob, let me know what you think: https://medium.com/xrp-toolkit/on-a-mission-to-fix-the-lacking-hardware-wallet-xrp-support-f458d962768d
  5. RareData

    Hi! I'm Bob

    Well, here go you Bob, let me know what you think: https://medium.com/xrp-toolkit/on-a-mission-to-fix-the-lacking-hardware-wallet-xrp-support-f458d962768d
  6. RareData

    Hi! I'm Bob

    I'd argue that the lack of hardware wallet support is a major contributor to the slow XRPL DEX adoption. Now that there's U2F/WebUSB and soon Bluetooth support in the major browsers, users can use DEX interfaces in a plug n' play fashion without installing anything (and without trusting the DEX interface with their secret). Ethereum users have had Mycrypto.com and MyEtherWallet.com (millions of users) with proper hardware wallet support for a long time. Binance DEX is executing on something similar for their native chain, working with hardware wallet maker Ledger from day one, enabling user-controlled hardware wallets interoperable with their non-custody, feature-rich DEX interface. Don't you think Ripple and the likes of Coil/Kava/Strata Labs/(...) would benefit from hardware wallet multisigning and escrow support? Don't you think it would enable a much better usability/security tradeoff for DEX interfaces with hardware wallet support for order transactions?
  7. RareData

    Hi! I'm Bob

    Bob, you're a star! This confirmed my hypothesis that the brightest at Ripple are aware of this issue and that PolySign is related to the problem of low XRP hardware wallet support. I'm doing what I can to change this, starting with implementing full XRP support together with Secalot (open-source software and hardware) and then going for Ledger/Trezor/others. It's 2019, we should be able to multisign using multiple hardware wallets, sign escrows, trust lines and IOU payments by now... Do you have any additional thoughts on XRP hardware wallet support?
  8. For fiat or for crypto? In a lot of jurisdictions, acting as a money service operator or stored value facility for fiat would require a multimillion dollar share capital (legal requirement). Crypto should be more low-hanging fruit, as long as the coins/tokens are not seen as money nor securities.
  9. Ripple has nothing to do with the XRP Toolkit. The linked article is terribly poor written, by someone completely oblivious. It would've been much easier to simply reach out to me, like @Hodor and @xrptipbot do when they want info ☺ You go to the source, you don't make things up like that article's author seems to have done.
  10. Your linked article is full of misinformation. "RareData also mentioned that the next XRP Toolkit release could include log-in options with seaclot (a QR code reader)." Secalot is a QR code reader? It's a hardware wallet... I have not said this. This author just lost all credibility, treat accordingly. "By improving the XRP Ledger." The XRP Toolkit is not trying to improve the XRP ledger at all... It's already incredibly good. The XRP Toolkit is merely trying to provide an equally good interface to it.
  11. We work hard with trust minimization, use a hardware wallet and the client-side interface won't see any sensitive data at all.
  12. We'll release the source code shortly
  13. Oh I see. Maybe because the entity combining the signatures, may not be the same as the signers?
  14. Well, according to https://ripple.com/xrp/market-performance/ the XRP ledger is currently processing 4.75 transactions per second (out of the 1500+ possible), so we need to see a 31478% TPS increase before it becomes a problem. More about transaction queueing: https://developers.ripple.com/transaction-queue.html.
  15. How come you find the Ripple API way "a work around"? From my point of view, using https://developers.ripple.com/rippleapi-reference.html#sign together with the options.signAs should fulfill your use case?
  • Create New...