Jump to content

Professor Hantzen

Member
  • Content count

    324
  • Joined

  • Last visited

  • Days Won

    1

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
    https://twitter.com/phantzen

Profile Information

  • Gender
    Male
  1. New payment partners in Q3

    Any such announcements might be part of the Q3 report which isn't yet out, or given the impending Swell conference, held back until just before or during that.
  2. 700,000 ripple stolen from my gatehub account

    That's probably a good definition. But, yes - there is no way to have 100% safety even with a cold wallet.
  3. 700,000 ripple stolen from my gatehub account

    The person you're replying to spelled out correctly and usefully what a cold wallet is, what a warm wallet is, and what a hot wallet is. These terms have existed in cryptocurrency for many years, and are consistent and well-known irregardless of which currency they are used with. You can read definitions interchangeably for Bitcoin cold and hot wallets, for Ethereum, for DASH, for Litecoin and for Ripple, etc - they are all the same. Google the term enough times and you will discover that the definition you've been given here is the most correct and useful. The reason the definition you quoted from the Ripple site is incomplete in its description is likely because terms are so prevalent and well-understood that the writer of the page assumed the reader already knows their common definitions. The writer only added the relevant gateway-specific information because the page is intended to inform the reader about gateways.
  4. Ripple should IPO now

    IMO this would be a solution to a problem that doesn't exist. Ripple is doing great as a company, has more than enough money and cashflow, and is making progress at a consistent rate. Faster is not better when you're building mission-critical software that needs to have extremely high integrity and be able to function more or less perfectly 24/7 with potentially millions of connections/clients at any given time. Let others rush and shoot themselves in the foot playing catch up, Ripple has had four solid years and any competition is missing at least half of that.
  5. Ripple Labs v. R3 (actual court documents)

    Apologies - I couldn't find the thread when I searched (both the forum search and my activity stream), so assumed they'd be moderated out. It's odd as I just had another look now, and it came straight up:
  6. Ripple Labs v. R3 (actual court documents)

    @brjXRP17 Excellent work! Thanks for posting these and for the great summary. To be clear, others have previously posted the court documents - but the threads have been removed. I'm not sure why - these are documents that are part of the public record as I understand it. A previous poster also did not include the TPA (which may contain the crux of Ripple's complaint), but did include a short excerpt from it. Do you have the TPA also? Could you explain any legal rationale you or someone else may have for excluding it?
  7. Higher Transaction Costs

    I'm going by the stated 1000txns/sec. It's recently been doing about 8txns/sec, and has handled greater loads in the past without fees going up by factors of millions.
  8. Higher Transaction Costs

    This is a fair point. But regardless of which metric of value is used, the fees were too high for the system to work as intended. This is an error condition, and not intended, as evidenced by various Ripple employees statements regarding the situation as a "problem", "bad behaviour", etc. The code certainly allowed for 75,000XRP fees to be recommended by rippled or it wouldn't have happened, but this not a state that was intended to have been reached when the network is operating at less than 1% capacity.
  9. Higher Transaction Costs

    I see this as a grey area, and believe you're missing a key point. The community here, using the open source protocol has contributed in adding significant value to the business offering Ripple is making to banks and whoever else. Mr Ripple (the market maker who paid the fees in question) is one of the largest market-makers operating on the ripple ledger, were it not for their activities, and those of other participants very much like them (myself included), the ledger would have very little activity, had far less stress-testing, and on the whole come across as a far less attractive option for crypto exchanges to list, and for investors - whether crypto or otherwise - to put money into. A major part of the price rise and the now multi-billion dollar market cap Ripple enjoys has been the fact the asset listed on so many exchanges. Exchanges wouldn't take the time and expense to list a visibly dead coin. Regardless of it's open-source origins and the traditions that may exist there, Ripple is positioned somewhere in the middle of that and a client-provider business relationship, with the benefits and drawbacks of both to both parties. We are breaking new ground here - what is occurring in payments and value transfer does not exactly fit into old paradigms. We are defining new ones, and I simply want to see Ripple being pro-active when it comes to redressing their mistakes.
  10. Higher Transaction Costs

    If USD$15,000 fees are intended, I'm out - and I think just about everyone will be joining me. ;D
  11. Higher Transaction Costs

    I have the same ethic - it's one reason I don't use ripple-lib (other than to sign transactions sometimes, though even that nearly burned me once). To be clear, I'm not advocating blame. I'm suggesting responsibility. The difference between the two is who acts first.
  12. Higher Transaction Costs

    I understand your reasoning. However, this situation does not fit with it. It is beyond the reasonable expectation of client trust in a system designed and publicised as enabling transactions with fees in the region of tiny fractions of one single US cent (and that has been providing such consistently over millions of transactions spanning 4 years), that rippled was advising the client they spend the USD equivalent of $15,000 cancelling a single transaction, and that Ripple's provided example client script for transaction cancellation was happily spending this amount multiple times over. While technically you can say "user beware", I say that if this situation is the result of code that Ripple wrote that they did not intend to result in such erroneously high transaction costs, then my opinion Ripple is responsible for the overwhelmingly larger part they played in creating the unintended expense. In principle, and in general, I agree with the assertion regarding a user's responsibility for their own funds when using an in-development system such as this for value transfer. There is some argument to be made that the user could be more careful regarding trusting the server to suggest reasonable fees, but a very similar argument could be made for all of us trusting the system to simply even hold our funds at all. If an intended "feature" of, or "bug" in, rippled code one day resulted in an account or accounts suddenly having hundreds of thousands of XRP less than it did from one ledger close to the next, I would expect Ripple to make some kind of redress with the account owner(s) along with correcting that unintended situation in their code. At some point, and this looks like it may be such a point, it is possible for the creators of a product to make a mistake. I believe they can and should hold themselves responsible for the impacts on those using the product in such a situation. Samsung didn't intend their tablet batteries to explode during ordinary use, but an argument similar to yours could well be made for the risks of people choosing to use products with Lithium batteries in them. The question is which world do we prefer to live in?
  13. Higher Transaction Costs

    That's highly unlikely. For a few years the Ripple network ran fine (sometimes at higher load than now) without the currently-problematic fee escalation code even in place. It's a relatively recent feature addition. I do have concern that the cause is someone exploiting weaknesses in the fee escalation algorithm. I'm sure that's fixable but it would look bad and tarnish an otherwise largely clean security record for Ripple. Though, even then it wouldn't be the end of the world - look at Ethereum's precedent and that's still going strong.
  14. Higher Transaction Costs

    Actually, it may be somewhat revealing that such a fix hasn't been employed. We could infer from this that there is a reason it hasn't been employed, and about the only thing I can think of is some kind of ongoing spamming or other activity for which the fee escalation is having some beneficial preventative effect that presently outweighs the inconvenience and cost.
  15. Higher Transaction Costs

    I am surprised at the lack of communication, but not that the fix is taking a while. IMO, this is the the most significant issue or bug in rippled since Ripple began (which could be considered somewhat of a backhanded compliment...). In conjunction with the ripple-lib example script, the situation has arguably cost client funds. It's not something to take lightly. However, there should be better communication right now - though I wonder if the nature of the issue internally may require stealth until a fix is employed. We just don't know, unfortunately. A hastily-employed patch or cap could also cause the problem to become worse. It's not as simple as employing only a cap (and I didn't mean to suggest that in my earlier post). Whatever underlying issue causing the fees to escalate too high needs to be addressed prior to employing any cap on fees. If it isn't, fees will simply rise to hit against that cap and even more transactions could fail.
×