Can I use M1 straight away and get rid of IV in Merkle–Damgård? In Merkle–Damgård is there any reason why we use a fixed $IV$ at the beginning? Can we use the first block ($M_1$) right away instead of $IV$ and feed it through the compression function with $M_2$.
TL;DR: A simple reason why we use the IV is to mitigate second preimage attacks.

This is the typical Merkle–Damgård construction: you split your messages in blocs of $k$ bits (input size of the compression function).

    M1         M2 ...     Mn
    |          |          |
    +--|\      +--|\      +--|\
       | \        | \        | \
 IV ---|  |-------|  |-------|  |---  Hash
       +--+       +--+       +--+


your proposal is the following :

    M2         M3 ...     Mn
    |          |          |
    +--|\      +--|\      +--|\
       | \        | \        | \
 M1 ---|  |-------|  |-------|  |---  Hash
       +--+       +--+       +--+


This assumes that the message is longer than $k$ bits! What if the message is shorter ? Well you get the following because you don't have an IV to compress with.

 M1 ---  Hash


Also this idea of using $M_1$ as an $IV$ assumes that the inputs of your compression function have the same size e.g. if you take $f(x,y) \to h$ where:


$\texttt{sizeof}(x) = 128 \texttt{bits}$ and
$\texttt{sizeof}(h) = 160 \texttt{bits}$


This implies that  $\texttt{sizeof}(y) = 160 \texttt{bits}$. Therefore the use of an IV is encouraged unless you want to manage a padding for the first input...

What if we have a fixed last bloc compression ?

Such that:

    M2         M3 ...     Mn ...     LB
    |          |          |          |
    +--|\      +--|\      +--|\      +--|\
       | \        | \        | \        | \
 M1 ---|  |-------|  |-------|  |-------|  |---  Hash
       +--+       +--+       +--+       +--+


And in the case of very short messages:

    LB
    |
    +--|\
       | \
 M1 ---|  |---  Hash
       +--+


In the end don't you agree that this is the same has having a fixed first block, also called an IV ? You still need to save this value. Whether it is at the end or at the beginning, it is needed.

A Second Pre-image attack

Quick reminder:


  Given an input $m_1$ it should be difficult to find another input $m_2$ such that $m_1 \neq m_2$ and $hash(m_1)=hash(m_2)$. Functions that lack this property are vulnerable to second-preimage attacks.


Feeding directly $M_1$ instead of the IV whatever the construction above (with or without a fixed last block) leads to a second-preimage attack:

Let $M_1$ such that $M_1 = a || b || c || d$ where $||$ is the concatenation and $a,b,c,d$ are of the right size. We pose $H(a || b || c || d) = h$.

    b          c          d
    |          |          |
    +--|\      +--|\      +--|\
       | \        | \        | \
  a ---|  |---h'--|  |---h"--|  |---  h
       +--+       +--+       +--+


Notice that we have $h'$ and $h''$ such that $h = H(a||b)$ and $h'' = H(a||b||c)$.

What happen if we compute $H(h'||c||d)$ or $H(h''||d)$ ?

   c         d
   |         |
   +--|\     +--|\
      | \       | \
  h'--|  |------|  |---  h
      +--+      +--+


    d
    |
    +--|\
       | \
 h'' --|  |---  h
       +--+


In both case you will get $h$ which leads to:
$$\begin{align*}
H(a || b || c || d) &amp;= h\\
&amp;= H(h' || c || d)\\
&amp;= H(h''||d)
\end{align*}$$

Thus we have a collision through a second preimage attack (note that the compression function may be perfectly secure!).

How to solve this?

Multiple solutions exists:


Use an IV.
Encode the length of the input in the last block.
add a domain separation encoding at the end of each block.


Solutions has been discussed in the following paper (see section 8:  Implications for sequential hashing).