Why is the obscured commitment number necessary in lightning commitment TX's?
Looking at the c-lightning code I find this call: 

    txs[0] = commit_tx(ctx, &amp;channel-&gt;funding_txid,
               channel-&gt;funding_txout,
               channel-&gt;funding_msat / 1000,
               channel-&gt;funder,
               channel-&gt;config[!side].to_self_delay,
               &amp;keyset,
               channel-&gt;view[side].feerate_per_kw,
               channel-&gt;config[side].dust_limit_satoshis,
               channel-&gt;view[side].owed_msat[side],
               channel-&gt;view[side].owed_msat[!side],
               committed,
               htlcmap,
               commitment_number ^ channel-&gt;commitment_number_obscurer,
               side);


in particular the following line: 

commitment_number ^ channel-&gt;commitment_number_obscurer


Tracing down the commitment_number variable this suggests to me that it is really an integer. If you see how often in the code it has to validated that two commitment transactions are directly succeeding each other it makes sense to have an unobscured integer instead of a txid. Consider For example this code block:

    /* FIXME: Document this requirement in BOLT 2! */
    /* We can't send two commits in a row. */
    if (peer-&gt;revocations_received != peer-&gt;next_index[REMOTE] - 1) {
        assert(peer-&gt;revocations_received
               == peer-&gt;next_index[REMOTE] - 2);
        peer-&gt;commit_timer_attempts++;


It is obscured later since the information how many commitment tx existed should not be public. It is as far as I understand obscured with an OTP via XOR. The OTP is the one you mentioned above. The idea is to have an integer that can be used but obscure it when being sent to the blockchain. I did not find a position in the code where the obscured value is taken and processed to a clean value however.

I hope that helps (: