Ethereum receipts blockid and hashes

Question

Preface: The question relates to the relationship between the content of the Ethereum's receipts and the hash of the block header.

Problem description: I wonder, in Ethereum, blockid is based on the block's hash. The header contains the hash of the root of the receipts Trie. The receipt contains the block's ID.

But before putting the block's id into the receipt one needs to know the hash of the block itself (which contains a hash of the Receipts Trie) - in other words we've got a circular dependency.

Now, I see 4 possibilities:

1) The block contains receipts of transactions which are contained within the block; if not then this would be easy; receipts would be stored in consecutive blocks; but this would complicate things; as there would need to be an incentive for other nodes to include external receipts etc.

2) The hash of the Receipt's Trie does not take into account the blockID field within receipts. This would result in some of the data being malleable (not protected by the PoW).

3) The blockID is not based on the hash value of the entire header. Thus not taking into account the hash of the Receipts Trie.

4) Theres' no blockID inside of a receipt; but then I've seen these are included on some of the JSON print-outs available here. are these values appended by the command'processing interface implicitly?

Which one, or maybe another possibility, is it?

Answer 1

The answer is 4). The receipt doesn't have the blockId.

From Ethereum's Yellow Paper section 4.3.1 "Transaction Receipt"

The transaction receipt, R, is a tuple of four items comprising: the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, R_u, the set of logs created through execution of the transaction, R_l and the Bloom filter composed from information in those logs, R_b and the status code of the transaction, R_z:

(20) R ≡ (R_u, R_b, R_l, R_z)

Some tools/frameworks add the extra information, like block hash, transaction hash or timestamp, because it is useful and often they have it already cached.