semiel

> And if you cannot trust the police, it is already too late.

No. Life went on in the USSR, despite the police being manifestly untrustworthy. Life goes on in the US and UK, despite the police being manifestly untrustworthy (albeit to a lesser degree). You still have to make choices and decide how to live, even when you live in one of the authoritarian regimes that form the majority of the history of human societies.

Those aren't securities, though, because their value doesn't depend on the efforts of the seller, which is one of the prongs of the Howey test.

It's of course possible that Bitcoin had less than a 1/10000 chance of hitting $10,000, and we're just living in an extremely unlikely world. But given that it _did_ happen, it's probably fair to bet that it was possible at the time to give it better than 1/10000 odds.

LessWrong is all about the Bayesianism, which means being comfortable with probabilities, even though it means you can never be "sure".

> It doesn't make sense to dump all your resources onto every new coin that pops up.

No, but if the odds work out, then it definitely makes sense to dump a _small_ amount of money into the ones you think have a shot.

This is exactly how startup investing works: http://www.paulgraham.com/swan.html

> Confirmation bias. How many things were discussed on rationalist websites that people were sure were going to be yuge, petered out, and were forgotten? You can't claim victory for rationalists without factoring in the ratio of failed predictions.

If there are indeed more than 10,000 of these, then I agree it's selection bias to only look at the successful one. Do you think there were? Personally, I'm having trouble coming up with even a single equivalent case, though I'm sure there are at least a few.

Yep, and we pretty much know what the solution will look like: zero-knowledge proofs, such as the ones used by ZCash.

Why does it matter if it's dangerous if used incorrectly, if the majority of users use it correctly, and the overall effect is that fatalities go down?

Surely they can not turn on autopilot, if that's the case?

For me, I prefer life over a false sense of control.

It was a badly designed app written by a couple of over-eager developers who didn't have any security plan in place. If you blamed the language every time a website got hacked, there wouldn't be any languages left.

That's why you have backups.

I agree that having full control over your identity has risks as well as benefits, though. I expect that we'll eventually see security providers arise that have user-friendly account recovery tools. Due to the plug-and-play architecture of blockchains, that sort of thing will work automatically without any need for organizations like Aragon to integrate with them.

Solidity is not an ideal language, but I also think that the ~deep concern~ everyone has about it is overblown. C is a pretty problematic language too, but plenty of reliable software is built in it. Engineering and testing practices are more important than bikeshedding the language itself.

They are comparable, though, and that's exactly my point. They're not the _same_ by any stretch of the imagination, but it's just a weaker reading of history to refuse to consider themes that were common to the time period.

The Nazi camps were started for the same reason as the American camps: to contain and control a population believed to be subversive. They were indeed later used as part of an organized genocide, which is very important and makes them far more horrifying on a moral/human level, but it's willful blindness to ignore the deep similarities between a policy of containing and suppressing a racial group, and a policy of containing, suppressing, and exterminating a racial group.

Since these countries (in some form or other) still exist, it's tempting to start making moral comparisons and trying to figure out "which side you should be on". But that's not the most interesting approach, in my opinion. Future historians won't be picking sides, they'll be trying to put it in context, understand the conditions that led to these behaviors, and draw out trends in the period.

I can imagine a section in a future history textbook that went something like this:

"A distinctive feature of the Second World War was the widespread use of 'concentration camps'. These camps allowed belligerents to separate and control groups (usually racially defined) that were considered potentially subversive. In many cases, those interned were put to forced labor in support of the war effort, but in others they were simply kept under military control.

Conditions in these camps were generally poor, but they varied greatly both between and within countries. The Japanese in American concentration camps were subject to undernourishment and forced labor, but relatively few were killed. Things were worse in the Soviet Union, where even the process of transportation to the camps was deadly to large numbers of Volga Germans. The most infamous camps were in German-controlled territory, where millions of Jews and other undesirables were systematically executed, in an event later known as 'the Holocaust'."

Citation: https://en.wikipedia.org/wiki/Flynn_effect

> Some of it sounds ridiculous - for every new federal regulation, 2 existing regulations must be eliminated. How is that considered feasible by any rational person? It might sound great if you don't think too hard about it.

Canada has a variation on this law.

http://laws-lois.justice.gc.ca/eng/acts/R-4.5/page-1.html#h-...

On the other hand, it's much easier to protect your Bitcoin keys than your credit card number. Credit cards basically require you to share your password with anyone you want to buy from, which is a pretty ridiculous security model.

If you really want to get paranoid, you can buy something like a Trezor[0] or other hardware wallet. I'm pretty sure it would cost more than my net worth for someone to figure out how to compromise it, given the lengths[1] they've gone to to secure it. There's no equivalent option for credit cards.

