X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;ds=sidebyside;f=lightning%2Fsrc%2Fln%2Fchannel.rs;h=231ee832befe77a32c1166c8ab2ba87151623934;hb=1443509d77a1ee0edc16dbf1ff962861a1a5e1de;hp=c86136d6070a8f2c7909f8f3b39c743689ecd1f9;hpb=8ee626c9a4b8b3477acb772ae5de0e49704183e6;p=rust-lightning diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs index c86136d6..231ee832 100644 --- a/lightning/src/ln/channel.rs +++ b/lightning/src/ln/channel.rs @@ -240,7 +240,10 @@ pub(super) struct Channel { secp_ctx: Secp256k1, channel_value_satoshis: u64, + #[cfg(not(test))] local_keys: ChanSigner, + #[cfg(test)] + pub(super) local_keys: ChanSigner, shutdown_pubkey: PublicKey, // Our commitment numbers start at 2^48-1 and count down, whereas the ones used in transaction @@ -1995,6 +1998,17 @@ impl Channel { self.channel_monitor.provide_secret(self.cur_remote_commitment_transaction_number + 1, msg.per_commitment_secret) .map_err(|e| ChannelError::Close(e.0))?; + if self.channel_state & ChannelState::AwaitingRemoteRevoke as u32 == 0 { + // Our counterparty seems to have burned their coins to us (by revoking a state when we + // haven't given them a new commitment transaction to broadcast). We should probably + // take advantage of this by updating our channel monitor, sending them an error, and + // waiting for them to broadcast their latest (now-revoked claim). But, that would be a + // lot of work, and there's some chance this is all a misunderstanding anyway. + // We have to do *something*, though, since our signer may get mad at us for otherwise + // jumping a remote commitment number, so best to just force-close and move on. + return Err(ChannelError::Close("Received an unexpected revoke_and_ack")); + } + // Update state now that we've passed all the can-fail calls... // (note that we may still fail to generate the new commitment_signed message, but that's // OK, we step the channel here and *then* if the new generation fails we can fail the