Propogation is very fast.  It is highly likely one tx or the other will rapidly out pace the other one and as it does it "cuts off" more and more of the network from the other tx.   If the merchants tx out paces the "bad tx" it will end up at a super majority of the network nodes and "isolate" the bad tx and the reverse is also true.    It is simplistic to assume that sending tx a to half your peers and tx b to the other half will ensure each one gets to 50% of miners.  It is far more likely one tx ends up in the memory pool at ~100% of miners.  Also propogation beyond the first peer is chaotic.  Some nodes as slow, some are fast, some may have few unique peers some may have hundreds or thousands.  Many of your peers have the same peers so the two tx are going to race almost instantly.

I am not saying it is impossible to pull of a (non hashpower related) double spend but it isn't as easy as 1, 2, 3, click and win.

Merchants looking to accept 0-confirms shouldn't do it casually but there are methods they can take to improve double spend detection and prevention.  The merchant should maintain multiple geo diverse listening nodes which have a high number of inbound connections.  These "listening nodes" can communicate out of band with the merchants main "processing node" and look for double spends.  While a single node has a limited view of the global network multiple nodes sharing information have a much better view.  If one of the listening nodes detects a double spend they can alert the merchant and halt the transaction.  The merchant can automatically institute a small delay between notification of payment and release of goods.  This makes if very unlikely that an attacker can both propagate the network to miner and not be seen by any of the merchants listening nodes (which are unknown to the attacker).  Imagine a merchant with 5 listening nodes and an average of 1,000 inbound connections.   There probably is some overlap but lets say the merchant sees 3,000 unique peers and lets assume the network consists of 10,000 nodes.  The "bad" tx would need to make it to miners without it being relayed to any of the 3,000 nodes the merchant is connected to, otherwise they will relay it to one of the merchants listening nodes which will detect the attack.   Pulling that off in a chaotic network would be a challenge.

The larger risk in 0-confirm txs is the attacker exploits a flaw in tx relaying by nodes, the attacker performs a Finney attack, or the attacker is assisted by "dishonest" miners who are willing to do an in memory pool replacement for a bribe.  These types of scenarios are hard to defend against so a merchant should be very aware of the risks of 0-confirm before considering accepting them.  

Nothing in this post should be taken as "0-confirm" is safe.  Most merchants should likely NOT accept 0-confirm transactions, however not all transactions are have the same risk profile. A site selling $5 css website templates is a different story than an exchange accepting $5,000 deposits.  Someone looking to steal website templates will most likely just pirate them rather than try to pull off a double spend.    For high margin, low value, low risk items the benefit of strong double spend detection may warrant the risk.  Remember the fraud rate of credit cards is not zero either, and online merchants are able to turn a profit.

Do you generally expect assets to continually double in shorter and shorter timeframes?  The chart is starting to look rather parabolic.  Not saying it is going to crash here but if i continues to grow the daily growth it is the likelihood of a crash increases.  

One can simultaneously believe in the long term possibility of Bitcoin and also believe the exchange rate has come too far too fast and look for a correction.  Ironically enough people being cautious about the possibility of a correction can slow the bubble and makes a correction less likely. 

ECDSA 256 bit key only has 128 bits of security.  Public key systems generally need larger keys to deliver the same key strength as symmetric encryption.  

The same thing applies to hashing algorithms.  For collisions and second pre-image resistance the bit strength of a hashing algorithm is half that of the digest length for 128 bits for SHA-256 and 80 bits for RIPEMD-160.

So there is no reduction in bits strength.  Even if there was (assume Bitcoin used 512 bit ECDSA keys), 128 bit simply can't be brute forced, not at any cost, and not in any useful timeframe so any reduction would be academic at best.  

Public key systems are more likely to be degraded in the future (due to mathematical relationship between the public and private key) and thus they are "hedged" by using larger key stengths to provide a "cushion" against improved cryptoanalysis.

WTF?

