Jump to content

T8493

Bronze Member
  • Content Count

    2,304
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by T8493

  1. If you are not sure what you need to do now, go to a tax advisor (or lawyer or tax administration) now and don't wait.
  2. If you want to change "tax address" to another country, that typically means you have to physically move to another country.
  3. It looks like Coinbase is having a lot of internal turmoil recently. Head of GDAX engineering is now relatively young and inexperienced developer from Slovenia (Miha Rebernik).
  4. You won't get any "expert" advice regarding the taxation of crypto profits in France. You should probably ask your tax administration about this. You don't necessarily need an appointment with a tax expert because they're often clueless.
  5. Bank security systems are not significantly different from the security systems in other sectors (health, insurance, funds, etc.).
  6. Banks just need to store their private keys in a secure environment. Typically, they already have such environments (they use e.g. HSM cryptographic appliance) because they use it for other purposes, too. One of the problems seem to be the lack of support for curves (secp256k1) and digital signature schemes (ed25519) that Ripple and other blockchains use.
  7. Authors don't claim there is any weakness in the SHA-256 (or RIPEMD-160) algorithm. Authors also claim that they need to examine around 2^137 private keys before they find a collision. No one in the world is capable of doing so much work. Just try to recalculate how many days one would need to find to find 1 collision using the 25 MKeys/sec pool capacity that the authors give as an example.
  8. Not exactly. I was saying that there are much easier ways to calculate your private keys (e.g., in case of a faulty software) than to brute force keyspace for collisions. Maybe these private keys were found using some other method.
  9. Amazon is looking for blockchain partners, although this is maybe not what people here expect: https://aws.amazon.com/partners/blockchain/
  10. It depends on how these private keys were generated (e.g. did someone use brainwallet or a faulty random number generator?). It could also be a consequence of how the ephemeral ECDSA keys are generated (improper generation of emphemeral keys can disclose your private key). Basically, it boils down to how well written was your software and its implementation details. This is not necessarily something that would be an inherent weakness of ECDSA.
  11. Probably yes, because behind the scenes uses similar method of generating public addresses. I think this was already discussed somewhere (and nikb responded).
  12. What does this SHA-1 collision have to do with Ripple? How is this related to Ripple? This is AES (encryption, not digital signature scheme) and side channel attacks are usually very implementation specific. Side channel attacks are also possible against ECDSA (e.g., timing attacks), but regardless of that ECDSA is still widely used (because we have countermeasures).
  13. But why would this have any impact on ledger closing times?
  14. I really appreciate your efforts to contribute to the Ripple ecosystem, but you must understand that this community can be sometimes quite critical (much more than other crypto communities). But I think this is a very good thing - such brainstorming can lead to better (safer, more secure, reliable, with less privacy concerns, etc.) solutions for community members.
  15. I would be slightly skeptical, yes, and I would certainly audit it before using it in production (especially if I could be potentially held liable for something). Older versions of this code produced faulty Ripple addresses and I'm not sure substantial engineering effort went into resolving and pinpointing the exact issue (not only on the RL side, but also on the side of third party developers which could potentially prevent this issue from happening in the first place). RL devs have added one additional test: https://github.com/ripple/ripple-keypairs/commit/1cf06f0f1ffe21ac4a0929545bc6d632f8648db3 . But - for example - are they testing this on every browser/nodejs/OS combination? I am not so sure. Are they testing for faulty message digests methods? Are they actually testing that rippled can actually verify the signatures produced with generated keypairs and public Ripple address? This library also depends on some third party libraries (e.g. hash.js) that also lack substantial test coverage, IMHO. However, problem could be also in the environment in which this code is executed (e.g. browser or nodejs environment). I'm not sure why is this relevant. If it is somehow "provably secure", then yes, why not.
  16. You see, here is the main problem. You trust third party library which wasn't audited (and there is no guarantee that it actually uses cryptographically secure random number generator, especially in some (older?) browsers) and this (or some very similar) code recently caused people to lose money (search for Jatchili's wallet on Mac on this forum). However, this is not limited just to third party cryptographic software. Hackers recently stole 5M USD from GateHub and the (official) reason was some partial payments "problem", which was probably known for years and it was very well documented. But their developers still mishandled it.
  17. I'm not sure why you mentioned me in your first post, though. It is true that libraries can have (very) limited scope. But it looks like you completely disregard this "compliance" and "risk" point of view. In corporate environments software sometimes has to be (externally) audited, too. And in this case it would be much more beneficial if Ripple had published such libraries that would have some kind of stronger "guarantees". Not necessarily in the SLA sense, but - for example - that they would use provably FIPS compliant components. Because right now there is only one library (JS ripple-lib) which is kind of maintained. All other libraries (Java & .NET) are practically dead from the development point of view.
  18. Well, documentation of most crypto projects really sucks, and it shouldn't be used as a benchmark. Something like MSDN should be used as a benchmark, though. Why did you build your own library? How much engineering effort did this require and what was the ROI of that? Does your library cover all edge cases? Was it audited? Is it cryptographically secure? Does it support all transaction types, even the more obscure ones?
  19. I've just removed "(confirmed)" from the title, moved this topic to a XRP price speculation club (before it was in the price speculation category) and added a "speculation" tag.
  20. The problem is what to send them as a proof that your account (and someone else's) needs to be credited. Everyone can claim XRPs sent without destination tag are theirs.
×
×
  • Create New...