2

Why are transactions grouped into blocks (PART 3)?

  1. Lets say we have just put a block on the blockchain. Now miners start forming new blocks and try to guess new hash values. The miners are putting transactions into their formed block (with a hash guess)? Which of the unconfirmed transactions do they put into the block (all unconfirmed or a subset)?

  2. Is putting a transaction into a block a way of stating that transaction has been validated? How does this guarantee the transaction, miner put in the block, is valid?

Improve this question

2 Answers 2

Reset to default
2
  1. Lets say we have just put a block on the blockchain and there are no blocks at the moment that miners mine. Now miners start forming new blocks and try to guess new hash values. The miners are putting transactions into their formed block (with a hash guess)? Which of the unconfirmed transactions do they put into the block (all unconfirmed or a subset)?

Miners will select transactions to include based upon transaction fees. In Bitcoin Core, this transaction selection is done as follows: Group up transactions into packages, a package consists of a transaction and its unconfirmed ancestors and descendants (some packages may just be 1 transaction, others more). Then calculate the total fee rate paid by a package and sort the packages by fee rate. Select transactions by going down the list of packages and choosing each package until the weight of all of the transactions (as defined by BIP 141) cannot allow any more transactions to be included (i.e. add packages until the weight exceeds the limit, then remove what was just added and add the next one, etc. until no transactions left to add).

There will often be more unconfirmed transactions than can fit in a block, so miners will only select a subset of unconfirmed transactions.

  1. Is putting a transaction into a block a way of stating that transaction has been validated? How does this guarantee the transaction miner put in the block is valid?

It is not. A block could contain invalid transactions and the block (and those invalid transactions) would be invalid. A full node must check that a block is valid. They do this by checking the block header is valid, the coinbase transaction is valid, and all transactions in the block are valid. Just because a transaction is found in a block does not mean that it is necessarily valid, and if it is not, the block is invalid and should be rejected.

Improve this answer
8
  • You can have the next few, I'm quitting for the day :-)
    – Nate Eldredge
    Oct 21, 2017 at 18:04
  • A lot of subquestions. Have to put some of them into separate questions. Damn doesnt let me post that often :D
    – croraf
    Oct 21, 2017 at 18:21
  • You say if a block with correct header is put at the end of the chain but with invalid transaction the block itself is invalid. Does this mean that then anyone can use the same block with correct transactions and throw it on the chain again?
    – croraf
    Oct 21, 2017 at 18:29
  • It would not be the same block because the invalid transaction would not be there and likely the nonces would be different because removing or replacing the invalid transaction (or changing it in any way) will change the block hash. But yes, there can be another block at the same height which contains almost exactly the same transactions.
    – Andrew Chow ♦
    Oct 21, 2017 at 18:31
  • 1
    The solutions are not nonces. Nonces are part of the data that is hashed and are what is commonly changed when trying to find a block hash (the solution) that is less than the target. The data that is hashed for the block hash includes the hash of all of the transactions in the block, so changing the transactions will also change the block hash.
    – Andrew Chow ♦
    Oct 21, 2017 at 18:34
1

4: As far as the protocol is concerned, it is completely at the miner's discretion which transactions to include. It is legal if the miner chooses to include no transactions at all (other than the coinbase transaction which is required), and some miners actually do this (it means that the block is small and can be relayed quickly, which slightly decreases the chance that it will be orphaned).

Most miners will include as many unconfirmed transactions as possible, up to the block size limit, preferring those which have the highest fees. They may automatically exclude those which transfer a very small value (so-called "dust") or whose fee is below some threshold.

5: The miner is expected to verify that every transaction in his block is valid (outputs not already spent, valid ECDSA signatures, etc). When he finds a nonce which attains the target hash and submits his block to the network, other nodes will attempt to similarly verify the transactions in it, and if they are not all valid the entire block will be rejected (i.e. other miners will not use this block's hash as the "previous block" in their own mining). However, mining is not necessary for this sort of verification, since non-mining nodes will also do this verification, and refuse to recognize any transactions that don't pass.

Improve this answer
3
  • Sorry, why would I not put as many transactions in the block as it fits?
    – croraf
    Oct 21, 2017 at 18:27
  • Does the difficulty of "solving hash" depends on the number of transactions in the block (or maybe some other transaction related weight)?
    – croraf
    Oct 21, 2017 at 18:38
  • en.bitcoin.it/wiki/Block_hashing_algorithm below the table it states that the difficulty is the same irrespective of transactions if I read correctly.
    – croraf
    Oct 21, 2017 at 20:58

Your Answer

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

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