Jump to content

Professor Hantzen

  • Content count

  • Joined

  • Last visited

  • Days Won


Professor Hantzen last won the day on February 22 2017

Professor Hantzen had the most liked content!

About Professor Hantzen

Contact Methods

  • Website URL

Profile Information

  • Gender
  1. Professor Hantzen

    XRP at 589$ = 23 000 000 000 000$ market cap

    Thanks! Glad I could help. Feel free to copy/paste anywhere.
  2. Professor Hantzen

    XRP at 589$ = 23 000 000 000 000$ market cap

    As is common, you have the misperception that the "market cap" is representative of the total amount of money put into a token. It isn't, never has been for any asset, and never will be. It's not what the measurement is for. Take the following example: Company Abracadabra holds an ICO for token ABC. Let's say there are 100 billion ABC tokens. They sell 5 billion tokens during a pre-sale for 0.01 each. So far, they've raised $50 million dollars. Now, because the company sold those tokens directly to actual purchasers for a fixed price, there literally exactly was - and only was - $50 million dollars put into the ABC token. At this point, based on the total supply, the "market cap" is 0.01 * 100 billion, which equals $1 billion. But, only $50 million was ever put in? Ok, so right out of the gate, the "market cap" is *not* representative of the amount put into the token. Now, let's say the company lists the token ABC on an exchange. The initial exchange price is 0.01, but it rapidly shoots up to 0.15 cents to meet demand - a lot of people want to buy ABC who missed the ICO. The volume for the first day was around $10,000,000 traded. That means, $10 million was sold by ICO holders, and bought by new purchasers (in amongst some people day trading, who may have bought in the morning from early sellers, and sold again in the evening to late buyers). The market cap at this point is $15 billion, but how much money was put in? The maximum "put in" at this point is somewhere between $50 million and $60 million. But the market cap is $15 *billion*, over 250x larger. Another way to put this is that after listing an ICO, and trading on an exchange, the market cap is 250x wrong if used as an indicator of "how much of a token was bought". This situation does not improve with more listings on exchanges, and more trading. It gets worse and worse, because as more trading happens, we lose more and more clarity on who has physically paid for a "new" token, and who is just trading them back and forth (possibly even with themselves using different accounts on the same exchange), and the price goes higher and higher. Market Capitalisation is essentially a flawed metric, that was hastily borrowed from Stocks (where it has a little more merit, but is still flawed) and misunderstood by most people who quote it. Where it *does* have a use is in comparing the relative strengths of different tokens against each other. The Market Capitalisation in some sense places each tokens "price" on a level playing field, such that each token can be compared relative to each other on some sort of a scale. However, as I've hopefully made clear here, that relative scale has nothing to do with how many tokens have been bought or sold, nor will it ever be. We can say that Bitcoins market cap is twice that of Ripple's at some point (or the reverse...), and this can give some indication into that token's dominance in the overall space. However, we can't use these numbers to figure out how much money has been put into a token, with *any* accuracy. To do that accurately would be to somehow magically analyse every trade on every exchange, filter out every buyer and seller individually and identify everything they did, figure out where all of the initial capital came from and in what form it was (it may have been another token for example) and after disentangling all of that huge mess, normalise everything into one currency (say USD) and figure out what has *actually* been put in. We will never know this number for any token in any accuracy. What we can guess fairly accurately however, is that this number will be anywhere from hundreds to thousands, to even millions of times less than the "market cap". This is why its very possible that digital assets can potentially have a much much higher "ceiling" than the widespread misunderstanding of what market cap is would suggest.
  3. Professor Hantzen

    Someone paid over 50k XRP for a transaction fee

    Javascript strikes again? 😐 Looks like there were around 16 transactions with anomalous fees executed by a script of some kind. When you order this set of transactions by the amount of fee paid, you notice that each transaction paid exactly double the previous fee. So it looks like someone had particular set of bugs that created this case. It wouldn't be hard to do, if they had bad programming practices encouraged by a language that does things like initialise variables for you and resolve ambiguities for you it could even happen quite simply. Something like a function containing "fee += fee" (an accidental "+" sign typo, which would even just literally be a typo because often + and = are on the same key on the keyboard). This would have added every fee together, when maybe they intended to write "fee = fee" or something similar, intending to pass "fee" to the function, and have it initialise a new "fee" value. It would be bad programming practice to name a passed in variable the same as a newly-initialised one, but some languages/cases permit it. Ordinarily a programmer might do something like "let _fee = 0; _fee = fee;", which would prevent any accidentally added "+" sign from spiralling out of control. Programming requires great attention to detail, and "good" programming languages enforce this, not letting you get away with anything. Javascript, and a few others, let you do all kinds of things without necessarily realising it, which is why they are a bad choice for writing software that moves money around. It's bad because such lack of strictness makes a language *seem* easier to learn, when in fact this "false-ease" it's actually preventing you from learning a bunch of incredibly important things. A beginner can be readily fooled into thinking what they're doing is correct, when in fact what they're doing can leave them open to all kinds of (mega-costly) errors down the line. There's no reason a competent programmer can't use Javascript/node to write robust code, if they are patient, methodological and adhere to good programming practices. But it is much harder to do, and the reliance on modules authored by others makes this much more difficult to maintain. For example, I recall finding a bug in an old version of ripple-lib's transaction signing code (which is written in javascript) that would turn a supplied amount that has high precision floating point amount like 0.0182665927465921, into billions without letting you know. The only reason I found the bug was because a transaction I signed and submitted came back with an "insufficient funds" error. Ie, had my account enough BTC at the time in it (luckily in this case, more than even exist...), the transaction would have attempted to use all of it. In which case, whose fault would it have been? Ripple's for the bad ripple-lib code? Javascript for making such silly things possible? Or mine for trusting ripple-lib to sign my transaction without silently modifying the amounts I supplied? In the case of the fee-doubling transaction, at least whomever did that seemed to be watching it after it ran. It's evident they halted the script after about 10-15 seconds as the errant fee-doubling transactions only happen across 3-4 ledgers.
  4. Yeah, I can see your point of view too, and it makes sense. I guess we may never be sure what happened, though there may be clues when we see another product from a competitor, or from Ripple themselves. I suspect we may see this similar interface cropping up again as I believe that aspect is part of what is being offered by Ripple as an end-solution to banks. What would be interesting is if another bank came forward with a Ripple back-end integrated with their pre-existing front-end - eg, their current mobile app for regular banking with a seamless Ripple integration for payments. That would likely be a bit more difficult to do and suggest more confidence in the tech than a completely separate secondary app as Santander did (which is arguably a confusing way to go about things for their customers, unless it was also the easiest way due to implementing a pre-existing turn-key solution).
  5. Firstly, its really nice to disagree with someone without it immediately degrading into useless nonsense - thank you. As for the app - I doubt Santander spent years developing it (though its possible if they have an extremely incompetent software department, which uhh... can certainly happen). A lone developer could code up such an app in a week or less, it only has a few screens and only does a handful of very common iOS-app things. iOS development (and most development in general) is really not that hard for an app like this. The pieces required all pre-exist. The revolutionary part happens at the Ripple end - and this app just sends a message to that part saying "hey can you do some of your XYZ Ripple magic please?". What this app does is the same things many apps do these days, verify a user, access a database, take input from the user and send off some JSON based on that input (that's the magic message). Santander already has a working iOS API into their banking system / database for verifying a user and processing transactions (and affecting other states), because they already have a banking app. Ripple's part is to sell Santander their custom API into their RippleNet & XRP Ledger. All that's needed to build the final app is a few screens to be set up in the (horrible) iOS development environment supplied by Apple (Interface Builder & Xcode), and the basic logic within that app to route the various requests where they need to go. The time-consuming part would be testing everything and catching all the edge-case error that the various DB's and networks involved throw up afterwards when things go wrong or take to long (timeouts). This last part will be exactly why Santander tested the app for so many months with their employees, but its very likely the app will have been mostly complete at the beginning of that process - and as I say - most likely supplied by Ripple as a template / boilerplate code. One major reason for that is that Ripple will have had to initially develop exactly that code for their own internal testing and for demonstrating to interested customers - it would make no sense to then arbitrarily withhold that code and force every bank to come up with it from scratch again. For one, all of the banks would be constantly asking Ripple "so how did you implement this bit with the sending the magic message to your thingy, could we maybe see the code from that demo you showed us?". (As for the Reisebank transfer, whilst the sections are arranged differently (and IMO confusingly), the very specific font and styling choices for the currency values, the titles of the different sections, and the same styling of an inverse block of colour with white text heading the payment screen all exactly match those in the Ellen/Santander version, hence my thinking its an earlier version of the same product, that was rearranged to make it clearer to the user what's happening.)
  6. Maybe, but I think it's more likely Ripple gives banks a bunch of starter materials and they customise them. It's a significantly less attractive proposition to have to start completely from scratch. Also, the ATB-->Reisebank transfer video predates Santanders app by a long while, yet bears a very close resemblance in terms of font choices, layout and feel, it looks to me like an earlier version of whats shown on Ellen (and the Santander app).
  7. For completeness, I had someone I know who banks with Santander download the OnePay FX app and add a recipient, as I couldn't find a decent screenshot of the exact same screen with recipient details. Here we go: One of these has been modelled on the other, or it's the exact same app. What I most suspect is that both are a Ripple-designed UI or template, and its customised for/by each banking or institutional client. So the Ellen one is probably Ripple's own internal default version.
  8. Holy ****. That is some amazing publicity. That will certainly send a major... ripple... through the consciousness of middle America. Enough stuff like this and Ripple will be a household name.
  9. While I agree that new dodgy sites pop up all the time, the NASAA is completely legitimate, and this article and the events it describes are real. My opinion however is that - as happens often in the finance industry - it may be corrupt as all hell behind the scenes. This article and its headline smack of unnecessary sensationalism, and to what end? Is it an "international crackdown" to send exchanges letters asking them to describe what they do? The fact they may have shut down or started prosecuting a small number of clearly-obvious scams that operate at the fringes of the space does not quite warrant the exaggerated language they're using. They could have named the operation "Healthcheck", and described what they're doing accurately with a headline "State and Provincial Securities Regulators Investigate Potentially-Misleading Investment Promotion In Cryptocurrencies". Instead of the byline "This is the tip of the iceberg", they could say "And we'll continue investigating until we've uncovered every scam amongst the legitimate and important innovation happening in the space". It's all obviously spun and overblown, and why exactly?
  10. Yes, exactly - it feels like the original article is intended as FUD, not (necessarily...) your post of it here.
  11. This has been known for a while, and is already thoroughly reported on. I'm not sure what this new article adds other than some FUD-type spin ("Operation Cryptosweep" ... ooohh!) to get people panicking and drive the markets down further. While I'm sure there is genuine work to eliminate crappy scams, the sensationalist headline of the NASAA article - and the timing - suggests to me more of a "coordinated effort" to keep investors selling so newly on-boarding institutions can buy up cheap.
  12. Indeed, almost seems set up to encourage about as much wash-trading as possible.
  13. Professor Hantzen

    Learn to code for Ripple products

    Yes, rippled is (almost entirely?) C++, and with good reason. Client side apps can be written in anything, but the official documentation and API are tailored for node & Javascript.
  14. Interesting timing too - this is a London-based exchange, and that London regulatory panel with Ryan Zagone wasn't so long ago. Is this a sign of a behind-the-scenes green light on crypto by regulators?
  15. Definitely for institutions only. Check out their prices (this is for their regular offering, not sure if/how crypto differs): https://www.lmax.com/global/fee-schedule