The yield varies with a few factors, chief of which is how much total ETH is staked. More staked ETH means a lower yield. Here's a calculator: https://ethereumprice.org/eth-2-calculator/
- the dollar is falling compared to US living expenses (US inflation)
- the euro is falling compared to the dollar (exchange rate)
- therefore, the euro is falling faster compared to US living expenses
- but the euro is not necessarily falling faster compared to EU living expenses (EU inflation)
Indeed, EU inflation and US inflation seem to be about the same, which means that the exchange rate change is not because one or the other is experiencing more inflation.
This isn't correct. There's no Solana tokens in the equation at all, so I assume you mean wrapped ETH on Solana, and that all got sent through the bridge to Ethereum, so it doesn't exist anymore.
In practice the people who are doing this very likely have that much ETH on hand and can simply use it, then rebuy over time to get back to their preferred holding levels.
If you had $320mm USD and needed ETH, you'd want to use an OTC desk, because the markets will feel it, even though they won't actually run out of depth. Right now the "+2% depth" (https://coinmarketcap.com/currencies/ethereum/markets/) on Coinbase, Binance, and FTX is about 5mm, and there's probably a dozen other markets with similar depth, though you'd want to execute the trades simultaneously. Decentralized exchanges have depth too; uniswap's USDC/ETH pool would let you buy $40mm for 2% slippage. All in all, you could probably get it all at about a 5% premium if you were really prepared for it.
That's why it's sometimes called an "argument" or specifically a "cryptographic proof". You can construct the statement such that it can be "proven" in a traditional sense by adding qualifiers such as "with probability more than 1-1/(2^256)". You'll generally need an assumption like knowledge-of-exponent or at least hash soundness.
The most natural solution for most people is to give shards of your key to various friends/family that you trust not to collude and reconstitute your key (or be socially engineered -- make them talk with you on video chat or something). Require 5 out of the 9 shards to reconstitute it.
Obviously you can scale up your security according to the value of your account and your threat model.
(not the author, but I'm an Urbit core developer, so I can read this pretty easily)
You're pretty much correct. lib/server.hoon doesn't "set up" the server exactly, that's built into Urbit. In general, apps communicate by sending commands ("poke") and subscribing to data ("watch"). A normal HTTP request is just a poke of type "handle-http-request". The js frontend can also subscribe to your app.
lib/server.hoon is a (mostly standard) library of helper functions that mostly convert from various internal types to HTTP responses, so they add the the HTTP response code, mimetype, octet-stream length, etc. There's also a function that wraps an HTTP response handler to redirect to the login page if they're not logged in. Most apps that have a web interface use these functions, though I think the author may have added a few more filetypes.
app/canvas.hoon, as you guessed, manages the main state of the app and syncs it to other urbits. An app's commands can be seen in +on-poke, which in this case calls +handle-canvas-action, where you can see all the different commands this app takes. For example, %join subscribes to the "canvas" app on another urbit on path /canvas/foo where "foo" is the name of the image. The rest of the commands can be traced in the same away. +process-remote-paint is the part that actually processes a new list of strokes from either another ship or the %paint poke; it updates its own state and gives updates on /canvas/foo.
app/canvas-view.hoon is the app that serves the html/cs/jss and handles browser requests. It has a similar set of pokes, and most of them are just forwarded to app/canvas.hoon, but some of them are handled directly. This is a different app from canvas.hoon to keep separate the essential logic of the app from the work needed to serve it to a browser. One could imagine writing a command-line app which used canvas.hoon, and it wouldn't need to talk to canvas-view.hoon.
Probably a few months for a really usable version of it, though seeing stuff like this makes me really want to finish that work. I'm working on it, but first we're reworking the software update process in general. That work is getting pretty close.
I recommend trying out stuff like this on moons, so you can just throw them away if it breaks.
Very cool. One of my formative programming experiences was learning the "hashlife" algorithm, which lets you do very large maps and zoom forward millions of iterations very quickly.
Seven weeks ago there were ~100 cases in Wuhan, now there's 60k. What's to stop that from happening in Seattle, or the Bay, or anywhere else in the developed world that isn't taking the precautions China did?
Can't read the article because the captcha won't load, but this reply doesn't make any sense. What can the browsers do without the cooperation of the server? You don't really need encryption to deal with that specific problem, but you do need signatures, which means you need a certificate anyway. It's quite a strange attitude toward the problem.
Notably, this thread is full of people blaming SB Nation for not converting IC's to employees, which is exactly what they say they're going to do, though not everyone will end up with a job at the end of it.