Still doesn't mean it can't grow too quickly and correct.   If it was certain that Bitcoin is going to $10,000 with no drops on the way and then forever remain above $10,000 .... well it would ALREADY be $10,000.

Just because Bitcoin ends up much larger in the future doesn't mean there can't be crashes along the way.   Hell you should almost COUNT on there being multiple more crashes on the way.

It is not quite that easy to pull off a double spend.  Most (virtually all) nodes will reject and refuse to relay or include in a block the second transaction they see.

So you broadcast a tx paying for a product then any node which sees that tx will reject the double spend back to yourself.
If you send the "double spend" (the tx back to yourself first) then there is a good chance the merchant will not see the "good spend" as all the merchants peers will drop it before it gets to the merchant.
0-confirm should be considered untrusted but it isn't as trivial as pay someone, pay yourself w/ fee and win but yes that is the general concept.

The 2TH/s model for Feb is cheaper than the 1 TH/s model at launch.
As the price per GH/s continues to fall the economics don't really makes sense on the smaller unit.
KNC dropped the mercurcy, CT drops the 1 TH/s unit.  In time I would expect HF drops the single module Baby Jet and focuses on just the 3 module Sierra.
Anyone think if/when BFL gets the Monarch out in volume they will still be selling 25 GH/s rigs?  When prices are down to $1 per GH/s?

What Bitcoins? I lost my wallet.dat, it got corrupted years ago.
Bitcoin is the first wealth that is portable and reputable.

Kinda hard to say you don't have a physical asset (say gold) when they open the safe and it is there.  Kinda hard to move $1M in gold bullion out of the country (damn TSA metal detectors).

Probably easier to simply tightly control the echanges and put monetary controls there just like they do fiat exchanges.  So hopefully the operator of BTC China sees that one coming because even if China remains neutral on Bitcoin they likely are going to want control/insight into currency flows into Bitcoin.

Not sure why people are saying "monthly volume" you guys do know the charts all share the same url right?  Click on price & volume and daily and you can see daily volume across all exchanges.

KNC ships the next batch (probably >2 PH/s conservatively and maybe closer to 2.5 PH/s realistically) in 6 days so calling it a plateau is a little premature.
Then HF batch one is mid Dec a little smaller maybe 0.5 PH/s.
The HF batch two is unknown since the first batch got pushed back (will it be a month late? will it ship right after batch 1?) but it looks to be larger maybe 2 PH/s max.

The rest should be the usually slow BFL dribble and small blocks by the other three (ASICMiner, Avalon, Bitfury) but my guess is they are not going to be significant compared to the existing hashrate and the three events above.

Cointerra is saying "on track for late Dec" but given holidays (vacation time) and the late tapeout, my guess is "late Dec" is code word for "oops at the last minute we just missed it and we are looking at mid January". Regardless of it being late Dec or early January we aren't going to be sitting @ 4 (or even 5) PH/s for that long.

unknown.

You have to remember there is no "bitcoin network" as if it is the single syncronized unified system.  There is tens of thousands of independent Bitcoin nodes each following their own rules/logic.

So when you create a tx it goes gets relayed your node to your peers who relay it to their peers and it eventually ends up at one or more miners who will eventually include it in a block (and with no fee there is no reason for them to include it before any paying tx).  When you create a double spend any node which knows about the first tx will drop/erase the second tx.  Thus it is very possible that no miners is even aware of the second tx exists because every node you sent it to dropped it as a fraudulent duplication of the first tx.  On the other hand if not every node learned of the first tx (maybe they were offline at the time) they now will relay the second tx and if they are relayed the first will consider that the double spend and drop/erase it.

To make it even more unknown when nodes run out of space in the memory pool (list of unconfirmed txs) they delete the oldest ones.  Of course if your client comes online it will rebroadcast it and in this case "it" is the second (not first which you already deleted) tx.

