Anyone can create a random key with a random email. See all the [email protected] addresses on the keyservers. So if they used the keyserver network I could just make a fake key for anyone I want to impersonate and upload it. Github has no way to authenticate which keys are good and bad if they only use the keyserver network. So they have you upload the key on their site to implicitly authorize the key as one that you (the person with the github account, or at least its password) consider valid.
Keybase lets you do some key stuff, but the bigger feature is that it provides a bunch of ways to authenticate the source of a key above and beyond the WoT and getting into the strong set. Authentication is an inherently hard problem. With keybase you can, for example, see that the key that you want to use to send an encrypted email to [email protected]'s website is owned by someone who also controls [email protected]'s twitter, reddit, github accounts, web-site, etc, making it less likely that there's a MiTM going on.
It depends on whether they use PGP/MIME or inline PGP. Without installing the tool, I'm guessing they use PGP/MIME, because you pretty much can't use html email with inline PGP, and I doubt they're going to default to plain/text mails.
Actually the current guidelines are pretty clear. Mining is income. When you receive your coins from mining, that's a taxable event. Current value - mining expenses = income. After that any gains or losses are unrealized until you sell, creating another taxable event. Current price - cost basis = capital gains. Since bitcoins were worthless when Nakamoto was mining, he has no tax bill there. No taxes are owed for simply holding the coins. If he sold today, he'd be taxed at the long term capital gains rate of 15% for 100% of what he sold.
EDIT: but of course I'm making the silly mistake of assuming he's an American.
Inflation adjusted, that would put him in the range of Rockefeller, Carnegie, Vanderbilt, Mellon, etc. If (and it's a big if) bitcoin was worth as much as the world gold market, it isn't disruptive like an internet startup, it's disruptive like Marxism. We could argue about the insanity suggesting that bitcoin will reach that sort of value, but if it somehow did, then $500 billion isn't totally out of line.
True, but they were able to process a single quarter-million dollar transaction and easily turn that into 'real' cash. That's still a pretty decent accomplishment for magic internet money.
Switzerland has its own currency and its own central bank. It doesn't use the Euro. So the money doesn't need to 'paid for'. The government can just create the money and hand it out.
Of course this might devalue the currency as a whole, but the central bank had to institute an exchange rate floor because Francs were becoming too expensive relative to the Euro. So they probably wouldn't even consider a minor devaluation a bad thing.
All the telecom companies, which cooperate fully with law enforcement, charge for their services. It's perfectly fair to bill time and materials that you can no longer use to improve your business and generate revenue.
These guys are complaining about disk space and bandwidth, not message security.
Even so, the current network can probably handle 100,000 messages a day, and the bottleneck there is some side channel timing attack mitigation code that causes the client to sleep while syncing with a peer. If you separate out the message syncing from the decryption process and eliminate the timing attack potential, the network can easily scale to a million messages a day or more.
At that point, the messages will need to be broken into 'streams' so that you can partition the traffic. The protocol supports this, but punts on the implementation details, so there's no easy way to implement multiple streams at this point in time.
But I would hardly describe that as full-on 'fail'. Everyone-shares-everything is a design feature to preserve anonymity. It's more difficult to tell who sent a message, who received it (if anyone), who was able to read it (if anyone), etc.
Reading more on this software, it seems like they try to solve the capacity/bandwidth problem by using a distributed hash table, but now the protocol requires a lot of handshaking with specific machines that has potential to remove some anonymity, and also potentially makes it easier to prevent a user from getting messages. Block enough traffic at the Great Firewall and you might not be able to get messages. [Take the above listed weaknesses with a grain of salt, I haven't done an in-depth look at the protocol.]
But in general it's probably premature to worry too much about scaling, since the bitmessage network can already handle several more orders of magnitude than the current traffic levels:
This seems very similar to bitmessage, which has a functioning client and 1000's of active nodes. Why would I wait for this instead of using bitmessage?
The problem is that you don't sent to the destination SMTP server. You send to your SMTP server. That goes at least one hop via SMTP and eventually ends up on the destination's domain server.
So even if I setup and host my own SMTP server, and even if I verify the TLS certs on my side, I have no way to verify that I'll get (1) A TLS connection (2) with an authenticated cert all the way to the ultimate destination.
It's beyond my control to ensure that I'm secured when emailing to an arbitrary domain with arbitrary configuration.
Meanwhile, per the Washington Post article, he asked the guardian to setup PGP in Feb, and his contact finally did so in March, both before this key's listed creation date.
Technically you want to submit a Privacy Act request to get records on yourself which is different than an FOIA request. But the NSA will just deny the request with a form letter.
Okay, so lets assume that the NSA has quantum computers that can decrypt RSA and ECC with ease. They would have to assume another state funded effort by someone like China could do so as well. Then the NSA wouldn't issue recommendations that the US Government itself use these encryption methods for TOP SECRET and CONFIDENTIAL documents.
http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=p...