• Content count

  • Joined

  • Last visited

1 Follower

About Sukrim

  • Rank
    Advanced Member
  • Birthday
  1. You seem to focus a lot on XRP in your articles while not being very knowledgeable about RCL (including the false claim that offline storage is not possible and not listing even RCL as a place to trade XRP). Why the big focus on a rather uninteresting asset on a very interesting platform?
  2. I highly disagree. If Ripple Inc switches off their validators for 2 hours, there will not be any validations on the network for 2 hours and the ledgers will pick up where they stopped. If anyone (MSFT, CGI) validates ledgers meanwhile on their own, they will very likely NOT be used by Ripple's validators to re-join the network but instead forked off. If a big mining pool in Bitcoin etc. goes offline, blocks are found more slowly for a while, but they will still get produced. If a big validator goes offline in Ripple, nothing should (TM) happen at all unless it is a pretty large percentage of all validators in the validation network (the 5 Ripple Inc nodes should be well below that threshold). If the network actually grinds to a halt instead, it is NOT decentralized currently, as claimed in that statement. Edit: As an aside, Ripple removed the video that explains their Consensus algorithm from their YouTube account. Doesn't seem like a very XRP-centric approach, since this is the way how XRP transactions are secured. Their YT channel is now nearly exclusively about ILP.
  3. The problem is that unless one has access to the private JIRA, it is very hard to know what "the next phase in the consensus refactoring effort (RIPD-1011/RIPD-1342)" is and "create a generic version of the consensus algorithm for use in a testing and simulation framework" sounds to me a bit like creating something like "librippleconsensus" (which would make sense by the way - there are lots of projects out there that might profit from Ripple-style Consensus). Sorry I misunderstood your intentions and thanks for the clarification.
  4. They are systematically removing all mentions of RCL (and thusly XRP) from their materials and website... Apparently they also try to create a separate library with just the consensus code part of rippled, my guess is that this is to be used by ILP nodes to form some "trust islands" amongst each other if they want to. [Edit: Wrong, see @nikb's reply below] I still don't get how banks are ever going to trust a solution written in JavaScript interacting directly with their internal ledgers in near real-time, but at least it makes for nicer looking demos.
  5. Nope. To make markets you need to own the stuff you trade or Ripple would need to co-sign every offer you make (and might get fined for that again). SusPay doesn't allow for this either, especially considering that the MM might just sell all XRP to a third party - whould Ripple then do a clawback? What if you're the third party and suddenly own XRP that you shouldn't? I'd like to see some concrete gateway names + evidence (100% of the history of all current gateways is available!) that low spreads make more market participants (how many are there anyways?) choose XRP or at least RCL to trade.
  6. How would those gateways be selected and how is this beneficial to the eco system, especially if new gateways would like to enter the market and then face subsidized competitors? Which gateways actually lack liquidity in your opinion and do you have any indication that there would be increased activity if there were smaller spreads? How would Ripple Inc get XRP back from users who break the contract?
  7. The "consensus" is 100% in Ripple Inc's hands and there is absolutely no way that any external opinions except US courts matter there right now. US courts however would likely not be very favourable to essentially stealing someone's property. Ripple already got fined for less and don't forget: they also have an agreement with Jed anyways. Sorry, but code or community won't solve this one.
  8. I don't see where RCL would offer anything more than some funding for this project. Also spending money on fixing water lines for a community in a first world country does not really sound appealing to me personally, then again I'm not even on that continent so maybe this is the ideal way to champion consumer facing development of XRP usage?
  9. There are several implementations of these curves available for Windows too, rippled builds and runs on Windows and most client side stuff is written in JavaScript. I'm sure there are also implementations in C# or ways to call them from C# if you need to. Weakening crypto or implementing weak ciphers just to appeal to some committee seems a bit backwards. Especially using stuff that has a still(!) unexplained seed value contributed by the NSA itself. If Microsoft or TPM manufacturers are into implementing this stuff, so be it. ECDSA schemes are still probably quite far off from being hardware accelerated anyways (it took quite long until AES or hashing algos were part of CPUs...). eIDAS recommends curves, but does not use the word "must":
  10. is nicer, since it also contains trust relationships (UNLs in Ripple/RCL). In reality, RL1-5 still only trust each other, so every other node on there doesn't matter. Last but not least, I'm not too keen on buying a domain just to have a "verified" validator in there, at least mine is listed. I am not happy that this is seen as a success though, especially since this is now the fifth(!) year that RCL runs solely on RL1-5 validators, including some quite extreme outages like This is something that wouldn't happen if the "C" in "RCL" actually was in effect. Regarding XRP, this is also in my opinion the main thing holding it back. As long as RCL is effectively only trusting directly or transitively a set of 5 nodes, all operated by Ripple Inc. (maybe not even on-site but potentially by some cloud provider or data center?!) I don't have high hopes for wide acceptance of RCL and subsequently XRP.
  11. Ripple uses very similar crypto, so it's mostly a software issue.
  12. These recommendations are bad and those standards probably outdated. Even secp256k1 is already a compromise compared to Ed25519, see
  13. Why did they check Litecoin but not Bitcoin-core by the way? Their choice of projects seems a bit odd.
  14. Would be easier to develop a custom firmware or at least an extension for existing hardware wallets like Trezor. I just don't see the demand for it or how this would be in any way even remotely financially profitable (or even covering costs).