The tech apparently works for 80% of color blind persons, by blocking certain wavelengths that otherwise overwhelm the color blind person's perceptions of certain colors.
Once the eyes adjust to the diminished total light transmitted by the special dark sunglasses, the admitted wavelengths allow the color blind person's eyes to perceive the previously missed colors.
Simple in concept, awesome technology. About $300 a pair and are available to meet those who need prescription lenses.
The programming classic "Mythical Man Month" had a chapter for the "second system effect". Its where developers put lots of complicated features in to the second system in a series. Its a pattern for failure.
In this case, Ethereum developers built a much more complicated cryptocurrency by making it Turing complete - to the extent of writing their own new computer language and virtual machine to run it.
They skipped over the halfway step of declaring parameters in the payment transactions, that open source enterprise library code, e.g. Java, could execute for for required behavior. No. They made the new code itself a user-contributed and immutable! part of the system.
That's actually a pretty good decision in my opinion. At least in this case. Think what would happen if they went for alternative solutions:
1. If it wasn't immutable, you'd never be sure when a contract changes. That's the basic assumption about contract - once you sign it, whether in real world, or by doing some action in Ethereum, you don't expect it to change how it works. That's why immutable is good.
2. User-contributed is just how it's supposed to work. It's decentralised. Everyone's a user. The content has to be user-contributed. Having some central publisher/gatekeeper is contrary to the whole idea.
3. Own VM is debatable. Sure, they could go with JVM, but the scope would have to include much more complexity (classes, namespaces, etc.) than just function/instruction execution. Maybe the limits of javacard would be enough, maybe not.
I really don't think the second system effect applies here. It's not a rewrite of something that existed and had issues.
Solidity contracts are already modules which contain functions. They're equivalent to Java classes with static methods or Scala objects. As for namespacing, I don't know how in this day and age programmers can say that's not worth it.
Solidity contracts do contain functions and some state. But that's at a fairly different level than Java's classes. Internals are not exported. The contract's structs belong to contracts. There's no need for namespaces within code because addresses provides namespacing already - all your code is normally visible to you already and you'll not get unexpected names shadowing anything in your code.
I'm not saying namespacing is bad, just that namespacing as defined in Java is likely not necessary in ethereum world, as I understand it. It would likely just confuse what's immutable vs what's referenced by name.
Turing-completeness was the entire conceit of Ethereum, as I understand it- without that you would have Bitcoin with a few bells and whistles, and no one would bother. And once you're committed to that, a new language and environment are essential- something this entire fiasco shows is that a language for contract programming has very different requirements than what software engineers are currently used to, in order to be safe in ways that don't apply to ordinary software.
In all likelihood, a working and reliable Ethereum simply requires computer science theories we don't have yet. A working Solidity would probably look something like Ada, but with types and invariants the likes of which we've never seen. Its potentially a very interesting research subject! But for now, yes, investing in Ethereum is like climbing aboard in a rocket aimed at Mars- exciting and futuristic, but unlikely to get you where you hope to go.
I think we have a lot of theory about turing-complete computation. I really wonder why somebody would be willing to sign a turing-complete contract? The problem of understanding properties of the contract may be NP-hard [1] i.e. practicallly uncomputable. It may even be undecidable by involving instances of the halting problem [2].
It is undecidable in the general case as shown by Rice's theorem [1].
[...] Rice's Theorem may essentially be generalized from Turing machines to most computer programming languages: there exists no automatic method that decides with generality non-trivial questions on the behavior of computer programs.
Of course, that doesn't mean you can't prove anything. It just means you can't prove things generally and automatically. For example, you can't solve the halting problem in general, but you can most definitely prove that a specific program terminates, or that large classes of programs all terminate. The proof of Rice's theorem boils down to the impossibility of the halting problem.
The parent comment asks why someone would agree to a "Turing complete contract". But it's not necessary for an Ethereum contract to be "Turing complete" any more than Quicksort is "Turing complete". If the contract's code does something simple, we can verify and prove that it behaves as expected. It wouldn't be impossible to create a "safe" DAO-like contract.
But wouldn't Ethereum be a lot safer to use if its contract system would only have so many degrees of freedom, that all side effects and properties of contracts were computable for all contracts in a practical amount of time?
With the current system I imagine one could even utilize homomorphic encryption to implement another Ethereum inside Ethereum that is cryptographically protected not only against modification but also against inspection :)
I'd love to see an example of such a restricted contract language. My speculation is that we'll see a few different languages pop up with different approaches to safety, along with coding methodologies and tools for static analysis.
Maybe we'll also discover a handful of primitive contract building blocks, to be implemented with care and stringency, with methods for combining them.
> The problem of understanding properties of the contract may be NP-hard [1] i.e. practicallly uncomputable.
The difficulty makes good contract design a valuable service (like hiring lawyers). Otherwise everyone would just write their own contracts. A more declarative, less powerful language would have opened this up at the expense of contract succinctness.
Is it a case of Second System Effect, or Build One to Throw Away? I don't have an opinion either way, but just pointing out that the very same pattern is also known as a successful one in some cases.
Build one to throw away means you're building the same "system" again, but with more specific requirements based on what you learned. Second system effect is building a bigger system will broader and vaguer requirements.
(Also, Brooks later said: "This I now perceived to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction." He wrote a later book, The Design of Design, encouraging iterative development.)
The Ethereum community proposes to roll back their blockchain to reverse the theft of 3.5 million ETH.
Here the thief proposes to independent ETH miners that enough of them refuse to rollback the ETH blockchain, by virtue of staying with the old version of the software.
If the ETH blockchain is not rolled back, the thief proposes to share the loot - about $10 million worth - with the agreeing miners, making them collaborators in the theft.
Apparently, the attackers also shorted ETH before the attack. Given the resulting ETH price cash after the attack, the attackers made off with real bitcoin by closing the short trades, even if they fail to withdraw any of their stolen ETH.
In some possible world, a US president Trump and congress should impose a 50% tariff on imported goods, services and intellectual property, in steps, over a five year period.
I read the convincing CrowdStrike detailed and technical description of how the DNC server got hacked. CrowdStrike saw the tracks of two known Russian groups.
The published documents to me look real. The SECRET document from the State Department had the obviously secret item that the USA will not nuke terrorist training camps nor hideouts in Pakistan. Official US policy is that all tools are on the table.
Question is how did the SECRET document get on to the DNC server?
Regarding Guccifer 2.0, I believe this is Russia's obfuscation of their release of these damaging documents. They want to help Trump, but must not admit it for fear that Obama takes action now, Hillary takes action if she is elected, or even if Trump wins - Russians helping him might actually hurt him given the foreign interference in USA elections.
Those don't look like actual classification markings, which are required to appear at both the top and bottom of pages. It seems more likely that those are some internal Democratic party markings. Also the fact that the documents seem to be talking about the first 100 days in the future tense would point to them being planning documents produced by people in the party.
