Jump to content

RareData

Member
  • Content Count

    35
  • Joined

  • Last visited


Reputation Activity

  1. Thanks
    RareData got a reaction from Trisky in [AMA] XRP Toolkit: Project Goals & Roadmap   
    To encourage early community feedback, I'd like to introduce you to the XRP Toolkit, project goals and roadmap.
    Background
    When looking for different options to conveniently adjust wallet settings, trade on the decentralized exchange and escrow XRP, I found a few pioneering web tools like The World Exchange and Bithomp.
    With a background in cybersecurity and secure software development, I found it unacceptable that very few were using security headers like HTTP strict transport security (https://tools.ietf.org/html/rfc6797) and DNS security extensions (https://tools.ietf.org/html/rfc4033). In other words, the developers are either unaware or simply not doing everything in their power to protect their users against e.g. man-in-the-middle, clickjacking, cross-site scripting and DNS spoofing attacks.
    You can verify what security headers your favourite exchange uses with e.g. securityheaders.com:



    You can verify if DNSSEC is properly setup for your favourite exchange with e.g. dnsviz.net:
    After reaching the conclusion that a more secure and user-friendly XRP ledger interface was needed, I began developing the XRP Toolkit with security as the highest priority followed by user-friendliness. A summary of security related design choices can be seen below:
    Client-side transaction signing, sensitive data never leaves the browser. Hardware wallet integrations, sensitive operations can be performed inside the hardware wallet itself. Extensive server hardening with strict use of security headers. Compulsory HTTPS for all endpoints and enabled DNSSEC for all name servers. Hardware Wallet Integration Demo
    I recently published some early proof-of-concept code, showcasing how Ledger hardware wallets can be used to securely send XRP payments from browsers, which was quickly picked up and covered by Hodor on the XRP community blog (https://xrpcommunity.blog/enjoy-your-summer-the-xrp-ledger-is-always-working/?
    Project Goals
    After releasing the demo application, I've continued to develop the first version of XRP Toolkit and setup three major project goals:
    1. Accelerate XRP mainstream adoption, by releasing a secure and user-friendly web interface, providing convenient access to the full feature set of the XRP ledger.
    2. Encourage learning and XRP ledger experimentation, by making the test net more accessible.
    3. Enable multisignature coordination and high security use-cases, by implementing transaction notifications and hardware wallet support.
    GUI Mockup/Prototype

  2. Thanks
    RareData got a reaction from AlexJohanson in Ripple acquires Swedish Startup TOWO Labs   
    Enough to cover Towo Labs expenses for ~2 years. 
  3. Like
    RareData got a reaction from XRPboi in 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?
  4. Like
    RareData got a reaction from Malloy in Suggestion: Deletable Accounts   
    For code simplicity and reducing the risk of severe harm to the XRP ledger, in case the audit does miss something, I strongly suggest the account has to do a full cleanup. If the intention is to delete an account, the owner typically wants to recover locked XRP above the minimum account reserve anyway.
  5. Like
    RareData reacted to JoelKatz in Suggestion: Deletable Accounts   
    The 20 XRP reserve requirement has proved to be a bit of an obstacle to some use cases for the ledger. This proposal would provide a path to delete existing accounts, recovering all but one incremental reserve (currently 5 XRP). This would also allow owners of unwanted accounts to clean them up and recover approximately 15 XRP in the process.
    There is a judgment call involving what to permit an account to have and still be deleted. In principle, you could allow an account to be deleted regardless of what ledger objects it owned and clean up any problems after the fact. For example, if code later encountered an order, trust line, or escrow for a non-existent account, it would simply handle it appropriately at that time. Orders, for example, would be deleted when discovered to be orphaned. However, that’s probably not optimal. It’s probably sensible to require that some amount of cleanup be done prior to allowing an account to be deleted.
    In addition, all code that looks up accounts for trust lines, offers, escrows, and the like must be carefully audited to ensure it sanely handles a non-existent account. Due to the severe harm aberrant behavior could cause to those relying on the ledger, this audit is essential even if the implementation intent is that an account cannot be deleted while those objects exist.
    There is a standard draft for this suggestion: https://github.com/xrp-community/standards-drafts/issues/8
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
  6. Like
    RareData reacted to mDuo13 in Suggestion: Deletable Accounts   
    The public spec defines a transaction that the account owner sends, which tracks down everything tied to the account that can or can't be deleted, and does that if possible. I think that's a great approach. (Actually, the spec itself is just fantastic work. Thanks especially to Scott Schurr for putting a ton of research effort into the thing.)
  7. Like
    RareData reacted to richxrp in Suggestion: Light Accounts   
    My personal opinion is that it over complicates matters in what should be a simple mechanism designed to prevent spamming the network.  The reserve should be set at a level which is just low enough to fulfill it's intended purpose but not so high as to be too onerous to open an account. 
    Also in keeping to a simple design philosophy,  if all accounts were to follow the same rule, it adheres to the KISS principle  ... Keep it Simple and Stupid..
  8. Like
    RareData reacted to mDuo13 in Suggestion: Light Accounts   
    It's a neat idea, but I'm not looking forward to trying to explain the difference between Light Accounts and full accounts. I think I'd rather lean towards finding ways to reduce the resource consumption of full accounts, so that there aren't extra barriers to entry for expanding from basic XRPL usage to more advanced stuff. Making full accounts deletable is a good start, and probably some updates to how we cache things in memory could improve it further. Plus maybe letting the shard store handle more things.
  9. Like
    RareData reacted to JoelKatz in Suggestion: Play Forward Ledger   
    Currently, when a server loses sync with the network, it has to simultaneously try to re-synchronize with the network and fetch all the ledgers it missed. The current design requires the server to first synchronize with the network and then work backwards to fetch what it missed but then work forwards to rebuild any missing intermediary ledgers.
    We propose that the design be changed to support a fetch operation that fetches a ledger’s header and all the transactions in the ledger in order. This will allow a server to play forward from the preceding ledger to the queried ledger with minimal network traffic. When a server loses synch, it can then collect validations to determine the ledgers it needs to go forward from its last-validated ledger to the current ledger.
    This has three advantages. First, it provides greater protection from hostile majority attacks because the server only obtains full ledgers by building them locally. Second, it allows the server to conserve network and CPU resources by only having to play the ledgers forward, rather than backwards and then forwards. Third, it reduces the load the server places on other servers and permits it to stop being a burden and resume helping other servers more quickly.
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
     
  10. Like
    RareData reacted to JoelKatz in Suggestion: Two-layer Consensus   
    Today, the network uses a single consensus process to both make forward progress from ledger to ledger and to coordinate network rule and fee changes. Because the consensus process provides a high degree of decentralization, it has some trade-offs in performance, traffic levels, and the number of validators that can be tolerated.
    We propose to switch to two separate consensus layers. One would exclusively advance the ledger. The other would handle fee changes, coordinate rules changes, and manage the participants in the first layer.
    With this design, a small set of validators selected by the larger set of validators would ensure the network makes reliable forward progress and does not engage in censorship. The larger set of validators would police the smaller set to ensure they are in fact making progress and are not censoring. Any validators in the small set that are not behaving would be voted out by the large set.
    This design has a number of advantages. The network can continue to make forward progress so long as either consensus layer is working. The set of validators preserving decentralization can be made larger without increasing the amount of work that must be done to generate each new ledger. Poorly-performing validators can continue to help keep the ledger decentralized without slowing down the advancing of the ledger. Validators engaging in censorship or poor service could not affect the advancing of the ledger as they would be voted out by the larger set.
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
  11. Like
    RareData reacted to JoelKatz in Suggestion: Investigate/reduce memory consumption   
    The XRP Ledger software does use quite a bit of memory. This is especially a problem on virtual machines where memory has a significant cost premium. Reducing the memory consumption would reduce the cost to run the software and improve decentralization indirectly.
    Unfortunately, we do not precisely understand how the memory is being used. An important first step would be to analyze the software’s memory consumption to see what areas of improvement would be likely to produce the most dramatic results. On the bright side, because this hasn’t been well-studied, it’s possible that there’s some low-hanging fruit where small efforts could bring large payoffs.
    The software does do a lot of caching. For example, some data is cached both in raw binary form (typically as SHAMapEntry objects) and in object form (typically as an STObject). It may be sufficient to cache only in binary form and convert to object form as needed.
    In addition, the SHAMap design pegs lots of SHAMapEntry objects into memory. This design could be changed to only keep SHAMapEntry objects in the cache and fetch them from disk as needed. Code changes would be needed to prevent SHAMap’s from keeping too many strong pointers to SHAMapEntry objects.
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
  12. Like
    RareData reacted to JoelKatz in Suggestion: Logging and Monitoring Improvements   
    The XRP Ledger has both statistics reporting and logging by category and severity. However, it has been neglected for some time. The statistics reporting could use a refresh to ensure that it is capturing parameters that are useful and valuable and to add monitoring of newer features that were added without such reporting. The logging needs a thorough audit to ensure that priorities are set appropriately and overly-chatty logging is disabled by default.
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
  13. Like
    RareData reacted to JoelKatz in Suggestion: Transaction Fee Tracking   
    It can sometimes be difficult to choose the right fee to pay for an XRP Ledger transaction. A common approach is to pick a value known to be large enough, such as .0001 XRP, and just using that all the time.
    We propose adding code to the server to keep track of when a transaction is first observed and what fee level it chose to pay. Then, when the transaction is seen in a fully-validated ledger, the server can update its statistics for transactions at that fee level. Thus the server could report, at any time, the fraction of successful transactions and the average confirmation time for various fee levels.
    In addition to being useful for choosing the fees to pay for a transaction, this would also gather interesting statistical information.
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
  14. Like
    RareData reacted to JoelKatz in Suggestion: DeFi Support Enhancements   
    Some enhancements could be made to the XRP Ledger to provide better support for emerging use cases in decentralized finance. For example, validations could be augmented to include the last fully-validated ledger. This would permit validators to automatically operate as oracles and allow, for example, users to prove to Ethereum smart contracts that particular things happened on the XRP Ledger.
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
  15. Like
    RareData reacted to JoelKatz in Suggestion: Checks   
    Most public ledgers provide no way to refuse an unwanted incoming payment. While most people would be perfectly happy to receive an unexpected, possibly misdirected, payment, it can create a real problem for some users. Regulatory requirements may make returning the payment difficult but they may also make keeping the payment difficult.
    We propose adding a feature to allow recipients to actively accept payments. We dubbed the feature “checks” internally. A sender can, instead of making a payment, create a check payable to a recipient. The recipient would have to actively claim the check.
    Users who do not want to receive unrequested payments could set their account to only accept checks. They could then simply not accept any unwanted payments. A whitelist of accounts permitted to send directly could be offered. Checks can also be used if the sender is not positive that the receiver still has access to the account. If the check is not cashed within some time period, the sender can cancel it and ensure the funds do not leave their account in the future.
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
  16. Like
    RareData reacted to JoelKatz in Suggestion: XRP-collateralized Stablecoins   
    One of the original use cases for the XRP Ledger (since 2012) was using the built-in decentralized exchange to exchange between stablecoins and to exchange stablecoins for XRP. Currently, only stablecoins that have a backer/issuer are supported.
    We propose adding a collateralized stablecoin feature to the XRP Ledger. The key distinguishing property of this proposal is that the stablecoin is always redeemable for XRP on the ledger from the collateral pool. So, for example, if you hold one unit of a USD stablecoin, you can make on-ledger payments at any time just as if you held $1 worth of XRP.
    We propose a scheme as follows:
    Anyone may place XRP into a position that they own. If the position is sufficiently collateralized, it may issue a stablecoin. Position owners may adjust the XRP in their positions so long as it maintains sufficient collateral. Position owners may issue and redeem stablecoins in their positions so long as it maintains sufficient collateral. Severely undercollateralized positions may be taken over by re-collateralizing them -- whoever does so keeps the remaining excess collateral. An order book mechanism will be used to permit the stablecoin to be automatically exchanged for XRP by redeeming against the least collateralized positions first. This encourages over-collateralization and cleans up positions that are in danger of becoming under-collateralized Pathfinding will be augmented to use redemption against the collateral so payments with a stablecoin work the same as if you held the corresponding amount of XRP.
    The scheme is not perfectly decentralized because some organization or federation still must supply the price the asset is pegged to on a continuous basis or the stablecoin will freeze. That organization can set a reserve ratio that they can use to tax the stablecoin system or to provide a reserve to buy out under-collateralized positions.
    The most obvious application is a stablecoin pegged to a fiat asset such as the dollar. However, stablecoins can also be pegged to the value of precious metals, stocks, indexes, and so on. 
    This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
    https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/
    You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 
  17. Like
    RareData reacted to JoelKatz in Suggestions for XRP Ledger enhancements   
    Since 2012, Ripple has been committed to advancing the XRP Ledger as an open, decentralized system for payments. We have worked together with the community to dramatically increase the decentralization, performance, and feature set over the last seven years. 
    Ripple’s vision for the XRP Ledger is for it to continue to provide the best interoperability with Interledger. Key to this vision is for the XRP Ledger to remain best in class in security, performance, and settlement features.
    We’ve been working on a number of possible features and design changes that could be introduced to the XRP Ledger, and we want input from the entire community about these features. How helpful are they to the use cases that the community is currently pursuing? What changes are developers and contributors to XRP Ledger interested in implementing?
    Today, we are posting descriptions of many possible enhancements to the XRP Ledger. They fall broadly into three categories:
    Consensus: Consensus is the heart of the XRP Ledger. It’s the way the ledger makes forward progress in a decentralized way. While PoW has provided only limited decentralization and appears to be a technological dead end, distributed agreement algorithms such as the XRP Ledger’s consensus algorithm provide real decentralization and continue to improve in their performance and reliability, year after year. Several of the suggested enhancements focus on improving the robustness of the XRP Ledger’s consensus mechanism.
    Performance and Resource Consumption: Due to the nature of public ledger systems, every on-ledger transaction imposes some resource costs on every participant. This creates a trade-off where increasing the transaction rate and lowering transaction fees can increase operational costs and drive some participants out of the ecosystem. Keeping resource consumption down increases the set of participants who can run their own server nodes, improving decentralization. Some of the suggested improvements aim to increase our understanding of the software’s resource consumption, reduce the consumption of bandwidth and memory, and improve network reliability.
    Features: The XRP Ledger currently has a sophisticated feature set including account management features, powerful multisigning, a decentralized exchange, and best-in-class support for off-ledger scaling. However, there are always more things it could do. The suggested improvements in this category add new capabilities such as an XRP-collateralized stablecoin and ways to ease the burden of the 20 XRP account reserve.
    We would appreciate members of the  XRP Ledger community looking over these suggestions and providing feedback. Suggestions for other features are welcome as well. Let’s build a roadmap to continue innovating together.
    You can find all of the suggestions in one place on Xpring's blog post. There are also links there to the individual forum posts for each feature for discussions.
  18. Like
    RareData got a reaction from Pablo in Chat: The Best Ripple Wallet?   
    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.
  19. Like
    RareData got a reaction from COOYONtheCOINOLIGIST in Chat: The Best Ripple Wallet?   
    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
  20. Like
    RareData got a reaction from damascus1986 in Work around to never updating Nano S   
    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
  21. Like
    RareData got a reaction from at3n in Work around to never updating Nano S   
    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.
  22. Like
    RareData got a reaction from stickmonster in Work around to never updating Nano S   
    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
  23. Like
    RareData got a reaction from 1Ton in Work around to never updating Nano S   
    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
  24. Thanks
    RareData got a reaction from 1Ton in Work around to never updating Nano S   
    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.
  25. Like
    RareData got a reaction from Flintstone in Work around to never updating Nano S   
    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.
×
×
  • Create New...