Matt Corallo 7165d6d48f Fix panic on receiving channel_ready after 1st commitment update ... `cur_counterparty_commitment_transaction_number` starts at `INITIAL_COMMITMENT_NUMBER`, gets decremented once when the initial `channel_ready` message is received, and gets decremented a second time when the first `revoke_and_ack` is received, revoking the first counterparty commitment point. At this point, `counterparty_prev_commitment_point` points to the non-revoked second commitment point. If we then process a second `channel_ready`, we check the `cur_counterparty_commitment_transaction_number` number, see that if is `INITIAL_COMMITMENT_NUMBER - 2` (i.e. not `- 1`) and assume that the *second* commitment number has been revoked (by `expect`ing `CounterpartyCommitmentSecrets::get_secret` with `INITIAL_COMMITMENT_NUMBER - 1`). This `expect` panic's. As the second commitment point has not yet been revoked, we should fetch it from `counterparty_prev_commitment_point`, which we do here, adding a test which failed on the previous code as well. Found by the `full_stack_target` fuzzer.		2023-01-08 02:02:47 +00:00
..
src	Fix panic on receiving channel_ready after 1st commitment update	2023-01-08 02:02:47 +00:00
Cargo.toml	Bump crate versions to 0.0.113/invoice 0.21	2022-12-15 22:15:55 +00:00