There are good ways to secure a protocol from MITM attacks without resorting to a Central Authority for certificates.

For example, Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack.  Diffie & Hellman's key exchange protocol, if you are able to communicate with each other at all, allows you to generate a session key impenetrable to an eavesdropper.  The two can be combined, resulting in cutting out MITM attacks very effectively.  It reduces MITM to, at most, DoS.  And DoS can be done by people who aren't even in a position to eavesdrop.

Actually key agreement protocol is unnecessary; Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key.

The Central Authority for HTTPS certificates was never necessary except that certain powers-that-be needed central points of control where keys could be taken, enabling covert eavesdropping, and securely linked to physical-world identities, enabling prosecution.  And also because some people needed to make the system work in such a way that they could make a profit off it, and if it were implemented as protocol, it would be free of charge. 

The functionality of protection from MITM attacks could be far more effectively and securely implemented simply by using protocol between browsers.  For Free.  Essentially, the CA system is still open to insider attacks.  It depends on keys held by people whose secrets the keys are not protecting.  Worse, those key holders have identities known to the public, and are therefore  subject to theft, bribery, extortion, blackmail, court orders, security letters, gag orders, etc. 

I dunno.  We get along fine in physical space with cash that's non-divisible and non-joinable.  If there are standard coin sizes, and people are willing to make change, divisibility isn't really necessary.  (although TX fees and so on would need to be in whole-coin increments, like sales tax).

It has another aspect though; it is an attack on privacy.

Next time you pay someone bitcoin, that 2 Satoshi or whatever will be listed as a separate input along with it.  This enables someone watching the blockchain to identify additional coins in the transaction as belonging, as of the time of that transaction, to the same person who "accepted" the 2 Satoshi. 

So, if a mobster wants to know what someone is spending money on, he can send 2 Satoshi to any address he *knows* that person controls, and then watch to see where that 2 Satoshi gets spent - learning, at the same time, many *additional* coins his competitor controlled as of that time, that he wouldn't know about if he didn't know to watch this 2 Satoshi. 

Because the coin selection algorithm is predictable, the 'gift' can be precisely timed to ensure that the 2-Satoshi coin is included in a particular transaction that the attacker knows will be happening at some predictable time - such as, say, the Police Department distributing paychecks to undercover detectives.  And should coin resulting from *that* transaction later be spent, with no intervening tx, by one of his employees, that employee should hope his life insurance is paid up.

I believe that there ought to be a privacy-consciousness setting in the client; if you switch it on, it rejects dust payments by immediately spending them in a tx with no outputs (ie, gifting them to the miner who gets the block).

One property of the Bitcoin system (and so far, of all altcoins) is that there is a public record of all transactions, including the amount and derivation of all "coins" ie, unspent txouts. 

In the presence of datamining, this effectively de-anonymizes vast parts of the entire system.  And that's a problem. 

It would be good if we could verify the transactions conformance to protocol rules with respect to amounts (ie, verify that the outputs are equal to or less than the inputs) without revealing the amounts themselves.  Zerocoin was one solution to this, but I would rather attack it at the level of individual transactions.

Proof of "less than" is very hard, probabilistic, and would add huge bulk to the blockchain.  But proof of "equal" is possible and compact, and requires only one adjustment to protocol rules: We must explicitly represent the coin intended as the transaction fee, so that proof of equality is applicable to all transactions.

In the Benaloh homomorphic cryptosystem,  the public key is a modulus M and a base B.  For a plaintext P, a blocksize L, and some shared number N greater than 0 and less than M, the encryption of P is:

(B raised to the Pth power, multiplied by N raised to the L power) modulo M. 

This is interesting because for any two integers X and Y whose sum is less than B, the product of Encrypt(X) and Encrypt(Y) equals Encrypt( (X + Y) mod B).  And because addition and multiplication are both associative, this is true of any set of more than two integers as well. 

