The current way of deriving revocation public key is wrong. We can't obtain the correct private key when the counterparty reveals his revocation secret.
We are skipping one commitment point while sending and verifying RevokeAndAck messages.
The commitment transaction outputs should use both the revocation key and delayed output key of the same party.
I also made one change that is required to construct the revocation transaction.
This PR adds a unit test to check that we can revoke an older commitment transaction.
While developing on this PR, I found a few bugs in current implementation.
RevokeAndAck
messages.I also made one change that is required to construct the revocation transaction.