What matters for the financial hedge is the existence of futures, which means the companies can buy something they know they will need at a known price months before they actually need it. The specifics of this operation differs depending on the actual financial instrument used, but the idea is the same, even on the opposite side (selling at a known price in the future).
It is already a sunk cost if they just bought futures, so shouldn’t keep them from flying. They can take delivery to fly, or sell for someone else to take delivery at the low price.
The hedge must be more complicated to explain why they would stay grounded.
Hmm. I don't think the hedge is that complicated, so maybe it's not particularly relevant after all. I was just thinking of it in terms of complementary goods -- normally we'd expect suppliers to increase output when the cost of an input drops, but in this case they already ate that cost so the effect would be damped. But maybe not?
I suppose there's also a question of how long OPEC floods the market. But IDK, and you make a good point.
The futures contracts don't always guarantee delivery. "Cash-settled" instruments just pay out cash based on the market rate (with the expectation that the long party can purchase the oil at that price)
Hashing the password in the client isn't very effective because the hash of the password now is equivalent to a password. If you have the hash you can just send it to the server and authenticate. Implementing this looks like a lot of trouble with little to no benefits, since you also have to take the regular precautions server-side anyway.
I wasn't arguing FOR hashing the password before sending it. My point was this: even if we think it's reasonable to require that a password be hashed before being sent over HTTPS, the corollary is that all web apps must use JS, and can't be server-side-code-only. And this corollary doesn't seem like a reasonable thing to require.
Your point that 'Hashing the password in the client isn't very effective because the hash of the password now is equivalent to a password.' is true if there's no salt, and if the password is never re-used across sites.
If the password is salted before being hashed and sent by the client, then having read-access to the plain text of the exchange only gives the attacker the ability to log in to that one site. Even if the same username/password combo is in use on other sites, the attacker can't use the password on those sites, because she can't hash the unknown password with an arbitrary salt.
Anyway, I'm definitely not an expert on this topic, so take what I wrote above with a pinch of salt (ha!).
My only reason to comment was that I was thinking through 'never send passwords' from first principles, and it struck me that, if everyone were to accept this to be true, they would also never willingly/knowingly log in to any site that works without JS.
Apparently it's caused by a bug with OS-specific code to check the last time a message asking for donations to the project was printed, so it doesn't ask too much. And this checking only happens on mondays for some reason... There's literally a "if (now.getDay() === MONDAY)".
What you're missing is that Tether is not truly bankrupt yet. Yes, sane accounting would say their liabilities exceed their assets, but only because 26% of their assets are a high risk loan to Bitfinex. They still have assets > USDT supply. What makes the liabilities exceed the assets is the credit risk associated with the loan.
You can't undisputedly say Bitfinex won't be able to pay the loan. Maybe the frozen assets are real and will be unfrozen soon. Nobody knows. They aren't bankrupt yet, but in a very risky position of becoming so.
Another possibility is that you misread the article title, which seems kind of misleading. It says that only 74% of Tether is backed by cash or cash-equivalents. The loan to Bitfinex is neither, so it should be the remaining 26% (26% of $2.8B is $745M).
That being said, I agree with you on the Wiley Coyote point. Tether should be completely disreputable, not only because of it's risky situation, but because the whole move was completely shady. Silently changing the wording of the website, after assuring everyone that they had it 100% backed... I don't see how anyone can trust it anymore.
The numbers aren't public yet, but it's probably low. I don't think they are dumb enough to expect this device to sell anywhere near the Galaxy S10 or an iPhone.
It may not be a huge sales success, but apparently it's above Samsung expectations.
My guess is the main goal is to recoup R&D prior to a proper consumer launch. And you know what, I'm fine with that. Personally, I'm holding out for gen 2-3 of this form factor when the price comes down to Earth. But smart of them to get it into people's hands where they can get real testing as to what works and what doesn't for consumers.
That might be some, I think for many it's just being able to buy "a piece of the future today".
Whether or not it ends up truly being practical, it's a phone that looks and does things that are radically different from most mainstream phones.
People will think their fancy future folding phone is cool, and other people will probably see it and think it's interesting and want to talk about it or see it work.
Kind of like paying $600 plus a 2-year contract for an iPhone in 2007 with a slow processor, no 3G, no MMS, no copy-and-paste, etc.
The webpack team has a simple solution: they have a bot that closes inactive issues. The issuer need not keep the issue alive by posting into the issue.
