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/
HN user
pcmonk
http://pcmonk.me/ http://github.com/philipcmonk/ @pcmonk
Engineer working on Urbit
phil at pcmonk.me
[ my public key: https://keybase.io/pcmonk; my proof: https://keybase.io/pcmonk/sigs/tet7bohLuwyz-BYeBElYMeFlsAYxpfAv-FLVf5l4UZg ]
Was down for a couple minutes, is back for me
Most of them don't seem to come from pull requests, I wonder if it's paired with a bunch of compromised github accounts?
I think the answer is something like:
- 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.
I found it interesting that the patch was apparently published before it was exploited: https://twitter.com/kelvinfichter/status/1489050921938132996
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.
I think your n_subjects is too low. You need that to be high enough or you'll miss those low-probability winners that bring up the average.
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.
Maybe related: in Spanish, "carpa" means both "carp" the fish and "tent".
I never thought to ask why they're the same, but Wikipedia says "carpa" as "tent" comes from Quechua and as a fish comes from Latin.
For terminal stuff, you can't beat the ease of use of asciinema.
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.
https://www.drdobbs.com/jvm/an-algorithm-for-compressing-spa...
You're off by an order of magnitude. 3% of 150m is 4.5m.
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?
The article doesn't say anything about hashing the password, this is a perfect case of the title having a large influence on how we read the article.
@dang This title is misleading.
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.
For another perspective, SB Nation's announcement: https://www.sbnation.com/2019/12/16/21024100/thank-you-calif...
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.
This is SB Nation, they have >100 separate sites (one per sports team in the leagues they cover, plus some extras), and they each have an "editor-in-chief" which is specific to that site and manages that community. It's not always their day job, as in this case it isn't.
If it's actually p2p, you don't need petabyte scale. You just need to store what you post, which for most people is megabyte-to-gigabyte scale.
If you're interested in tools for this, Logos Bible Software is quite good.
Isn't that saying Boeing is going to launch their capsule uncrewed, just like SpaceX did back in March?
Yeah, I actually keep my editor columns at about 65-70 with :set nowrap. I find this gives me appropriate pressure to write shorter lines, but if I go past the end I've got another 10 columns or so until I hit 80.
It lets me have 3-4 columns of code on a standard laptop or 8 columns on a 4k monitor, which is a huge productivity win.
the area with the color they can't see gets a lot darker
Interestingly, for me (deuteranomolous) the colors I can't see often seem lighter. For example, green traffic lights appear white. I assumed this is because I can still see the light, it just doesn't get interpreted as green, but I don't know whether that's true.
I'm generally opposed to accelerationism because it's too black-and-white. When there's some good to preserve, that's usually worth preserving. However, in this case I think we're already at the bottom since these methods are used regularly. Having a coworker know whether I read their email is the most benign version of tracking (even though I still don't like it).
The difference to me is that accelerationism says "it's bad; let's make it worse so that people will realize they need a revolution". Anti-theater says "it's bad; let's tell people know how bad it is".
I hate tracking pixels, read receipts, and all similar stuff. The only thing worse than lack of privacy, though, is privacy theater, and that's what we've had. It's a good thing for more people to realize that this stuff happens all the time, so they can take action about it if they want to.
This has been the case since always. It just wasn't as obvious to users because consumer-oriented mail software didn't include it.