Oleg Andreev
Month
OS X is very old. It’s UI framework, AppKit is almost 20 years old (taking its roots in NeXTStep). AppKit has a lot of cruft and iterating it towards modern standards takes a lot of hard work. While UIKit was built on top of CoreAnimation from the start, AppKit had to incorporate it as an option which you can turn on and off. Or consider NSCells vs. recyclable views, or custom drawing code vs. configurable labels in UIKit.
iOS 7 shows how a complete rewrite may look like. If you want to update your app, you have to adapt it to new look and feel. And APIs. If you don’t want to adapt, the OS ships with fully compatible old frameworks to run your app as before.
OS X can use this trick in some future release. It can add to UIKit support of keyboard, mouse, menus and windows. Make it a default environment for the desktop and run older apps on AppKit which ships with OS for compatibility. New apps would have to be compiled and released with new tools and UIKit APIs. Older apps could still be maintained with older tools and compiled against AppKit, but AppKit would not get any enhancements.
This all would help with internals. On the surface users would only notice more advanced graphics and animations similar to iOS. This won’t change much the “feel” of OS X as it would still use keyboard, trackpad and mouse. But things like buttons and scroll views would essentially be the same. Having the same toolkit for both systems would reduce hassle by 80% at least.
Of course, since OS X would run on UIKit which knows about touch already, it would be interesting to think of a practical way to enable touch on conventional notebooks and desktops (if they are still around). That is, how and why vertical screens become horizontal, and how professional interfaces with lots of mouse-friendly elements can be adapted for touch (or why it’s not needed for them). Maybe in interim, OS X UIKit would not accept touches at all, but still provide a great deal of efficiency.
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender’s conditions are met.
The script is actually a predicate. It’s just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we’ll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
When you use private keys, people trust your digital signatures because they expect that you keep these keys secret. If someone steals your keys, he can impersonate you and harm your reputation. As a precaution, whenever you feel like your keys were compromised, you can publicly revoke them (by signing a message “this public key XYZ123 is now revoked” and securely timestamping it with Bitcoin blockchain). All signatures from that moment can be repudiated and you may start using entirely new private key.
Today the iPhone 5s was announced and some people started freaking out about it collecting your fingerprints and sending to NSA. We have a lot of documentation about how NSA infiltrates companies to steal data or takes it using an order of some secret “court”, so these fears are not entirely unfounded. However, it’s even worse because many foreigners coming to U.S. (and maybe some other countries too) have to give up their fingerprints at the customs. Anyone who was brought to a police department for whatever reason was also scanned. Now mentioning corporate security systems that use fingerprint scanners for some years now. Your fingerprints could have been recorded in several places already.
The problem with fingerprints is that you only have one set of them and someone may damage you by impersonating you on a crime scene. Just like with a private keys, when you think your fingerprints could have been compromised, you have to revoke them. The solution is not to try to cut off your fingers, of course, but to publish them as widely as possible. Then, if someone uses them somewhere, you have perfect protection: your fingerprints are not longer your private property and could not be used against you.
Of course, publishing your fingerprint will diminish the usefulness of the Touch ID sensor in iPhone 5s, but that’s the price to pay when our governments keep people in jail for decades based on some biometric evidence.