Simple, it doesn't.  It simply is "marketing".  The blockchain DOES prevent double spends (once sufficiently confirmed) unless the attacker has enough hash power to rewrite the chain.  Then again all blockchains do, that is the purpose of them.

Then again a 20 sec block time that should be the first clue as to the knowledge of the developer(s).

Where do you get this idea from.  Nodes rapidly share tx even before they are confirmed (included in a block).  If the server has a properly running bitcoind they should "see" the transaction (as unconfirmed) within seconds at most.  The site can then report to the user, "tx received (unconfirmed)" and update the status once included in a block "tx received (1 confirmation)" and update the confirmation count as the blockchain is extended.

On edit: For security reasons the user needs to sign but not broadcast tx1 until it receives and verifies the half signed tx2.

Key word ... most.

Exactly.  If you put your name on it, you are vouching for it.  They did and the story was bogus.

Yes.


No.  While this would make a CPU "more" efficient, it wouldn't make it efficient enough.  Say your CPU was 3x (and it likely wouldn't be that much of a speed up) as fast and used the same power.  Would it really matter?

That is not how QC works, although I don't blame you because general media/new treats QC as some kind of computing magic.  A sufficiently large (we are talking tens of thousands of qubits) general purpose QC could use Shor's algorithm to vastly reduce the complexity of breaking public key encryption. However DWave system is not a general purpose QC and is incapable of implementing Shor's algorithm against keys of any size.  QC are a theoretical future risk to many forms of public key cryptogrpahy (such as ECDSA used to sign transaction in Bitcoin).  When QC can break 32 bit keys let me know.

Still none of that applies to SHA-2 (or any hashing algorithm).  Quantum Computers generally speaking are ineffective against Hashing algorithms and symmetric encryption as Shor's algorithm can't be used.  Grover's algorithm can be used but the speed improvement is not as interesting/useful.    With grover's algorithm a preimage can be found in 2^(n/2) operations where n is hash size.  So rather than 2^256 operations SHA-2 "only" requires 2^128 operations.  Even if such a QC existed today 2^128 is a completely infeasible amount of time/power to break a single PubKeyHash.  

Against mining it is beyond useless because miners aren't looking for a single hash they are looking for any one of quadrillions which meet the target requirements.  Even with QC it is many magnitudes more difficult to break a single hash then it is to search by brute force (mining) for "any" hash which is below the the target required by difficulty.

I will be going, you can save $100 by using code "BITCOIN". 
Now only if they accepted Bitcoins.  Maybe the 2014 conference.

Well someone investing $200M into an industry which at most has $130M in global revenue is equally unbelievable.  Remember the $130M doesn't mean the market supports $130M in mining hardware profit or even $130M in mining hardware that is just the GROSS revenue for all miners globally.  Miners themselves expect to make a profit and they have to electricity as a cost, and mining equipment is a capital good it doesn't get "used up".

Which has ABSOLUTELY NOTHING TO DO WITH MINING. You could make Bitcoin illegal (in one county) with 0.0 khps and can't make it iillegal with 3490278429178412940274219847 PH/s.  So the idea that one would need to invest $200M in mining  to fork Bitcoin and make the original illegal is just stupid as was your original claim.  Of course Bitcoin being illegal in one country doesn't make Bitcoin illegal in the other 239ish countries. 

Once again... LEARN HOW BITCOIN WORKS.

The only thing miners "vote" on is which tx is valid in a conflict and which txs are included in the next block.  That is it.  If a group of miners change the protocol it is a fork and existing users and continue to use the existing (original) Bitcoin.

Then underprice those sellers and still make a decent profit margin.  Problem solved.

Why would one do that?

Block hashes are random.  So the only way a miner could guarantee the next block will be a superblock would be to throw away VALID blocks which result in the next block being normal.

Every block thrown away simply means less revenue for the miner.  While they would publish more superblocks, it isn't because they found them faster, it was merely because they threw away valid blocks which don't lead to a superblock.