[0] http://bitcointrezor.com [1] http://doc.satoshilabs.com/trezor-faq/software.html

> So what are the implications of an object that breaks that symmetry? Would it be possible to observe an object in different times in the same state, or the same time in different states?

The object would be in a repeating set of states. First state 1, then state 2, then state 1, then back to state 2, etc.

This is not in itself surprising. Think of a pendulum, for instance. The difference here is that the motion is the lowest energy state. Over time, a pendulum swing decays. This does not: it will continue forever, if not disturbed.

The obvious next question is: isn't that perpetual motion? According to the normal dictionary definition of those words yes it is, which is why this is a fascinating discovery. However, it doesn't violate the normal arguments against perpetual motion, because there's no way to extract energy from the system. Anything you did to influence the motion would require adding energy.

Really? I haven't heard about this. I'd love a link if you have one.

It took me way too long for this reason. I got it instantly once I realized I had made that limitation up.

I feel like there is some sort of lesson, here.

I mostly disagree. You definitely need to know the basic abstractions and concepts, like blocks, transactions, and addresses. But they're not particularly harder than concepts like inheritance or pointers, and way easier than something like monads.

I can't think of any reason you'd need to know "bit lengths of various classes of data" for normal development.

> The major issue ethereum is going to have is making a case that there's a real-world value add relative to centralized, traditional architecture before many people will be willing to stare at it long enough for the easiness to set in.

I definitely agree with that.

I've been working in the Ethereum space for a year and a half, so I know my perspective is warped, but I really don't think the learning curve is that bad any more. Solidity isn't a very complicated language and has decent documentation[0], and Truffle[1] and TestRPC[2] can get you writing automated tests against a simulated blockchain more or less instantly.

It's still relatively early days, and there is a lot more work to do in making this stuff as friendly as possible, but progress has been pretty rapid.

[0] http://solidity.readthedocs.io/en/latest/ [1] https://github.com/ConsenSys/truffle [2] https://github.com/ethereumjs/testrpc

The point is the security professionals exist in order to facilitate the needs of the users they serve, not the other way around. It's always easier to just say no, but a good security professional knows how to assess risks, find creative ways to mitigate them, and serve the needs of the user to as great an extent possible without compromising security.

AlphaGo isn't a fixed strength, though. It's substantially stronger now than it was in October. Obviously it's not a completely continuous function, but I think it's close enough to cause this effect.

I think there's something analogous to the anthropic principle happening here. This match is happening now because Google realized we are in the moment when Go AIs are passing the top players in skill. Two years ago, Lee Sedol would have won easily. Two years from now, AlphaGo will win easily. In either case, the match wouldn't have happened at all, or wouldn't receive the same amount of attention.

Step 1 of exploiting this is "play a brilliant move to win a fight in the middle game", which is not the easiest thing to repeat.

It actually seems clearly the opposite to me. This approach uses standard tools and methodologies for which there are already experts. Asking Apple to write new firmware has the potential of software bugs and similar unexpected issues.

I have the top post in the reddit thread this is based on[1], and I don't endorse the spin of this article.

> smart contract programming is complex and at the moment is lacking functionality

I disagree. Smart contract programming in the Solidity language[2] is already remarkably simple, and there are great tools like Truffle[3] that provide you all the necessary scaffolding for rapid iteration.

While it's certainly true that there are challenges and limitations in smart contract programming, as I discuss in my reddit post, that's not the same as "lacking functionality". There are many things that are already easy to do, and the limitations are because we're working at the cutting edge of technologies that are still being actively researched.

> Homomorphic Encryption

This is a nonsense red herring. It would be cool if someday we had homomorphic encryption, but it's not going to be ready on any relevant timeline, and the "lack" of it is absolutely not a problem for Ethereum.

> Once the transition to Proof of Stake occurs, however, will the Ether coins have to be re-issued?

What? Of course not.

This article is trying very hard to turn a discussion of future research directions into FUD. 0/10.

[1] https://www.reddit.com/r/ethereum/comments/4945us/can_we_hav... [2] http://ethereum.github.io/solidity/ [3] https://github.com/ConsenSys/truffle

That was the previous version of the glasses. These are supposed to be much better, but we won't see specs until at least Wednesday, when the press embargo lifts.

Bitcoin can barely agree to a minimal blocksize increase. The Ethereum proposals for stuff like sharding would be complete non-starters in the Bitcoin world.

Currently, yes. However, the Ethereum foundation is actively working on addressing that limitation, and there are some very clever proposals for how to get around the problem. Unlike Bitcoin, Ethereum development is very active and the community welcomes major changes if they are worthwhile. I agree that Ethereum needs to solve the scaling problem to be successful, but I think Vitalik and the foundation have a good shot at doing it.