Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

That is incorrect. The validity of a transaction depends only on how it relates to the transactions that precede it. Mining simply keeps track of the "official" history of transactions, to guard against double-spend attacks.

Transactions are useless unless they're confirmed in the blockchain. That's the whole point of bitcoin. Mining and the blockchain is all there is to bitcoin.

And that's another problem: the energy used for mining depends on the hashrate, not transaction rate. It's true that increasing popularity of Bitcoin rises both, but trying to calculate "energy per transaction" on that basis is pretty much the same as trying to calculate "drowned people per litre of ice cream consumed" on the basis that warm weather increases both.

You might have noticed that my calculation started off with network hash rate because that's where the energy is being used. I don't really think it's that important a calculation anyway, but I did it to show the $35 per transaction of the OP was incorrect. Indeed, if the transaction rate goes up faster than the hash rate, then the transaction cost is even lower.

Instead of criticizing, maybe you can come up with a better cost per transaction for bitcoin (because there surely is one).

Pretty much all the power needed for a transaction is going to be the mining (a transaction isn't valid unless a miner has entered it into a block). So we can do a quick-and-dirty calculation; if we assume:

- 150000 Thash/s total network performance- power consumption of 1kW per Thash- power cost of 10 cents per kWh- 6 blocks per hour- 400 transactions per block

Symmetric (shared-key) algorithms do have vulnerabilities to quantum computing: Grover's algorithm allows a brute-force search to be performed in square-root time of the key size (i.e. 256-bits -> 128-bits, 128-bits -> 64-bits). This isn't a big problem as long as you're using at least 256-bits.