That is to say, for any given set of plaintext numbers, the product of the encrypted numbers equals the encryption of the sum of the numbers.   Since we want to test that the inputs and outputs add to the same sum, we can do so by testing that the encrypted inputs and the encrypted outputs have the same modular product, even when we don't know what the numbers are. 

Key management is a somewhat complex problem; to verify that the output coins add up to the same amount as the input coins, you need all the coins to be encoded using the same Benaloh key.  Therefore having the Benaloh key used for any output coin of a transaction enables you to learn the amounts for all input coins and output coins of that transaction.   That means that all the participants know what's going on in the transaction, which is, IMO, as it should be. 

But I need to figure out a good way for blockchain checkers to verify that the presented input coins shown in the current transaction  encrypted with the common key of the current transaction, are in fact the same amounts as the identified output coins of their previous transactions, which of course show in the blockchain encrypted using the keys of previous transactions.

I have solutions for limited cases where coins are not subdivided or combined.  (ie, input coins can change ownership in a transaction becoming output coins, in a way that's verifiable, without having their value revealed).   But when these coins are eventually subdivided or combined, their value is revealed as soon as one of the resulting coins is spent.  If at least one of the participants in a transaction does not value (or negatively values) privacy, this can happen as soon as that participant comes into possession of a coin.

Does anybody have a better solution for the last part of this problem?

A. Not hard at all.  Search "foocoin and barcoin" if you want to get started.

B. In most cases, people make forgettable cryptocurrencies where there are hardly any significant changes other than number of coins produced, timing of production over the long term, and block times which control coin production over the short term and confirmation times (and also bandwidth requirements).  These coins with rare exceptions are ignored.

C.  It's very common for people to make currencies with a "premine", emphasis on the "mine."  That is, they award themselves some number of coins before even starting the process, on the presumption that if their coin goes up in value they will be rich.   This is often presented as "development fund" or "foundation" or "charitable contribution" but the effect is the same.  If a new coin has more than a couple of testing blocks mined, it's generally considered a scam (read: even worse than being mostly ignored).

D.  One actual good idea that's been developed in altcoins is to base mining on "proof-of-stake" rather than "proof-of-work", or to try to make the "proof-of-work" ASIC-resistant (memory-bound, for example, rather than hash-speed bound)   This is basically an attempt to prevent mining from being dominated by people who've invested in specialized equipment, as has become more-or-less the case with Bitcoin, and to prevent a long-term risk of a 51% attack.

E.  One aspect that hasn't received enough attention is long-term bandwidth requirements.  Bitcoin has developed a database of over 10 Gigabytes that needs downloading before you can run a full node, and it's growing fast; this is a barrier to entry that limits the number of people running full nodes.  Also, Bitcoin's protocol requires bandwidth and compute power that scales with the product of the number of full nodes and the number of transactions.  In the long run this will constrain full nodes to large servers, further concentrating power and further making an attack on Bitcoin by subverting full nodes feasible.  A new cryptocurrency with some kind of built-in plan that limited the necessary bandwidth while preserving reliability and the possibility of high-volume use, would be a good thing.  

F.  Another idea for a cryptocurrency would be a built-in decentralized market in digital goods.  The "good version" is frequently considered as a "decentralized stock market" or similar.  It could be easily extended to just about anything that exists as information, but that kind of extension is a bit of a touchy subject, because you know, right, what would get traded.  You'd basically have millions of minor crimes of copyright infringement, and the commercial exchange of evidence of _major_ crimes such as sexual abuse of children.  If you generalize a cryptocurrency to a general digital market, and maintain no way to prevent it from being used almost exclusively for criminal purposes, there will be extraordinarily intense efforts by international law enforcement agencies to take it down -- possibly in a way that results in banning cryptocurrencies in general.

Well.... yeah, it really is that bad. 

Maybe we should ask sourceforge/github/ any others we can influence, never to serve executable (or, really, even source) using http rather than https? 

https isn't all that secure, for that matter, but it is better than nothing.

Anybody got a better idea?

This is weird.  A lot of the inputs to those big transactions into that account are "dust" that cost more to transfer than they actually contain.

Everybody realizes we're not even one twentieth of one percent of the way to 21 million, right?

Rather than having low-difficulty blocks, it might suit security purposes to reward users for near-miss hashes.

That means that in the coinbase transaction, the person who actually hit the difficulty target gets (say) 9 coins instead of 25, and the protocol also awards everybody who misses the target by less than 4 bits (there will be approximately 16 such hashes per block) with one coin. 

Alternatively, you could have special transactions allowing users to join (or leave) groups that split all block awards according to the number of acknowledged near-miss hashes turned in for that block.  With group membership encoded in the blockchain, the protocol could award shares of earnings to all members in the coinbase protocol.  So, it would marginally bloat the blockchain with group membership info and "near miss" tallies for members, but avoid additional transactions in which mining pools distribute block awards to miners.  So that would implement pooling for profit without pooling for consensus. 

But at this point we're seriously getting into AltCoin territory.  This would be fundamental rearchitecture in Bitcoin and I'd anticipate the devs flatly refusing to attempt anything like it unless an AltCoin had done it first and found it a good thing. 

I consider pooled mining to be a serious risk to Bitcoin's protocol.

Right now if the three biggest pool operators were to collude, it would be easy for them to simply agree never to mine on chains whose most recent block was not from one of them.  They'd immediately (roughly) double their profits by cutting out all other miners.  (AKA, a 51% attack).

But Bitcoin's design encourages this.  There is only one block reward every ten minutes, and the odds of a user getting one in his lifetime are rapidly approaching nil.  The only way to see a reasonably steady trickle of income is to join a mining pool.  So people do.  So we are all at risk on the decisions made by approximately any four out of six, or any three of the four biggest. 

And it gets worse when bitcoin's block reward  decreases.  At that point you see major hashing power simply turning off and waiting for the next time the difficulty comes down far enough to make mining into a profitable use of electricity again, then jumping back in again.  With mining pools, that can happen in huge chunks, making a 51% attack even more likely.

It's a design flaw that needs to be addressed at some point.  I don't know how, but we should definitely try to make it better to mine individually than in a pool. Or at least, as good in the long run.

Cryddit

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 

Keeping unencrypted wallets on Windows machines with Internet connections.

This is, of course, a self-correcting problem.

It's reasonable to want regulations -- and someone who can enforce them. 

What they're looking for is protection from malefactors.  If somebody breaks into your home and steals your television set, regulations about theft say that you can prosecute him, and the police will make a good faith effort to find him and get it back, and courts will try him, and there are known penalties with lots of precedent for their normalcy, and no, he does not get to keep your TV. 

They want there to be somebody who can take the role of police and courts and so on if somebody roots their computer and steals the bitcoins.   

If somebody scams a thousand investors for a million dollars each, the SEC will field the complaints, and investigate the business, and bring charges, and prosecute, and make a good faith effort to get as much of that money back as possible, and the courts will hear the arguments, and there is jail time waiting for the scammer. 

They want there to be somebody who can take the role of the SEC and so on if somebody scams them in a market denominated in BitCoin. 

If bitcoin is not subject to these things, or does not participate in them, then it will never be more than a dangerous and risky potential investment, and given the risks, it will never be worth developing into serious infrastructure.

It is not so much a "back door" in Tor, as an "attack on" users of Tor. 

Bruce Schneier, who has been going through the Snowden Files, explains.

https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html

Short version: If you're a Tor user, you probably have an NSA rootkit on your computer.  Not because Tor put it there or because Tor is flawed, but because Tor is typically used with a browser, and browsers have insecure implementations.  Tor traffic is used to identify targets for rootkit attacks via exploits in their browsers.  These rootkit attacks are carried out via MITM systems in place on the Internet backbone where they can intercept most traffic.