<p>(<a href="https://en.bitcoin.it/wiki/Protocol_documentation" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Protocol_documentation</a> is a good resource for technical details about the protocol)</p>

<p>At the topmost level, blocks contain three things:</p>

<ol>
<li>80 byte block header.</li>
<li>VarInt for the number of transactions in the block (N).</li>
<li>N concatenated transactions.</li>
</ol>

<p>The block header contains:</p>

<ol>
<li>4 byte version number</li>
<li>Prev block hash pointer.</li>
<li>Merkle hash/root of the N transactions in the block. (See <a href="https://bitcoin.stackexchange.com/questions/10479/what-is-the-merkle-root">What is the Merkle root?</a>)</li>
<li>Block timestamp</li>
<li>Difficulty to solve the block encoded as an integer.</li>
<li>Nonce - an easy number to change to try different hash values.</li>
</ol>

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

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

<blockquote>
  <p>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?</p>
</blockquote>

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

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

<p>Neither.</p>

<blockquote>
  <p>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?</p>
</blockquote>

<p>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.</p>

CC BY-SA 3.0
2015-12-02T13:13:59.460Z
2015-12-02T13:13:59.460Z
2017-04-13T12:47:33.583Z
morsecoder
<p>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. </p>

<p>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. </p>

<p>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. </p>

<p>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.</p>

CC BY-SA 3.0
2017-08-30T11:43:14.660Z
2017-08-30T11:43:14.660Z
amritkrs
<p>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):</p>

<blockquote>
  <p>...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.</p>
</blockquote>

<p>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.</p>

<p>Logically, that is the only thing that makes sense to make it tamper resistant.</p>

CC BY-SA 3.0
2016-11-25T11:04:50.840Z
I don't understand this point. why change k -> change k+1 -> change k+2 ... so it will go unlimited or at least go the tail of list. why textbook said go to the head of the list. thanks
hqt
CC BY-SA 3.0
2016-10-18T23:03:02.407Z
2016-10-18T23:03:02.407Z
nbz
<p>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.</p>

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

<p>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).</p>

<p>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.</p>

<p>I hope this makes it clear for you.</p>

CC BY-SA 3.0
2016-11-25T12:45:16.523Z
2016-11-25T12:45:16.523Z
Aditya Sahay
<p>I'm not sure how to ask this question clearly so I will ask it three different ways and hopefully someone understands me.</p>

<ol>
<li><p>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?</p></li>
<li><p>Does the hash pointer in block k+1 look like this : H(k) or this : H(k||H(k-1))?</p></li>
<li><p>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 <strong>entire</strong> block k (so, the data and H(k-1))? Because if block k+1 contained a hash of the <strong>entire</strong> block k then it should contain a hash of the hash already contained in block k right?</p></li>
</ol>

<p>I hope I made some sense. Any help is appreciated.</p>

<blockchain><hash>
What exactly is the input for the Hash pointer in block k+1?
Riva
# What exactly is the input for the Hash pointer in block k+1?

(Asked by: username_0 on 2015-12-02)

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.

**Tags:** blockchain, hash


---

## 4 answers

### Answer by username_1 on 2015-12-02. Score: 4

(<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?](https://bitcoin.stackexchange.com/questions/10479/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 by username_2 on 2017-08-30. Score: 0

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.


---

### Answer by username_3 on 2016-10-18. Score: 0

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.

> **Comments:**
> **username_4**: I don't understand this point. why change k -> change k+1 -> change k+2 ... so it will go unlimited or at least go the tail of list. why textbook said go to the head of the list. thanks  

---

### Answer by username_5 on 2016-11-25. Score: 0

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.


---

