Why is the obscured commitment number necessary in lightning commitment TX's? The obscured commitment number for each commitment transaction is the lower 48 bits of:

SHA256(payment_basepoint from open_channel || payment_basepoint from accept_channel)


It is encoded in the lock time and sequence fields (24bits each) of the commitment transaction. I don't understand why it is necessary, the BOLT rfc reads:


  This obscures the number of commitments made on the channel in the
  case of unilateral close, yet still provides a useful index for both
  nodes (who know the payment_basepoints) to quickly find a revoked
  commitment transaction.


Why doesn't the TXID of the commitment TX suffice as lookup index key?
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 (: