9

I think I understand the basic operation of the Bitcoin protocol.

Blocks are the "long-term memory" of the network used to prevent double spending (and the way the network agrees in first place). Proof of work is sort of brute-forcing the nonce so that the hash has at least the desired number of zeros. When a dishonest node generates a new block other nodes will refuse it should it contain transactions that were not seen by them, so the network will "converge".

I guess the transactions need to be included in that PoW (or else it would be simple to alter them afterwards). So every time a new transaction is seen it will require the miner to start brute-forcing "from scratch"? I read some sort of tree is formed, so it actually doesn't mean the input to the hash function gets longer, but still every transaction will change the "root value", won't it?

Why would a miner even bother to include all transactions that occurred on the network (given that transaction fees are minimal)? There is no lower limit on the tx number per block (perhaps in that time there were really no transactions). It would be simpler for them to just include perhaps one and then use their (CPU) time to solve the puzzle and earn the reward.

There must be some sort of thing in the Bitcoin design which I don't get yet...

  • 2
    I've probably fallen for the "gambler's fallacy". The probability that the next calculation will win is the same no matter whether I change just the nonce or something else changes in the block. On average is takes that many tries to get a correct solution. – fiction Jun 10 '13 at 7:47
  • I agree with your first question, and don't think the gambler falacie applies here: the nonce has 4bytes so if I already checked 2^16 numbers without success accepting a new tx will make me start from zero again and have 1^32 tries, while not accepting a new tx will double my chances of finding it first. @david: still will be better for a miner not to accept the tx to be the faster minerr in the network. So.... I think the question is still open, at least I can't fund an answer. Anyone knows the answer? – user6045 Jul 22 '13 at 6:19
  • 4
    Your answer is based on many misconceptions. For one thing, 2^31 is half of 2^32, not 2^16. For another thing, a typical miner will try all 2^32 possible nonces in a second or so. Lastly, your chances of finding a working nonce are completely independent of how many prior successes or failures you've had. It may be that no nonce in the 2^32 possible nonces work. It may be that ten of them work. Each nonce is an independent trial. Typical miners won't interrupt a set of 2^32 nonces just because of a new transaction, but a few seconds later, their next run will use the new transaction. – David Schwartz Jul 22 '13 at 7:11
10

Miners have a long-term investment in the health of the Bitcoin network. If Bitcoin collapses, then their expensive ASICs are worthless. Miners particularly need Bitcoins to remain valuable over the long term because their hardware produces Bitcoins over time.

If nobody includes transactions in blocks, then Bitcoins would be useless and therefore worthless. That would hurt the miners' long-term investment.

If this ever became a problem, transactions would just wind up with higher fees to encourage miners to include them. Right now, enough miners will include a transaction with a miniscule fee that there's no point in paying more.

  • I see. So the few additional hash computations for the Merkle tree update are probably for the "greater good" (but might get rewarded by tx fees). However mining is still exactly at same speed as without including transactions (because there is no "from scratch") - I did not realize that yesterday. Well ASICs probably would be worthless but a general purpose CPU won't. We are probably off-topic but I guess that's the motivation behind Proof of Stake (more BTC, more to lose if the network collapses). – fiction Jun 10 '13 at 7:59
  • "However mining is still exactly at same speed as without including transactions (because there is no "from scratch")" - there is a from scratch every time a transaction is added (due to a new merkle root), but because 2^32 nonces can be hashed on the header so fast, adding another transaction(s) to attempt the next round of hashes with all nonces isn't a big deal. Additionally, the timestamp in the header adds variation enough for a new group of hashing with the 2^32 nonces. Can someone confirm if this is correct. Whatever the case I've voted up the question & accepted answer, thanks! – alexkb Jan 21 '15 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.