3

According to https://bitcointalk.org/index.php?topic=216938.0 one transaction can only be contained in one block. If I understand correctly, miners can freely decide what transaction they include in their block and what they don't.

Why is it that multiple miners concurrently deciding what block to build on, and what transactions to include, produce blocks without any duplicate transactions? Is there a reservation list of transactions to be confirmed and miners that will include them?

Improve this question
1

2 Answers 2

Reset to default
1

When a miner (call him Pete) learns that a new block (call it X) has been mined by someone else, he will normally update the header of the block he is trying to mine, so that it lists X as the previous block. (That way, Pete is now trying to build on top of X, rather than trying to replace it.) At the same time, Pete will note which transactions were included in block X, and remove them from his "memory pool" of unconfirmed transactions that he was planning to include in the block he was trying to mine. He will rebuild a Merkle tree with the remaining transactions he wishes to include, and update his block headers to match.

In this way, when Pete does succeed in mining a block, it won't contain any transactions that have been contained in previously mined blocks.

Improve this answer
5
  • Does this mean that mining pools work most of the time in vain - their work is lost because the lack of planning? I mean suppose there are 4 mining pools. All of them are working on different blocks but all of these blocks contain one same transaction (lets say A). When fastest pool publishes the newly mined block others has to change previous block reference and replace the transaction A. Because data of their blocks has changed they need to search the nonce space from the beginning. So all the work of remaining 3 pool done before block publishing by fastest pool is lost. Is that correct?
    – czerny
    Commented Jan 21, 2015 at 13:10
  • @czerny: That is a very common misconception about how mining works. Every nonce has an equal chance of success; a winning nonce could be anywhere. So there is really no progress to be lost. Whether you've already tried a trillion nonces for a particular block or are just starting, your chances of success on the next one are the same. It's like a fresh roll of the dice each time.
    – Nate Eldredge
    Commented Jan 21, 2015 at 15:11
  • 1
    @czerny, Just like Nate said, there's not really a progress bar when mining. It's sort of like flipping coins on video. If you get lucky enough, you can show your video to others, and they let you get to pick the next transaction set and get paid. Every other time, you throw out the old video, start filming and try flipping the coins again.
    – morsecoder
    Commented Jan 21, 2015 at 21:24
  • @StephenM347: That's a nice analogy, I've never heard that one before. I may have to start using it.
    – Nate Eldredge
    Commented Jan 21, 2015 at 21:31
  • Thanks for answers. I asked in separate question about the progress of mining and as far as I understand there is a progress of negligible size. So it is practically like coin flipping but strictly speaking each nonce has a (tiny) bit higher probability to be the proper one.
    – czerny
    Commented Jan 21, 2015 at 21:37
1

When a newly discovered block is announced to the network, every node must verify that all the data contained in it is valid. If such a block lists a transaction that was already listed in any ancestor block(*), the node must reject the new block entirely. The block will be ignored and the network waits until someone announces a block that is valid.

(*) Every block contains a reference to its parent block, ensuring that bitcoin's entire transaction history is verifiable by anyone; hence the term block chain.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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