Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by RareData

  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?
  16. A preliminary roadmap is available at: https://gitlab.com/xrptoolkit/xrptoolkit-client
  17. You do know that the Ellipal hardware wallet is airgapped and communicates using QR codes? Your step 1 to 5 above can be simplified, with even higher security, by using a hardware wallet together with the XRP Toolkit.
  18. XRP support for the Ellipal wallet is said to come in Q4, 2018.
  19. Minor adjustments to the roadmap: https://gitlab.com/xrptoolkit/xrptoolkit-client A "Coming soon" landing page is now available: https://www.xrptoolkit.com The next announcement will be the beta release (Postponed from Q3 to October) and made from the official XRP Toolkit account @xrptoolkit. --- Update 2018-09-30: The XRP Toolkit will always prioritize security as #1. Incorporation and our SSL certificate application took longer than expected. We are still waiting for the SSL certificate and have decided to postpone the promised Q3 launch to October. In the mean time, we'll begin implementing Q4 features, perform additional testing with Ledger wallets and stress test our hosting infrastructure. The displayed public keys does not belong to the XRP Toolkit. The displayed public keys does not belong to the XRP Toolkit.
  20. Thanks! If you want to understand our long term vision, imagine a high-security, device agnostic and responsive web application, with plug-n-play capability for the most popular hardware wallets. No registration nor installation needed. An Electron desktop app (.exe/.dmg/.AppImage) or a companion app (iOS/Android) might add value, but there's no definite plans yet. It will ultimately depend on user feedback, as well as if our planned crowdfunding in 2019 is successful. To properly develop and support more than a high-security web application, we need to scale our team first. We aim for a best-in-class web security approach, following OWASP TOP10 recommendations and IETF drafts, utilizing HSTS, DNSSEC, CSP and SRI to name a few. Together with coming multisignature capability, the XRP Toolkit may very well achieve a better security/usability tradeoff than comparable desktop applications.
  21. Bithomp finally replied and has now added most security headers. Their content security policy contains some unsafe directives, but Bithomp.com is now much more secure. The XRP Toolkit is still on schedule for a first beta release in Q3 (September). I'm really looking forward to receiving feedback from you guys and being able to release way more details. The XRP Toolkit will be available at https://www.xrptoolkit.com, once it's ready for release. Multiple login options, account overview, XRP payments, account settings and the UI/UX seen on this screenshot, will be available in the first release:
  22. To accelerate the XRP Toolkit roadmap and increase community involvement, one alternative would be to issue a custom token on the XRP ledger. Is the community interested in increasing the awareness of this XRP ledger feature? Make your voice heard. The ongoing Allvor airdrop features an uncapped supply and the 'No Freeze' flag has not been set by the issuing account. In other words, an infinite amount of ALV can be issued and the tokens can be freezed at will. For example, in the event of compromised secret keys, nothing stops a malicious party from issuing additional ALV or freezing all ALV tokens. There's a much more secure way to issue custom assets on the XRP ledger, utilizing its built-in functionality to cryptographically guarantee a fixed supply: 1. Create a dedicated issuing account and a few operational accounts. 2. Issue a custom token. 3. On the issuing account, set the 'Default Rippling' and 'No Freeze' flags to 'True'. 4. Add trust lines from the operational accounts to the issuing account. 5. Send all issued tokens to the operational accounts. 6. Set the issuing account's regular key to black hole address ACCOUNT_ONE (https://developers.ripple.com/accounts.html#special-addresses) 7. Set the issuing account's 'Disable Master' flag to 'True', permanently giving up account access. This cryptographically guarantees a fixed supply. 8. Distribute the issued tokens from the operational accounts. Suggested Token Use Cases After issuing a permanently fixed supply of XRP Toolkit tokens they could for example be used as: 1. Contributor and bounty rewards. 2. Amendment voting rights. 3. Discounted payment option for paid services like transaction notifications and multisignature services. These are all use-cases independent of XRP adoption, incentivizing community involvement to e.g. translate the XRP Toolkit, have a say in amendment decisions and benefit from an increased token demand.
  23. Just to clarify, I contacted The World Exchange and Bithomp developers to offer my help. Kudos to The World Exchange for adding the most important header, HTTP strict transport security, within an hour! I'm still waiting for a reply from Bithomp and decided to also reach out to Wietse, responsible for the XRP Tip Bot.
  24. For stable v1.0.0, I'm planning to add functionality to submit/broadcast already signed transactions. Would it fulfill your use-case if the XRP Toolkit could read QR images, representing signed transactions? And in offline mode, if you could sign transactions and output QR images?
  25. Thanks!! You mean functionality to read and generate QR images? That's certainly doable for v1.0.0+.
  • Create New...