BTW:  superblocks are generally speaking pointless but I don't see there is no mechanism to profit from this.  At best an attacker could use it to drive down the value of the coin.

You guys are idiots.  Since when is SHA-256 an encryption algorithm?

It will never "catch up" and that is fine.


Gross World Product*: $71 trillion
Global Annual Forex Volume: $1,423 trillion
Ratio of currency speculation to actual goods/services: ~20:1

Non-speculators trade because they HAVE to. As an example, a compnay receives 100 BTC and needs USD to pay for materials, they aren't trading to make an exchange rate profit, they are trading because they need to.  Likewise someone buying an Avalon (is/was? only sold for BTC) who only has USD is trading because they need BTC.   If there are no speculators (or low speculative volume) the market is going to have huge spreads and low liquidity.  In order for non-speculators to have deep liquid markets generally requires a multiple of speculative volume.  This applies to currencies and commodities, Bitcoin will be no different. 

In summary, all markets need speculators in order to be efficient and speculation will ALWAYS be a magnitude higher than "real economy".


* GWP is the the sum of all the gross national product for all nations.  Gross national product excludes imports and exports, since all imports are another countries exports they aren't useful in looking at global production.

Still having a hard time with this concept of open source.  The actions or inactions of the founder are utterly irrelevent.  

However SOMEONE will need to add merge mining code to the child-coin.  The parent coin (i.e. Bitcoin) doesn't need any modification.  It is utterly unaware its hashes are being used to secure other chains.

Adding merge mining support will be a hard fork event.  Nodes which don't upgrade to the the version which supports merged mining will see the merged mined blocks as invalid.


There is no limit to the number of child chains.  No ASIC miner is Bitcoin specific.  They perform a proof of work involving hashing a blob of binary data plus an incrementing nonce two times using the SHA-256 algorithm.  Any application which uses that will work fine.  Even without merge mining one could use an SHA-256 ASIC to mine IXCoin or Devcoin.

Don't assume all scammers are good at scamming.

The main problem with botnets is that the zombie owners don't pay any real cost for their infected nodes.  This is why they are so hard to fight.  The targets of botnets pay all the cost of fighting them, the botnets fight with "free" hardware and the cost to each zombie owner is relatively small often it goes unoticed.

Ironically the block eruptor would act like a canary in a coal mine.  Seeing the shares/revenue go to zero would alert the owner that their system is compromised.  If the owner can't get their computer fixed then there would be no reason to leave the eruptor plugged in and running.  They would either unplug it an put it in a drawer or maybe sell it on ebay for $5.  Either way it would be very hard for a botnet operator to contiunally steal a resource the zombie victim is likely to notice.

You are half right and my statement was incomplete.  A compromise of SHA-256 alone would not be sufficient.  You would need to break BOTH SHA-256 and RIPEMD-160 but not necessarily ECDSA to steal bitcoins because there are two potential attack vectors.  You can (in theory) steal coins by finding a preimage of the public key that produces the same hash or by finding the correct private key to sign the transaction.

Thus to steal coins you would "only" need to break EITHER both hashing function or ECDSA.

Theft by preimage.
Bitcoin validates transactions by ensuring the public key of the signature corresponds to the pubkeyhash defined in the output being spent.  Thus if the attacker can find a pubkey which hashes to the correct pubkeyhash then he can spend the victims coins without breaking ECDSA.

