Professor Hantzen

  • Content count

  • Joined

  • Last visited

  • Days Won


Professor Hantzen last won the day on February 22

Professor Hantzen had the most liked content!

About Professor Hantzen

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Country
  1. Ranged from around a half to a third of the current value at that time. And I agree... he could buy some XRP with it at least.
  2. Ok - proof of... something. The server always closes the socket at just under 30 seconds from when the last message was received by the client: Further, it appears if you don't subscribe to anything (and do just a server_info request on open for instance), then the socket will stay open.
  3. Btw I suspected it was related to idle state as a few days ago I did a little testing, and subscribed to a order book stream on its own (so without also subscribing to a ledger stream), as the orderbook was quiet at the time, I would get much more frequent disconnects. I was also trying to identify which server was giving me solid connections but there's just too many (love the names though). Here's a gist of the output log and the short program I wrote for testing: As you can see from the code, every socket close in that log was uninvited and pushed by the server, names are named...
  4. I've been having constant failures with websockets beginning in the past 1-2 weeks, too. I've been watching it and it seems to be server-specific. Ie, each time the connection closes I reconnect with a new server, and once in a while, that new server will give me a decent socket connection that will last, apparently indefinitely. The last good one lasted for 3 days before I had to close it myself, and that was the type of experience I could expect before this change happened in the last couple of weeks. Upon disconnecting from a good server, I'll get bad ones again which close the connection constantly. When I say constantly, I mean if I open a connection, subscribe to a couple of streams - 90% of the time the server will disconnect within the next 5 minutes. I can't be sure but it appears to be an idle state - like if a ledger takes longer than a few seconds the socket will close. Note: I'm NOT using ripple-lib to manage these connections, this is just straight ws in node. So, I believe this is either rippled-related, or something is going on with the cloud platform hosting the public-facing rippled servers. I thought of reporting this on github - but where is the endpoint for issues affecting the deployment of public servers specifically?
  5. I see the poor bastard's lost ~8 BTC by leaving it with Snapswap. (I guess his own coins $4.1 billion market cap might make him feel better though.)
  6. When trying to ascertain the value of a cryptocurrency, the market capitalisation is often cited. We take the amount of coins in the wild, multiply that number by the current price, and the resultant number is supposedly of use in determining the overall value. I've been thinking about this, and the more I think about it, the less it makes sense. For example, let's say the usefulness is it shows how much money it would take to buy every coin from everyone. Well, the market cap doesn't show that: That would be shown by clearing every order book on every exchange for that currency, and calculating what you paid on average across all the aggregated asks, and then assuming - by some heuristic - how much it would cost to tempt all of the remaining coins not listed to be listed on exchanges and for what price and then clear all of them in the same manner. This would be difficult to estimate accurately, and it would only ever be a guess, and it would also - depending on how high the asking prices in the order books went - be really, really high. But, it would be a reasonable estimate of the current "value" in principle at least - as it would be literally how much it would cost to buy all the coins. But, given how hard it is, and how must guesswork is involved, we'll have to scratch that. Let's instead say the usefulness of the market cap is that it shows how much money has been invested in that currency. Well, obviously it doesn't show that: To find that out, you'd need to take the volume weighted average price (VWAP) paid for all of the currently held units of currency. Given all available data points, this would be possible to calculate, but be somewhat time-intensive given you'd have to account for so many exchanges back and forth, even between the same person and the market, to find the real latest value paid for any given currently held amount of the currency. Further, all the required data points are not necessarily available - any coins traded privately, or in other ways off-exchange could not be accounted for and would have to be assumed somehow. So, failing either of these methods of measuring the value, the market cap seems to be just some kind of weird, inaccurate mathematical "nickname" for an ideal metric that doesn't really exist, or is just too hard to calculate. In any case, when we calculate the market cap, it appears we're doing so out of tradition rather than any common sense. Market cap ostensibly would show the "value" but it absolutely doesn't do that. If you offered everyone holding the asset the current market price, they *wouldn't* give it to you - how could they? Many of them aren't even listing a sale price - ie, they don't want to sell - and many that are listing a price are doing so way, way higher than the current market price (that's the list of asks). How is the last paid price multiplied by the coins any way indicative of the value? It isn't. It's a fantasy! So, given that the market cap is of no real tangible use for its stated purpose, how can we establish the value of a cryptocurrency (or any asset for that matter)?
  7. Great explanations here! Given the current RCL environment (low-liquidity, disparate currency prices), are there present use-cases where enabling rippling is advantageous or useful? I can understand it's usefulness in a future where currencies of the same type have reliably congruent value, but it in the current environment rippling appears to provide advantage only to malicious actors who find ways to use the feature to exchange an asset of lesser value for an asset of greater value, behind the back of the more valuable asset holder. Pretty much the only "attacks" or bugs/issues with RCL that have endangered user funds - that I'm aware of - have been related to rippling, and yet it appears to provide little to no present advantage or use... is that fair comment, or surely am I missing something?
  8. @miguel Anything like this in the pipeline for 2017?
  9. Ethereum just crashed somewhat (well, in relative terms...), so maybe its a combination of those exiting ETH seeking shelter in XRP stability, and those dumping XRP to buy more ETH at a perceived discount?
  10. This is not your call to make, regardless of the situation. You do not own the protocol, nor are you it's sole arbiter. You've stated that this issue can cause the slow draining of funds that could push a gateway to insolvency, and you've also stated it could be considered legitimate use of the network. Those two are clearly opposed in principle and that calls into question your judgement that nothing can or should be done by Ripple. Even if you were to turn out to be completely correct in that conclusion, it is basic respect - and a prudent check on your own judgement - to provide them with the information to reach a conclusion themselves. If this has nothing to do with RCL, and is solely due to bad gateway code then you shouldn't be playing favourites with which major gateways you alert and which you don't. Have you described the issue to Gatehub such that they can address it? If not, why not?
  11. @Duke67 @Hodor Glad you liked it!
  12. This may help: Given that as a background, I think I can understand @ripplerm's position (though I don't agree with his conclusion). If he has knowledge of how to drain gateways funds arbitrarily, he is faced with either: 1) The gargantuan task of trying to make contact with every possible gateway on RCL, in every language they may speak, along with somehow validly defining who is a gateway and who isn't. Further, anyone he informs could use the information to protect themselves whilst attacking someone else. It'd be nigh on impossible to ensure the safety of everyone simultaneously. 2) Disclosing the issue privately to Ripple, and expecting them to successfully implement 1), when - in his view - they may be biased toward only supporting a handful of major players at the expense of everyone else. I can understand it'd be a frustrating predicament, but I feel this "deadline" reveal is a bad idea, especially considering how quickly and well Ripple responded to the prior issue. Personally, I feel he should take option 2. Ripple are better equipped than a lone-actor in any case, and it's very much in their interests to assure the safety of everyone using the network. Most importantly, as @nikb has suggested, there may well be an option 3): Fix this at a protocol level and push all the updates at once, so all gateways are taken care of in one hit. At the very least, Ripple should be given a chance to properly assess the claim - nothing can be lost by that and much could be gained. They are the custodians of the network, and they invented it. They should be given the chance to do their job. If they are denied that, then IMO, any negative fallout from this would rest solely on @ripplerm.
  13. It's obvious that multiple interpretations of the meaning of the term "gateway" is leading to some confusion here. To be clear - anyone with a Ripple account can become a fully-fledged "gateway" in around 3.5 seconds. ( @tulo explained this in one line recently, but I'll go over it in more detail.) A gateway on Ripple could be most simply defined as: any account on the Ripple network that has a negative balance of one or more IOU's. Ideally, this gateway also employs some mechanism to honour its IOU's, but that is entirely optional (hence the term "malicious" or "bad" gateway). If any of you reading this have a Ripple account, you can say to your friend "Hey, add a trustline for $1000 USD to my Ripple address!". If your friend then does this (it will take around 3.5 seconds), you are then able to send them up to $1000 USD over the Ripple network. The only difference between you and someone else doing that (such as Gatehub or Bitstamp), is the issuer address of those USD. Let's say your account address is "rMyAddressOnRCLThatIsNowAGateway ". When you send your friend $1000 USD, you are actually sending them USD.rMyAddressOnRCLThatIsNowAGateway (just like when Bitstamp sends USD.rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B to an account, "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B" is Bitstamp's issuer address - it's the account on the RCL that has negative IOU balances in it). In your case, after sending your friend the USD, your account "rMyAddressOnRCLThatIsNowAGateway" - in whatever wallet you look at it in - will show negative -$1000 USD.rMyAddressOnRCLThatIsNowAGateway, and your friends account will show positive $1000 USD.rMyAddressOnRCLThatIsNowAGateway. Your gateway "issuer address" is now rMyAddressOnRCLThatIsNowAGateway, and you can say to anyone in the world that you are issuing USD on the RCL. YOU ARE NOW A GATEWAY. You can go on and advertise that or do whatever you want with it. For example, if you go to the XRP/USD.bitstamp chart on and paste in your issuer address instead of the bitstamp one in the URL, you can get ripple charts to display charts for your gateway. (Which would all be probably empty at this point, but you and your friend could just post some standing orders to fix that...). You can at this point do ALL of the things that your favourite gateways do now. For example, you could insist that your friend actually goes to the bank and physically puts $1000 USD fiat into your physical bank account, before you will send them the $1000 USD.rMyAddressOnRCLThatIsNowAGateway over the Ripple network. The other thing you can do is wait for them to send the $1000 USD.rMyAddressOnRCLThatIsNowAGateway back to you over the Ripple network, and ask them to give you their bank account number, and then you can give them their $1000 USD fiat back into their bank account. You probably better get some KYC details though... ;P The important thing is this: Because on RCL anyone can, at anytime, become and stop becoming a "gateway", and because it's a completely open network and this can be done from anywhere in the world, it is basically impossible for anyone to act as "God of Gateways" and take responsibility for keeping track of them, advising them individually of issues that affect them and other such things. For example, you can't even be sure that the language you use to communicate the message can be understood by the person you're sending it to. RCL can be used by anyone in the whole world who has internet. To take an extreme example, there is nothing to stop an anthropologist in the middle of the Amazon jungle with a solar-powered satellite phone and internet connection listing an untouched Amazonian tribes chia-seed-based currency on the RCL and teaching them how to use the system through a custom iPad interface they developed so they don't need to faff about with chia-seeds so much and can just eat them instead. The anthropologist could teach them the system, show them how to recharge the iPads and maintain the solar batteries, and then tragically fall to their doom moments later. At this point, there is an Amazonian jungle gateway for a lost tribe listed on the RCL, and it is in full operation with active deposits and withdrawals being made by a bunch of topless people with spears, and there is no way for Ripple to contact them about any issue that comes up affecting gateways because no one at Ripple speaks their language, and - crucially - no one at ripple even knows they exist. I haven't checked recently, but years ago there was a website that presumably was tracking negative balances on RCL, and the last time I looked at it I think there were around 300-400 "gateways" according to it, that were operating on the RCL, and there may well be thousands by now. Remember: a gateway can be most simply defined as any account with a negative balance of one or more IOU's. There is no way to know if those IOU's are backed by anything, if they are just testing the system, or if they are taking deposits from people into bank accounts. Certainly, there is no way Ripple can keep track of it all, nor should they. That's the point of a decentralised and distributed system such as this.
  14. Cool you did that! I think the glyph looks good and it's a nice clear idea. The kerning on the font is off - mostly the T, but between X and R is a little too wide too. Maybe just use the glyph part? (It also might be best to keep the forum title as browser-rendered text, so it works with translations and can be sized correctly on different displays.)
  15. Actually, I agree with this. Though I would still say the issue is debatable - the proof is it's being debated... To me the choice by a user to hold funds in a defunct gateway implies the user is comfortable losing those funds in their entirety and without warning. The choice to maintain a trust line to one implies they are happy to receive funds they may subsequently lose. These are implied because of the wild fluctuations in price such assets can have and because the gateway could freeze the assets at any time. Of course the bug extended to encroach onto other IOU's, but the point is, had the user not chosen to maintain a trust line to a defunct gateway, they would not be at risk from that. Therein lies debate, and possibly never a clear answer as it can be validly seen from both sides. I think you did the right thing to report the issue publicly, and I also think you deserve the bounty, despite probably not having honoured its terms.