So all of the above are possible
a) the first tx eventually confirms (eventually could be 1 to an insanely large number of hours)
b) the second tx eventually confirms (eventually could be 1 to an insanely large number of hours)
c) you delete the second tx from your client and eventually all nodes forget about both tx and you can start again.

As for the client not "asking" for fees.  Fees are only required if the tx is low priority, that is the only time the client will make you include a fee.  However fees are OPTIONAL on all txs.  If you include no fee and there are thousands of tx waiting which have a fee obviously a miner will pick those paying txs first.  If more and more paying tx come in while you wait you can fall further and further down the list.

Given the min fee is so low I recommend setting your client to pay a fee on all tx even those that don't require it.  You don't have to but it avoids messes like this.

Just a lull, the waves are building out in the oceans they just haven't haven't reached the shore but they will in time.

KNC starts shipping Nov batch on or around 11/15.  The prior batch was >2 PH/s so no reason to think this one will be smaller.  I would say probably 2.5 PH/s.
KNC hasn't opened a Dec/Jan batch yet but I have no doubt they probably will.  I wouldn't expect anything less than 2 PH/s.  If units don't sell they can cut prices a lot to make sure they do.
HashFast is delayed but indicating they will ship Batch 1 on or around 12/15.  That will be ~0.5 PH/s (including IceDrill project).
HashFast batch 2 and upgrade timeline is unknown, but say worst case scenario it goes a month after the first batch, that will be another ~2 PH/s.
HashFast MPP window (which is likely to be max) closes end of Jan.  So expect another ~1 PH/s in Feb for that and probably another 1 PH/s (or more) in regular sales.
Cointerra is sticking with "end of Dec" but given they taped out a month late I think it is going to be more like Jan.  Still Dec or Jan it is another ~2 PH/s.

BFL ?  Well no friggin idea I doubt Monarch will be on time but it will happen eventually but probably too far out (late Feb?, early Aug?) to start considering.

Bitfury, ASICMiner, Avalon have been real quiet so it is hard to know what to expect but I am sure it isn't zero.

So I think we will have one maybe two quiet difficulty adjustments and then expect a solid climb with multiple waves shipping one after another.  
The only "good" news is that at one time a Petahash meant the difficulty would increase 100% now it means 25% and in the future it will mean less.  The % will have to eventually decline simply because doubling every month will start requiring an increasingly insane number of new units.

So Cointerra gave a vague delivery date and you know they chose a conservative timeline with lots of room for slack and errors.
Other companies gave a vague delivery date and they chose an aggressive timeline with no room for slack and errors.

Cointerra is different why?  You want them to be?

Cointerra has announced they paid a premium for a rocket run or this is an assumption?
Usually the pricing and timeline of fabrication is subject to NDA so I would be surprised if they announced that.

I hope to change that.  It probably will be impractical for "the what is a Bitcoin, I just want to buy something, push a button, and get lots of coinz" miner but for the hobbyist I think it is possible (not certain but possible) for immersion cooling to be used.  There is an added bonus for home use of immersion cooling and that is using the waste heat.  A moderate sized rig has sufficient thermal output to provide a home with "free" (or at least 0 energy cost) hot water and/or whole house heating.

As for AM immersion cooling operation.  People shouldn't assume it is a slam dunk super duper money maker.  The economics are challenging however there are two potential bright spots:

1) Immersion cooling at its simplest form is a tank with fluid, a condenser and some mechanism to remove heat from the condenser (i.e. chilled water supply, freon, warm water) .  As hardware evolves old hardware can be replaced with new hardware.  Hardware from one vendor can be replaced with hardware from another vendor.  If it can fit in the tank it can be cooled with immersion cooling.  Compare this to heatsinks, heatpipe coolers, and waterblocks.  They are generally work on a specific system and must be scrapped when the board is obsolete.  Try mounting a Avalon heatsink on a Hasfast mining board.  The capital costs of immersion cooling are higher but they have a long lifespan long enough to support multiple generations of ASIC hardware.  The tank itself has no moving parts and the mechanism for cooling the condenser can be adapted to the location.

