Professor Hantzen

Member
  • Content count

    249
  • Joined

  • Last visited

  • Days Won

    1

Professor Hantzen last won the day on February 22

Professor Hantzen had the most liked content!

3 Followers

About Professor Hantzen

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    https://twitter.com/phantzen

Profile Information

  • Gender
    Male
  • Country
  1. Unfortunately, there's not really such thing as a "tick" in the Ripple system because all of the trades are collected and executed within the space of one ledger close roughly every 3-4 seconds. One way to get maybe the closest you can to tick data is to run a rippled instance, populate it with the history of ledgers you want, and query through them for the trades and payments affecting the order books you're interested in, and noting the TransactionIndex in each transactions metadata, which is the position of that transaction within the order of execution for any given ledger.
  2. That's awesome! The highest definition available at the moment is here. It's around 5500x5500 (roughly, and also note that the background glyph shape is a little pixellated). It's probably not high enough resolution to print very large (maybe A4 at 300dpi would look alright), but I do have vector versions of the separate parts. I know someone who could combine them, and they may well be interested in receiving payment in XRP. Let me have a check and I'll get back to you!
  3. Thank you! So great to hear you're using it as your wallpaper. I always enjoy your posts and perspective.
  4. Hah! Yes! Thanks! Here's it's full blurb: "Created from two months of chatbox messages from the XRPchat.com forum. The period is from 22nd March 2017 through 25th May 2017. Probably the happiest most eventful time to date of Ripple and XRP - from the start of massive price rise out of the sub-cent range, through to it's peak in the 30-40 cent range and right before correcting. The foreground is from the content of the messages, the background is the people who wrote them."
  5. That's really cool - anda nice fast site. But where is ETH?
  6. Me neither - well, I mean I knew it was possible to create it, but hadn't found someone who had. Be nice if they published their source data though (we kind of just have to trust them). Found it here, by the way (top comment): https://www.reddit.com/r/Ripple/comments/6fnsez/bitcoin_crash_xrp_crash/
  7. The rule for all crypto is the same. Wait at least one year, or preferably five, for anywhere from 1,000% - 100,000% gains (...or 100% loss). Anything less than a year is too early to tell.
  8. These epic charts tell the whole story. Essentially XRP has a very low correlation with the movements of any of the other major cryptocoins. There's not even very much inverse correlation. In other words, XRP has completely broken free of the shackles of being tied to the movements of BTC, ETH or any other crypto. It's charting it's own path, independent of the others. It's therefore likely that it's investors are no longer a subset of cryptocoin investors, and instead, cryptocoin investors are a subset of XRP investors.
  9. Wow. I'm feeling the half-cent to 40 cent rise all over again.
  10. I think you're missing something. If 3000XRP = $100k, each XRP would be worth $33.33 and it's naked market cap would be 3.3 trillion dollars (or it's CMC'd version around 1 trillion). That's almost 100x bitcoins current market cap. If Ripple and XRP achieved that level of success, this shirt would be worth absolutely shitloads as a collectible, and it's floor price would likely be set in XRP as the amount of XRP paid in this auction. The winner of this auction is likely making a wise investment along with supporting a good cause.
  11. Right you are. I've edited to clarify what I've provided - maybe its still helpful to someone. I tried to track the source of getrandomvalues() just now, but couldn't turn up anything. Anyone know where the source is? I could only find a github for the documentation.
  12. A while ago I wanted to find this out for the server side. I'm not sure what happens client side, and whether there are similarities, but in case it's useful here's what I turned up: The node module ripple-keypairs is the one typically used to generate seeds (which in turn are used to derive the ripple "secret"). The ripple-keypairs module uses "brorand" which is a node module I can find absolutely no information about. It appears many people use it - though it doesn't even have a readme. I looked at the code and it seems to just try a few different browser-dependent sources of randomness or falls back on nodes crypto module. I guess it's just a simple convenience module, but relying on this piece of "middleware" for such a security-imperative function seemed somewhat haphazard to me. It creates a single-user weak point for mission critical random number generation the world over. If that users account is compromised, and someone uploads malicious code, there may be a period of time where people unwittingly use the updated module and security the world over is affected. Anyway, in the case of ripple-keypairs being used through node, brorand simply wraps node's crypto.randomBytes(), which itself I believe wraps OpenSSL's RAND_Bytes(). When investigating RAND_Bytes() I found it has the following issues: https://eprint.iacr.org/2016/367.pdf Can someone familiar comment if the vulnerabilities described in this paper have any impact on ripple-keypairs? How safe is using the generateSeed() function in its default state (without supplying custom entropy)? While looking into this, I also discovered an issue with ripple-keypairs and how it processes user-supplied entropy. In short, it appears to truncate the amount of entropy supplied by the user to 16-bytes without warning them it's doing so. It's not a big deal (16 bytes should be enough), but it still should be fixed.
  13. If you're interested, there's a comprehensive answer here. Specifically: "if you could use the entire planet as a hard drive, storing 1 byte per atom, using stars as fuel, and cycling through 1 trillion keys per second, you'd need 37 octillion Earths to store it, and 237 billion suns to power the device capable of doing it, all of which would take you 3.6717 octodecillion years." 1 octillion is: 1000000000000000000000000000 1 octodecillion is: 1000000000000000000000000000000000000000000000000000000000 So according to the writer, you'd need 37000000000000000000000000000 earth-sized hard drives storing 1 byte per atom, and 3671700000000000000000000000000000000000000000000000000000 years to get through every key. (Though, as consolation, after that you would have *all* the coins.) This is for bitcoin, but the principle and numbers are - for practical purposes - the same for almost all cryptocurrency. The numbers may vary by a few quadrillion years here and there, but who's counting?
  14. Love this combo. Not just the two aptly-titled books, but also how they're framed by a Bloomberg terminal keyboard, what looks like a freshly-opened Apple-product booklet, and... the ubiquitous start-up whiteboard marker. "Tools of Titans" indeed! (If it's a little hard to make out - the book on top is "Programming Javascript Applications", the programming language often used to write code that interfaces with Ripples products, along with some of the products themselves. Tim Ferriss' book on the other hand is an excellent compilation of the habits and philosophies of many contemporaneously successful entrepreneurs, artists and scientists.)
  15. No. The idea is people are repositioning XRP and other assets by making payments from one account (probably a cold wallet), to another account (either a personal hotwallet, or an exchanges). Therefore, payment volume can be expected to increase prior to major exchanges (and so, price movements) taking place. Further, after trading, more payments can be expected to be made placing acquired assets or profits back into cold storage. Payments spiking along with price movements is normal behaviour.