Decide whether to use the same commitment number for both parties

[contrun]

Currently, we follow bolts to use different commitment number. bolts/00-introduction.md at master · lightning/bolts

A 48-bit incrementing counter for each commitment transaction; counters are independent for each peer in the channel and start at 0.

The current implementation store both local and remote commitment number in channel state.

ckb-pcn-node/src/ckb/channel.rs at accd10155064b624efa7afd4aafb0ab3021c5d0e · contrun/ckb-pcn-node

It seems using the same commitment number will simplify a few things (in the cost of requiring both nodes to synchronize before updating commitment number). For example, we can use the same number to store the TLC info.

Should we use the same commitment number for both parties? If so, what are the things we need to be careful from both the perspective of protocol and the perspective of implementation.

[contrun]

Using the same transaction ID may result in dead lock when both parties try to send a CommitmentSigned to another. Since both parties have sent out their partial signature, they must get the RevokeAndAck message from another for the channel to make progress. But if both parties are unknowingly sending simultaneous CommitmentSIgnedmessage, then this will create a deadlock, as both of they are waiting for the RevokeAndAck message.

[contrun]

As commented above #43 (comment) , there are some difficulties in using the same commitment number.