2) SHA-2 ASICS are extremely energy dense and the the density has been rising.  One reason that immersion cooling has never caught on in the server world is that while a server may use a lot of power (say 1200W for high end quad core, high memory server) it occupies a relatively large volume.  This mean a large amount of (very expensive) working fluid is needed.  Now one "could" redesign a server to be more compact but then you trade reduced fluid cost for higher custom fabrication costs.  It is a lose-lose without massive (i.e. millions of servers) economies of scale.   Bitcoin ASICs are very energy dense and getting more energy dense.  Take a look at HashFast or Cointerra.  300W+ in a board that is 100mm by 300mm.  This brings its own complications.  We have gone from low capacity heatsinks and fans (ASICMiner/Avalon) to Copper Heat Pipe CPU Coolers (KNC) to Waterblocks (HF & Cointerra). 

Probably not.  Most trojans are designed to operate in near realtime.  At best this results in a race condition, you and trojan transmit a tx for the same "coins", a double spend and it becomes a race to see which ones ends up in the block (the other one ends up invalid).  I don't know for sure but to avoid a race condition it would be pretty trivial for a trojan to disable/block your outbound transaction to ensure it always wins so you might be looking at a guaranteed loss.

If you suspect your computer is infected, then don't use it.  Open the wallet.dat on a different computer.
If you suspect the password for your wallet has been compromised.  Create a new wallet on a secure computer with a new unique strong password (or temporarily an offline/paper wallet) and transfer the full balance of your old wallet to the new wallet.

It would have to be that complicated.  A large reason why the IO on a pool server is so high is that miners want low variance and and real time stats (i.e. thousand if not millions of low difficulty shares).  In a setup like this the node isn't really a "money maker" and the work load can be much lower.  With ntime rolling it is very possible that the pool server would only need to provide a single work unit per router per block.  Likewise for the "lottery" you don't need routers to return a lot of shares.  The share difficulty can be set relatively high such that a router may only return 1 share a week.  The pool would convert 1 share (and only 1 any excess shares rollover to cover variance in future weeks) per week per router into a ticket and lottery off the week's proceeds.  The router would advise the user if they won (maybe even a blinking Bitcoin LED).

The load on the pool server can be reduced to a negligible amount.  Per router it would be roughly 1 WU issued per block, and 1 high difficulty share to verify per router per week (or maybe day for lower variance).  If the pool could maintain 0.1% of the network hashrate it would on average solve one block per week.

Still I think this type of setup makes more sense in a donation/charity model.  Buy a cobranded router from your favorite non-profit, plug it in and collectively help the non-profit raise revenue.

An alternate version of this would be quite the scandal.

Some OEM puts a low powered low output (say 28nm die shrink of bitfury) chip on say a HDTV, or Bluray player, or set top box.  These devices more and more are designed for internet connectivity.  Covertly the device mines using the customers electricity.  Now 1 28nm Bitfury (guestimate 8 GH/s) might not be much but imagine it in say 30 million HDTVs (or game consoles, or STBs).


Still I think a router w/ miner is an interesting idea.  The reality is that a single one would generate negligible revenue but it could be used in a charity/donation type setup.  Imagine the EFF (or some other non profit but EFF given their focus would be a good fit) had a EFF co-branded router (obviously made by some Chinese OEM like any other router) with a low powered mining ASIC.  The router was designed to direct all revenue to EFF "donation pool".  The router could show how much this individual router and all routers combine help the EFF and how much they decentralize the network.

No it would not.

Address =/= Wallet.

A wallet consists of one or more addresses.   My wallet has >3,700 addresses used.   Please look through the blockchain and find all 3,700 addresses.

You could make a distribution of addresses but since an individual can have any number of addresses it would be next to useless.

A distribution of wallet balances is impossible.

That made me smile.  Buckle up because it will be the mother of all rockets.