Merge pull request #1285 from TheBlueMatt/2022-01-remove-closed-issue-ref

Remove stale reference to incomplete BOLT compliance

diff --combined lightning/src/ln/channel.rs
index fc48a6b9a1ceb777eea964f19b89bd729072b60f,4a4742e007ba2fc1334bd7bf7898313a81cc11e6..19e1c8e3643b8c84b9a741ee053c5bea4e617359
--- 1/lightning/src/ln/channel.rs
--- 2/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@@ -942,6 -942,14 +942,6 @@@ impl<Signer: Sign> Channel<Signer> 
        fn check_remote_fee<F: Deref>(fee_estimator: &F, feerate_per_kw: u32) -> Result<(), ChannelError>
                where F::Target: FeeEstimator
        {
 -              let lower_limit = fee_estimator.get_est_sat_per_1000_weight(ConfirmationTarget::Background);
 -              // Some fee estimators round up to the next full sat/vbyte (ie 250 sats per kw), causing
 -              // occasional issues with feerate disagreements between an initiator that wants a feerate
 -              // of 1.1 sat/vbyte and a receiver that wants 1.1 rounded up to 2. Thus, we always add 250
 -              // sat/kw before the comparison here.
 -              if feerate_per_kw + 250 < lower_limit {
 -                      return Err(ChannelError::Close(format!("Peer's feerate much too low. Actual: {}. Our expected lower limit: {} (- 250)", feerate_per_kw, lower_limit)));
 -              }
                // We only bound the fee updates on the upper side to prevent completely absurd feerates,
                // always accepting up to 25 sat/vByte or 10x our fee estimator's "High Priority" fee.
                // We generally don't care too much if they set the feerate to something very high, but it
@@@ -951,14 -959,6 +951,14 @@@
                if feerate_per_kw as u64 > upper_limit {
                        return Err(ChannelError::Close(format!("Peer's feerate much too high. Actual: {}. Our expected upper limit: {}", feerate_per_kw, upper_limit)));
                }
 +              let lower_limit = fee_estimator.get_est_sat_per_1000_weight(ConfirmationTarget::Background);
 +              // Some fee estimators round up to the next full sat/vbyte (ie 250 sats per kw), causing
 +              // occasional issues with feerate disagreements between an initiator that wants a feerate
 +              // of 1.1 sat/vbyte and a receiver that wants 1.1 rounded up to 2. Thus, we always add 250
 +              // sat/kw before the comparison here.
 +              if feerate_per_kw + 250 < lower_limit {
 +                      return Err(ChannelError::Close(format!("Peer's feerate much too low. Actual: {}. Our expected lower limit: {} (- 250)", feerate_per_kw, lower_limit)));
 +              }
                Ok(())
        }
  
@@@ -4731,9 -4731,6 +4731,6 @@@
        /// Will only fail if we're not in a state where channel_announcement may be sent (including
        /// closing).
        ///
-       /// Note that the "channel must be funded" requirement is stricter than BOLT 7 requires - see
-       /// https://github.com/lightningnetwork/lightning-rfc/issues/468
-       ///
        /// This will only return ChannelError::Ignore upon failure.
        fn get_channel_announcement(&self, node_id: PublicKey, chain_hash: BlockHash) -> Result<msgs::UnsignedChannelAnnouncement, ChannelError> {
                if !self.config.announced_channel {
@@@ -6154,13 -6151,6 +6151,13 @@@ mod tests 
                        "MAX_FUNDING_SATOSHIS is greater than all satoshis in existence");
        }
  
 +      #[test]
 +      fn test_no_fee_check_overflow() {
 +              // Previously, calling `check_remote_fee` with a fee of 0xffffffff would overflow in
 +              // arithmetic, causing a panic with debug assertions enabled.
 +              assert!(Channel::<InMemorySigner>::check_remote_fee(&&TestFeeEstimator { fee_est: 42 }, u32::max_value()).is_err());
 +      }
 +
        struct Keys {
                signer: InMemorySigner,
        }