• Content count

  • Joined

  • Last visited

1 Follower

About Sukrim

  • Rank
    Advanced Member
  1. I guess something that is an already established industry standard would be great to have, like FIX or heck, even something that's emulating Bitcoin's API. sounds also like something that might be interesting, though I have yet to see any open source clients out there that use this protocol or OpenMAMDA. What is currently missing is an easy way to verify ledger contents (e.g. does the root hash of a ledger actually compute correctly), any (supported) API library that does NOT use JavaScript, documentation of some more advanced features of RCL (path finding/defining paths in general, p2p networking concepts, cryptographical foundations) and accessible local testnet deployments to install and simulate. It is a shame that after nearly half a decade rippled is still not a package in any major Linux distribution even though it is published under a free software license.
  2. It modified transaction processing logic though, right? I already called it "fix", not "amendment" (which I only called amendment because that's how it is named in the code: "amendmentRIPD1443"). As far as I understand it, unless this piece of code is present, validators would reach different conclusion if a certain transaction after the time stamp in the switch was processed by them. A full amendment would also insert a pseudo-transaction in the ledger, so a validator voting against this or not knowing about it would not just see a (in its opinion) invalid transaction result which it might be willing to overlook or accept that the majority sees it differently, but it would see the whole resulting ledger as invalid and thus stop operating alltogether. With this "time-based switch", it just would propose different ledgers initially in cases where this bug was used and quickly switch over to the transaction results that the Ripple Inc validators propose, as their vote is the law currently.
  3. If they still run validating nodes, there is very little chance that they approved, since the code was published after the weekend while Ripple Inc. rolled out the fix on their validators during the weekend. There was no public way to run a validator agreeing with the ledger chain published by Ripple's validators for a few days recently. The only way that they could have approved would be that they either have access to Ripple Inc's internal code repository or that they got a compiled binary from Ripple themselves and immediately rolled that one out on the weekend. I call this implausible. Running a validator is easy (mine runs for quite a while already), there is just no way currently that it actually matters. Maybe with the "dynamic UNL" stuff in 0.60.0, Ripple Inc. will now start publishing what entities they consider "unique"? There's very little documentation around that feature though so far...
  4. Why? The 2 days was based on the time this post was done, so I guess it is understandable in context. The next, planned hard fork will be when the actual amendment for ILP integration goes live. Do you consider the amendment procedure or the unilateral rollout+deployment of consensus changing code something other than a hard fork in the blockchain sense?
  5. There are not that many countries with 40 million citizens...
  6. It is better because XRP is native to the same blockchain as several USDT-equivalent "cryptocurrencies" (actually: fiat denominated IOUs) are and it is even including a trading mechanism, a sane API and it is still actively being developed. USDT is less than a gateway IOU, since to trade you HAVE to go to a different exchange, which is often not very transparent or risky and demands creating USDT IOUs by depositing funds there. I don't see the appeal to convert to XRP either, but I find it very strange to see someone from Ripple Inc promoting something that got created as a direct response to the Ripple gateway model just making sure not to actually use Ripple which (in times of the ripplescam website) was definitely not something you wanted to be associated with. RCL itself and USD denominated IOUs/balances of a trustworthy gateway serve the same function and more of USDT, yet even after years most "adoption" of Ripple in the cryptocurrency space only consists of half-assed (and sometimes completely inefficient and using plain wrong concepts) acceptance of XRP tokens instead of evolving into gateways.
  7. Ripple as a concept initially was built around rippling and not so much around the gateway concept. In a strong end-user centric market, rippling would be much more common and useful. If only less than a handful gateways like currently are transacting in scale, it of course is hard to see the advantages. Conceptually, I'd recommend looking at rippling as "implicit offers" compared to the explicit ones that end up in order books. Both have their place and their advantages as well as risks. One advantage would be for example that it is very easy for someone to offer a "hub" between a lot of IOUs and even automatically (though quality settings) have a chance for a guaranteed profit without having to submit a single transaction. I really hope that with ILP enablement later this year one of the first use cases will be more native cryptocurrencies on RCL, which would offer lots of trading potential as well as potential for more interesting gateway models than with the regulation heavy fiat currency market. This depends on client/wallet support though and in that regard unfortunately there still is a lot to be done. Whoever manages to have a profitable business case for a well made and tested Ripple wallet would be doing more for the XRP price than the umpteenth bank announcement which anyways will just use Ripple Inc's closed source ILP implementation and never touch XRP even in passing (why should they, if there are no actual offers or useful gateways out there anyways?).
  8. Why set SendMax to a value that you're not intending to fully send anyways?! @enej - where in the best practices and security guidelines is a SendMax value set above Amount + Fee recommended? To me it seems more like a copy-paste error from the documentation, which uses a 0.5% fee.
  9. I don't think this needs to be on-ledger, but it would be nice to have. If you want it on the ledger, it could be implemented with Memos too. Bitcoin removed this functionality a while ago (using a preset key, some people could sign a broadcast message that would have been displayed at every Bitcoin installation e.g. telling users to not transact because there is an active attack). In the "real world" CERTs have the infrastructure and expertise to handle this stuff, a Ripple CERT (either run or funded by Ripple Inc.) might be a good idea.
  10. Me too, believe me. :-) I agree that it was probably the best way with your current tool set to fix this issue as fast as possible, though I'd still have loved to see the code public at least as soon as you deploy it on the network or latest after the time-based-switch was in effect and your validators were already using it. I really hope that in the future this will have to be handled differently, even if it is done semi-automatically (e.g. look into the Omaha protocol and if it might be a good fit for dealing with rippled deployments). I loved your fast reaction on this, but I'm a bit disappointed that it is still possible to push through hidden code changes on the live ledger in 2017. Hopefully neither of this will be possible (because RCL is secured by a diverse set of entities) and necessary (because there are no transaction processing bugs) in 2018 or sooner. Ripple's decentralization is currently not existing, the current amendment procedure is nothing more than a dry run test as all amendments are accepted or rejected solely based on how Ripple Inc. votes. I agree with your bolded statement, packaging and deployment is definitely an area where rippled does not do very great. There is not a single Linux distribution I could find that builds all variants of rippled successfully using just native packages. Even the RPM by Ripple Inc. is built with a custom patched (and statically compiled...) version of OpenSSL, uses various packages from Fedora to get more recent compilers and library versions and compiles git from source for some reasin.
  11. The only difference between a validator and just a standard node is that a validator signs its current opinion about how the next ledger should look like and broadcasts this signature. [Edit to clarify: This means it is very cheap to switch on validation, though it would probably be better to have a dedicated server for this if you want your validator to be trusted by others eventually. Enabling validations does not influence any of your capabilities on the ledger itself and does not add much overhead or provide additional capabilities to a rippled server.] I'd recommend getting in touch with Ripple the company, they are more experienced in running servers at scale than most participants on this forum.
  13. You seem confused, or I've maybe not been very clear: I'm talking about introducing changes to consensus rules unilaterally, not about developer teams or software development in general.
  14. With calling a consensus breaking change "hard fork" or with deflecting that "forking a project" in software development context means "moving on with a different developer team and splitting off the current code base"?
  15. @papa - The term is quite well defined in the cryptocurrency space and after all this is the technical forum. Instead of making blanket statements ("your argument is overinflating") maybe give some reasons in your post as well. @zerpdigger - Ripple Inc. still after more than 4 years has 100% full control over everything that happens on RCL which could also mean that they are liable for any fraud that happens on there. @RafOlP - Bitstamp publishes validators ( but apparently doesn't even run them any more. I don't think with the inherent risks of a US-run centralized system Ripple is going to attract volume, XRP "market cap" (however one actually calculates that one...) is one of the least interesting metrics to me and imho not indicative of anything more than speculation. If validations were more diverse, it would be harder to fix bugs like the one mentioned in the OP, but it would at least mean that they are engaging with the community (or starting to build one in the first place) instead of secretly pushing out amendments that change consensus rules. Of course you are forced to trust them if you want to use XRP by the way, they are the only ledger that is legally allowed to call their native asset that name and they run the clique of validators that govern this network.