Hacker News Reader

Comment by jimmcslim | Hacker News Reader

A few thoughts:

1. I'm probably too lazy to look this up, but given mining Bitcoins essentially boils down to solving hard math problems and there is no centralisation, what prevents collisions from two miners mining the same bitcoin at the same time? Is there a GUID element involved? (if so, then perhaps collisions are possibly, just extremely unlikely as to be practically zero).

2. If the bitcoin mining difficulty increases on a known path, would it be possible to tie the current BTC price (probably would have to try estimate a forward price) vs the current cost of GPU processing on EC2 (ie. via Amazon's spot market mechanism). Has anyone done this?

View on HN

Regarding #1: it's not really coins that are mined, it's blocks (which happen to include a reward paid to the miner). Blocks are numbered and include a hash of their parent, so you can get a tree-like structure of blocks. But only the longest branch "counts", so miners have an incentive to spread information about the current highest block as quickly as possible.

In cases there two blocks happen to be mined simultaneously there's a brief period of uncertainty regarding which transactions were committed and who earned the mining reward. But as blocks are generated on both branches at random intervals, eventually one will become longer and snowball from there. The key is that the average time between blocks is about 10 minutes, muck longer than the communication delay between miners.

As to #2: first of all, the Bitcoin protocol knows nothing about exchange rates. And secondly, in a market-based exchange, you can't just "tie" a price to anything. You could set up a fixed-price exchange, but if the market price was different from the one you picked, either buyers or sellers would look elsewhere to get a better deal. (That is, unless you provided some additional benefit over the existing exchanges that was considered valuable enough to make up for the price difference.)

I didn't explain myself for #2 very well... I can imagine a setup where a bot is monitoring the exchanges for the current BTC price, and perhaps (if such data is exposed) the market depth at and near that price. Then, monitor the Amazon spot price for GPU instances (if Amazon makes GPU instances available at spot rates, otherwise use their fixed price). At some point, the cost of BTC in USD would be greater than the cost of EC2 compute hours in USD required to obtain coins, in which case ramp up EC2 instances and get to work!

I'm afraid the spot price of EC2 has never been even close. EC2 GPUs are nVidia anyway, which don't have the specific on die instruction that made ATI/AMD cards so good for mining back in 2010-2012. That's all been superseded by ASIC tech which is already in a race to smaller and smaller feature sizes.

The math can be most easily done at mining.thegenesisblock.com

> what prevents collisions from two miners mining the same bitcoin at the same time?

Absolutely nothing. There can, in fact, be two blocks at the same height. This is a temporary fork. What happens is that miners mine the next block on top of one or the other at random, and the chain which gets the next block "wins", and everyone then mines on top of that.

To make it clearer, at any time, the longest chain of blocks wins. There can be two chains of the same length at any point, but that doesn't last for long, as it's statistically incredibly unlikely that this will continue for more than a block or so.

There's a page full of times that it's happened, here: https://blockchain.info/orphaned-blocks

> mining Bitcoins essentially boils down to solving hard math problems

Nitpick: it boils down to solving the same ridiculously simple math problem billions of times with a different parameter until by pure blind chance you get the right result.

Reply on news.ycombinator.com