pubkeyhash = RIPEMD-160(SHA-256(SHA-256(pubkey))

So if there is an unspent output sent to pubkeyhash P one "only" needs to perform a preimage attack to find a different pubkey p that produces the same pubkeyhash P.  There are potentially trillions of pubkeys which produce the same pubkeyhash.  However the triple hashing using two different algorithms designed by different entities and using different internal structures makes the odds that they would simultaneously be both compromised significantly enough to make such an attack feasible very low.  Still just for academic correctness you would NOT need to compromise ECDSA in order to perform this attack.


Theft by breaking ECDA
This IMHO is the more "likely"* attack scenario and it requires the pubkey to be know (funds have been spent from this address thus the pubkey is recorded in the signature of the tx input).  Given the pubkey the attacker either through a classical attack due to a cryptographic flaw in ECDSA or through some future advancement in QC and Shor's algorithm uses the pubkey to find the privkey.  Not reusing addresses greatly complicates this attack vector as the pubkey remains an unknown to the attacker. 

* By more likely I mean you are more likely to die by a shark then by meteor strike, both are rare.

The entire blockheader (which includes the nonce) not just the nonce is hashed using the SHA-256 algorithm.  Now the blockheader is actually hashed twice to produce the block hash.  Block Hash = SHA-256(SHA-256(blockheader)).

For more info on what is in the blockheader (Looks like the wiki is down so here is a google cache).
http://webcache.googleusercontent.com/search?q=cache:FZ9pUxR3ldEJ:https://en.bitcoin.it/wiki/Block_hashing_algorithm+&cd=1&hl=en&ct=clnk&gl=us




Of course it is trivially easy to hash a block header.  The average GPU can do this almost a billion times a second.  So not all blockhashes are solutions.  There is a target based on the current difficulty.  The blockhash has to be smaller than the target to "solve" the block.  So a miner will take a blockheader starting with a nonce of zero, double hash it check against the target.  If it is too large, it will increment the nonce by one, and do it again.  Eventually all ~4 billion nonces will be tried, so the miner will make some other change to the blockheader and start over again at zero.  The miner does this until someone publishes a new block on the network. 

Currently difficulty is ~30 million which means the target is so small that it will take on average 128 quadrillion (2^32 * 30 million) hashing attempts before a block hash is found which is smaller than the target.  When a miner finds hash which is smaller than the target it produces a valid block (sometimes called a block solution or "solving a block").  The miner relays the new block to its peers, who relay it to their peers, who eventually relay it to every node on the network.  All miners then construct a new blockheader using the just found block as the prior block and start the process all over again which they have done 249,913 times.  It is written this will continue until Great Satoshi returns to judge the crypto and the fiat.

Imagine it like a dice game which requires you to keep rolling a bunch of dice (say twenty) until you get a certain number of "ones", the difficulty would determine how many ones are needed to "win" and how long on average it would take.  Difficulty =1 would be pretty easy, difficulty = 20 would be insanely hard.

I think this has a lot to do with it.  



Trying to keep the number of coins in circulation static would require confiscating "old" coins and that is a very hard sell.  Going for low continual inflation wouldn't be as bad as some make it out to be (the problem with banks isn't inflation it is unfair access to pre-inflated prices) but "stable low persistent inflation" is harder to sell in a 30 second sound bite then "there will never be more than 21M BTC".  A low rate of deflation doesn't have any meaningful effect on the economy and and is easier to "sell".  That is likely why Satoshi went that route, it was the easiest route and honestly if implemented BEFORE the genesis block there is little difference between low (<1% annually) monetary inflation, low monetary deflation, or a system (once all coins are mined) holds the supply nearly static.

IMHO though that ship has already sailed (except for maybe alt-coins).  Trying to change it AFTER THE FACT would kill Bitcoin.  Things like the rate of minting, irreversibility of txs (including old ones), and the maximum money supply are part of the social contract offered to all potential adoptees.  It is immoral to make ex post facto changes to the social contract.  People bought into Bitcoin because those were held out as the "rules of the game".  Changing one wouldn't destroy the economy from a technical standpoint but it would destroy the faith in the currency that the rules won't be gamed/changed for the benefit of some at the expense of others.  

If someone could change the fundamental nature of Bitcoin (even for the "better") what else could they change.  How long until the next change for the "better" and the next one and the next one. How long before that leads to an elite group of economist-miners .... we will call them "The Federal Pool" would analyze the Bitcoin economy and change the minting rate by fiat (decree) to align the rate of monetary inflation with the rate economic growth.  Of course they would do it for the "good" of everyone, there stated goal might be something like "ensure price stability, maximize economic efficiency, and seek maximum employment".