Jump to content

Professor Hantzen

Member
  • Content count

    275
  • Joined

  • Last visited

  • Days Won

    1

Professor Hantzen last won the day on February 22

Professor Hantzen had the most liked content!

6 Followers

About Professor Hantzen

  • Rank
    Advanced Member

Contact Methods

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

Profile Information

  • Gender
    Male
  1. Ripple-lib

    +1 for this. It's certainly somewhat less than ideal to be coding event-driven financial applications that handle real-world money, in a language that can't necessarily be sure what any given value is at any given moment, and that readily furnishes the creation of asynchronous code equivalent to trying to eat instant noodles with a teaspoon. (Edit: But I'm not bitter...)
  2. Is Miguel Vias in XRPChat?

    I wouldn't underestimate the power ordinary, relatively-unsophisticated, yet extremely wealthy crypto investors have to move the price of XRP (or any crypto asset). The 40x price rise from April to May wasn't driven by the tiny percentage of daily crypto exchange volume that was sold off-market to institutional investors. Every coin has its own centre of discussion where most of the good content is. The main discussion for Ethereum is at reddit.com/r/Ethereum, which is super-clean of price discussion and in general has a very high signal-to-noise ratio. The main discussion for Ripple is here which used to be the same but has suffered lately. (Bitcoin is perhaps the exception in the space, its community so fractured there are several places.)
  3. Is Miguel Vias in XRPChat?

    Two things: 1) The price / market cap being "low" versus it's potential makes it a more attractive buy for banks and financial institutions. These are the players with the real power to drive the price up, not just from buying, but of course from usage and public perception of the value to the company and to XRP of that use. The price of XRP is probably right about where it needs to be right now. The big players are just beginning to load up. 2) There has been a huge influx of "lambo-tards" into the forum and on reddit in the past few months, since the massive rise in April and May. This forum used to have a way better signal-noise ratio. There's still very good content here but the noise is annoying. It's pointless to read the same post over and over again, which can essentially be reduced to: "When will I get rich?" or "How rich will I get?". I'm not sure what can be done about it - but, to the people posting such things, think before you post: "Am I adding any value to the discussion?" Because if you aren't adding any value with what you write, then you aren't adding any value to the community, which in turn means you aren't adding value to the price. In summary: if you really want your lambo - shut up about it. If you'd like to have a positive impact on price - try to ask more interesting questions, do research and post your results, study the technical aspects - teach yourself to code (it's fun - build stuff!). When you've learned something, help others. Do something of benefit. Add value. When an investor with enough financial backing to make an impact on price comes to this forum and sees a bunch of kids whining about how their get-rich-scheme isn't working fast enough for them, what will that impression add to their decision making process? What if they see a community of enthusiastic developers, and encounter a bunch of solid research that helps them right off the bat? How would that impact their choices? How could the cumulative effect of this on many eyeballs affect the perception of Ripple and the price of XRP? If you want to make money, you have to be smart. Think before you write. As annoying as these types of posts are to many of us here, they're actually just not serving the desires of the people who make them. (Btw, I'm not specifically directing this at the OP of this topic - theirs was fine - but there are many far worse examples of this type of post on the forum.)
  4. Chat Box Run Entirely on Ripple

    Despite having the idea myself, I agree in part. While there is a legitimate use-case - preventing/reversing censorship - it would seem more suitable for these kinds of applications to create their own fork rather than use the existing Ripple ledger, not least because having the majority of the nodes controlled by banks, governments and major corporations is somewhat counter the goal of the use-case.
  5. Chat Box Run Entirely on Ripple

    This is really cool. I had an idea for a similar project but haven't had time. Some suggestions you might want to consider: rather than storing the entire message on the chain, just store a hash of the message instead. Leave it up to someone else to store the actual messages (they could be duplicated redundantly online in a bunch of places cheaply), and the chat server retrieves the chat history online, and implements only a "verified" tick or green highlight or something for each message. This just confirms that the hash stored on the ledger matches the content of the message. Obviously this relies on choosing a hash function with a low number of collisions - I think something like half a SH256 would be a good compromise between on-chain message storage size vs integrity. Further, you could batch every n=(1024 / hash_size_in_bytes) + truncated_account_delimiter messages into a single on-chain message to make it significantly cheaper both in terms of user-cost & on-chain storage and reduce on-chain transaction count probably by orders of magnitude. The downside would be susceptibility to some kind of a short-term DDoS-style attack at the point of batching - but that's probably not a biggie (and you could revert to full "on-chain" mode if the attack couldn't be mitigated).
  6. Secret Key doesn't match public key

    I've looked into this a little just now. All I can say is, it is really very broken. I've done a bit of logging and apart from the above reported issues, the minimalist client under Safari also *sometimes* doesn't always agree with *itself* what the public key is from one moment to the next. I have to travel now so I can't keep looking into it - but if it helps: 1) The minimalist client is using ripple-lib version "ripple-0.12.5-rc2-min.js" 2) The problem seems to be happening somewhere here: function generateAddress(secret) { if (secret) { secret = ripple.Seed.from_json(secret); } else { secret = ripple.Seed.from_bits(ripple.sjcl.random.randomWords(4)); } return { secret: secret.to_json(), address: secret.get_key().get_address().to_json() }; } The "secret" passed to this function is what the user enters in the text box. This *sometimes* has an incorrect associated public address by the end of this function. It would be super-convenient if it was the first "else" being called accidentally - but I commented out that line, and the issue still occurs. When modifying the code to the following: function generateAddress(_secret) { console.log('before:', _secret); if (_secret) { _secret = ripple.Seed.from_json(_secret); } else { alert('should not reach here'); //_secret = ripple.Seed.from_bits(ripple.sjcl.random.randomWords(4)); } var return_object = { secret: _secret.to_json(), address: _secret.get_key().get_address().to_json() }; console.log('after:', _secret); console.log('return_object:', return_object); return return_object; } The secret always stays the same as what the user enters (I added the underscore to reduce the potential of some kind of namespace/scoping issue). However, *sometimes* there is a new public address returned by the end. It is indeed a mystery. Edit: Adding to it, I did a test with a live account and connecting to the public ripple servers - and setting a trust line. Unfortunately, though the secret doesn't *appear* to be corrupted in the above chain, it still could be occurring somewhere else. When the public address changes for an active account, attempting to set a trustline using the public servers results in an "invalid secret" error - I'm not sure if that's because the secret changed to a corrupt one, or because of the public address mismatch.
  7. New RippleNet branding and three new products

    Clever splitting the suite in three - suiting the triskelion logo. Nice branding overall really. I especially like XRaPid's name - they obviously thought of a word that would embed XRP in there. That's cool, and the "x"'s preceding them all kind of allude to XRP also. One thing that struck me as odd was the phrase: "One frictionless way to send money globally". It's on the Twitter cover image. When I first read it, I read it as Ripple stating they were offering one of the many ways available right now, which made me think: "There are other ways?", and was just immediately confusing and distracting. It's not a strong thing to have as a catchphrase, something that can so easily be misinterpreted as: "Well, you could use one of the many other frictionless ways available, or you could use ours, I guess!". The other version of this, which seems to be written everywhere else: "One frictionless experience to send money globally" is a bit better. It could be open to the same misinterpretation but seems less so. I'm also not in love with the way they've done the imagery with the symbols fully-opaque in front of the faded-out words. It looks like the symbols are "crossing the words out" and makes them difficult to read. Those images created an immediate negative impression for me. Nobody cares about the symbols, nor should they - they're just decoration - the important thing is the word, the new name. That's what people will be using, saying, typing, thinking about etc. It actually appeared to me that the designer intended the symbols to be in the background faded out, with the words in front full-opaque, but someone higher up the chain with no design experience came down hard with reversing that. (Of course that could be a total fantasy of mine but I do say it from of years of experience working in corporate branding, marketing and advertising where exactly this kind of thing would happen frequently.) But all in all it's pretty strong, and the fact XRP is taking centre-stage for one of those three products is very cool.
  8. XRP Circulating Supply Graph

    XRP aren't mined like Bitcoin, so an exactly equivalent graph can't be made. All 100 billion XRP that there will ever be were brought into existence at the same moment of the genesis ledger (in early 2013 or late 2012 I believe?). You could create something similar, perhaps by defining "circulated" as "having been sold or given away by Ripple (the company)". But the limits around that may be difficult to define. For example, if a Ripple employee has been given XRP by the company but hasn't sold them yet, are they circulated or not? If the answer is "yes" then it could be argued that all Ripple-held XRP are in "circulation", because all are - one way or another - controlled by Ripple employees. If we then defer to it being the "intention" of those employees that matters, that opens another can of worms as intentions to sell or hold part or all of a holding change all the time. For a pertinent example of this dilemma, are Jed's unsold XRP billions in "circulation"? It could be argued that they aren't, because he was a founder of the company, and hasn't sold a bunch of them yet - just like Ripple the company would have their holdings qualified as out of circulation. This is further complicated by the fact that Ripple is technically in possession of Jed's XRP at the moment. Yet, he obviously wants to sell them, and they're being sold all the time... where to draw the line? This is a very different situation from Bitcoin, where nobody controls the uncirculated Bitcoin. Those Bitcoin can be clearly defined as such because literally nobody can access them - those Bitcoin, in a sense - don't "exist" yet. And without the cooperative mining effort of the entire network, which releases them (through maths), they won't ever exist. If a suitable and comprehensive definition of "circulated" for XRP could be arrived at, it might still also be a lot of work to figure everything out, as the requisite transactions may number in the thousands and they span many years. Maybe Ripple has undertaken something like this already and could make such information available?
  9. SnapSwap.us - end of an era

    One reason they keep trading may be because of (understandable) ignorance regarding the correct usage of the NoRipple flag. There've been multiple instances here, the old ("official") forum, and on reddit, of people who've long since left snapswap behind, yet ended up having USD or BTC rippled out of their accounts and replaced with snapswap versions of same, due to having exposed themselves to such practice by unwittingly setting the NoRipple flag counter to their intentions. Should this happen, the only semi-reliable course of action is to place an appropriately out-of-market order on the snapswap books and wait for it to be filled - which *can* happen if you're prepared to wait (though it could be days, weeks or months). The long and short of it is that in order to prevent rippling definitively in a given wallet you must have NoRipple flag set *on every trustline*. It is not sufficient to have it set *only on the trustline you don't wish to ripple*. Unfortunately - and maybe counter-intuitively - that's just the way it is. Full details here: Understanding The NoRipple Flag For anyone reading who has ever held snapswap or btc2ripple IOU's in a ripple wallet they're still using for other IOU's: the safest thing to do if you don't completely understand the ramifications of the NoRipple flag, is to treat any wallet that ever held snapswap or btc2ripple IOU's as "tainted". As such, create a new ripple wallet, and if it is not set by default, be sure to set the NoRipple flag (aka, "Disallow Rippling") on every new trustline you create, and then move any existing IOU's (except snapswap/btc2ripple), out of your old wallet and into the new one.
  10. XRP Contest/FUN :D

    A bunch more on this thread:
  11. Ripple coding Langauge

    Just a heads up that whatever you've seen online that's said it's written in Python is probably not a good source of information. There's actually little Ripple-related that's written in Python compared to other languages. As others have said, the core of the ripple system is written in C++, with various interfaces / libraries written in Javascript, or more specifically node.js, which is a server-side variant of Javascript ("Javascript" generally refers to what is run in the browser to display and interact with webpage content). FinTech applications, like any kind of application for any purpose, can actually be written in any language. Programming languages are not so generally "industry-specific", they are more "task-specific". For example, if you want to write something that needs to *run* superfast, but doesn't need to connect to anything, you might write it in C/C++, and possibly also Assembly, which is basically shorthand for the "language" your computer's CPU itself understands (and its reasonable to say C is kind of a shorthand for Assembly). These languages are more time-consuming to code in, but when coded well, can run blazingly fast and take full advantage of a computers processing power. On the other hand, if something needs to be *written* quickly, and it needs to connect to various online services, you might use something like node.js (or Python) which are much easier and faster to code in, but much slower than C or Assembly when actually running - which is not so important for many networking applications as they spend most of their time waiting around for the network to do things anyway. If something needs a combination of running fast and also needing to do a bunch of networking, it can realistically be crafted with a mix of different languages, leveraging their various strongpoints for different pieces of the puzzle. This is essentially what you have with the Ripple suite as a whole, except that - at least for the main core component (rippled) - it also does a bunch of the networking side with C/C++ which can be kind of a difficult thing to do. There are literally hundreds of programming languages in active use and development. And while this may not be what you're getting at - just in case: If you want to be a FinTech developer, don't restrict yourself to just one language, and don't be scared of learning several languages. Once you've learned one programming language, it's not difficult to pick up another, most of the common-use programming languages for software development at their core have far more similarities than differences.
  12. An ICO on RCL? Why not! Announcing PRX.

    So... if XRP are called "zerps", PRX are called "perks", right?
  13. That's not the intended use-case for XRP. It's meant to be part of a behind-the-scenes solution for making payments between banks faster, cheaper and more reliable. Through Interledger, it may also be used to facilitate transfers between asset markets that are not otherwise connected. While XRP *could* potentially be used as you suggest, it seems unlikely to happen. Certainly, it's highly unlikely Ripple themselves would actively encourage or support it. That said, some third party, or a bunch of enthusiastic users *could* potentially promote and support it in that way, and given RCL's short settlement time versus other alternatives, maybe it'd catch on. However, I doubt that would happen soon - given the current price volatility. (Unless someone comes up with a way to solve that more quickly.)
  14. An ICO on RCL? Why not! Announcing PRX.

    I love this idea. Ripple & XRP are a perfect fit for launching ICO's without all the bandwidth headaches currently plaguing Ethereum ICO's. If there was a way to bridge between the Ripple IOU's and ERC20 or other chain tokens post-crowdsale it could be a match made in moon.
  15. Real bank on RCL ?

    Really? I had no idea. Why the hell aren't I notified about these things?
×