What exactly is the input for the Hash pointer in block k+1?

Question

I'm not sure how to ask this question clearly so I will ask it three different ways and hopefully someone understands me.

1. Is the input for the hash pointer in block k+1 just the transactions in block k or is it the transactions in block k as well as the hash of block k-1?

2. Does the hash pointer in block k+1 look like this : H(k) or this : H(k||H(k-1))?

3. In block k+1, there is a bunch of data as well as a hash pointer for the block k. But does block k+1 contain a hash of the entire block k (so, the data and H(k-1))? Because if block k+1 contained a hash of the entire block k then it should contain a hash of the hash already contained in block k right?

I hope I made some sense. Any help is appreciated.

Answer 1

(https://en.bitcoin.it/wiki/Protocol_documentation is a good resource for technical details about the protocol)

At the topmost level, blocks contain three things:

1. 80 byte block header.
2. VarInt for the number of transactions in the block (N).
3. N concatenated transactions.

The block header contains:

1. 4 byte version number
2. Prev block hash pointer.
3. Merkle hash/root of the N transactions in the block. (See What is the Merkle root?)
4. Block timestamp
5. Difficulty to solve the block encoded as an integer.
6. Nonce - an easy number to change to try different hash values.

I think you are asking: what is the 2nd block header parameter in block k+1?

Each hash pointer in a block to point to the previous block is SHA256(SHA256(80 byte header of block k)).

Is the input for the hash pointer in block k+1 just the transactions in block k or is it the transactions in block k as well as the hash of block k-1?

It's just the hash of the header. The header contains a hash of the transactions, though, the merkle root.

Does the hash pointer in block k+1 look like this : H(k) or this : H(k||H(k-1))?

Neither.

In block k+1, there is a bunch of data as well as a hash pointer for the block k. But does block k+1 contain a hash of the entire block k (so, the data and H(k-1))? Because if block k+1 contained a hash of the entire block k then it should contain a hash of the hash already contained in block k right?

You do need the hash pointer in block k to be able to calculate the hash pointer in block k+1. Verifying the hash pointers and their difficulties is a small part of the work of miners.

Answer 2

I think your question is related to a generic definition of hash pointers (irrespective of bitcoin's protocol). If I am correct about that then, while reading the Princeton Bitcoin book, it says the following about hash pointers (page 33):

...the adversary changes the data of some block ​ k ​ . Since the data has been changed, the hash in block ​ k ​ + 1, which is a hash of the entire block ​ k ​ , is not going to match up. Remember that we are statistically guaranteed that the new hash will not match the altered content since the hash function is collision resistant. And so we will detect the inconsistency between the new data in block ​ k ​ and the hash pointer in block ​ k ​ + 1. Of course the adversary can continue to try and cover up this change by changing the next block’s hash as well. The adversary can continue doing this, but this strategy will fail when he reaches the head of the list. Specifically, as long as we store the hash pointer at the head of the list in a place where the adversary cannot change it, the adversary will be unable to change any block without being detected.

What the above suggests is that if someone wants to tamper data in k, then they will need to change the hash pointer in k+1 to cover up their mistake and then the next one (k+2) and then k+3 and so on until they reach the head. This makes me believe that the hash pointer points to a hash of the data PLUS the previous hash pointer.

Logically, that is the only thing that makes sense to make it tamper resistant.

Answer 3

The Block-Chain technology is such that if any part of it, be it data or hash-pointer, is altered, the final hash-pointer would mismatch.

This itself implies that the hash pointer of k+1 block has to be H(k||H(k-1)).

If you think for a moment if the hash pointer was H(k). If an adversary had to tamper with the data of k-1 block, the hash pointer of only the next i.e. kth block, would have to be changed in order to make the entire block chain consistent(the hash pointer of k+1 block will remain the same).

However, since the hash pointer is H(k||H(k-1)), the hash pointer for k+1 will also get modified. This will continue all the way till the end of the block-chain.

I hope this makes it clear for you.

Answer 4

The book that you mentioned is indeed confusing. Let me clarify it. Let's assume block1 to be genesis block. Then block 2 will contain data and in its header, it will contain the H(block1). Similarly block 3 then will contain its data and H(block2). Now note that by writing H(blockn), I mean the entire block and not just the data of blockn. Thus you get the chain.

Now modification to any block, say block3 will necessitate a change in hash of block4, which will require a change in block5 and so on till the head of the list.

Why I call this last added block as head of the list is because the pointers in this linked list is in backward direction and therefore genesis block becomes the permanent tail of the list.

Having said this, now you can understand why it is difficult to modify a old block once the list have become large enough. That's why in bitcoin chain, if a block gets 5 more children added in front of it then they assume that block to be valid as it's hard to recompute 5 blocks quickly in bitcoin chain.