Ensure derive_channel_keys doesn't panic if per-run seed is high

[TheBlueMatt]

b04d1b8 changed the way we
calculate the channel_keys_id to include the 128-bit
user_channel_id as well, shifting the counter up four bytes and
the starting_time_nanos field up into the second four bytes.

In derive_channel_keys we hash the full channel_keys_id with an
HD-derived key from our master seed. Previously, that key was
derived with an index of the per-restart counter, re-calculated by
pulling the second four bytes out of the user_channel_id. Because
the channel_keys_id fields were shifted up four bytes, that is
now a reference to the starting_time_nanos value. This should be
fine, the derivation doesn't really add any value here, its all
being hashed anyway, except that derivation IDs must be below 2^31.
This implies that we panic if the user passes a
starting_time_nanos which has the high bit set. For those using
the nanosecond part of the current time this isn't an issue - the
value cannot exceed 1_000_000, which does not have the high bit
set, however, some users may use some other per-run seed.

Thus, here we simply drop the high bit from the seed, ensuring we
don't panic. Note that this is backwards compatible as it only
changes the key derivation in cases where we previously panicked.

Ideally we'd drop the derivation entirely, but that would break
backwards compatibility of key derivation.

I'm a little less concerned about this for rust users, but I do think we should backport this to 113 bindings, as bindings users more often use non-time for the starting_time_nanos field.

[codecov-commenter]

Codecov Report

Base: 90.77% // Head: 91.72% // Increases project coverage by +0.94% 🎉

Coverage data is based on head (5dde803) compared to base (f6a9382).
Patch coverage: 83.33% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1935      +/-   ##
==========================================
+ Coverage   90.77%   91.72%   +0.94%     
==========================================
  Files          94       96       +2     
  Lines       49603    57157    +7554     
  Branches    49603    57157    +7554     
==========================================
+ Hits        45028    52427    +7399     
- Misses       4575     4730     +155     

Impacted Files	Coverage Δ
lightning/src/chain/keysinterface.rs	86.02% <83.33%> (+2.87%)	⬆️
lightning/src/util/events.rs	29.35% <0.00%> (-0.23%)	⬇️
lightning/src/chain/onchaintx.rs	95.17% <0.00%> (-0.21%)	⬇️
lightning/src/ln/reorg_tests.rs	100.00% <0.00%> (ø)
lightning/src/offers/refund.rs	93.73% <0.00%> (ø)
lightning/src/ln/outbound_payment.rs	89.26% <0.00%> (ø)
lightning/src/ln/channel.rs	89.03% <0.00%> (+0.17%)	⬆️
lightning/src/ln/monitor_tests.rs	99.84% <0.00%> (+0.27%)	⬆️
lightning/src/ln/inbound_payment.rs	93.78% <0.00%> (+0.29%)	⬆️
lightning/src/offers/offer.rs	93.91% <0.00%> (+0.46%)	⬆️
... and 12 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[tnull]

Looks good, two nits.

[arik-so]

great catch, but this is getting too complicated. Let's extract chan_id % (1 << 31) into a variable, and then let's extract ChildNumber::from_hardened_idx into a separate variable, and pass that to the method in one line.

[TheBlueMatt]

I don't see how more variables makes things more readable, the indentation as-is makes clear what's being expected where, no?

[arik-so]

Well, most people find that more comfortable to read, but the PR's perfectly fine as is.

[TheBlueMatt]

Pushed the fixup of the comments in the last commit -

diff --git a/lightning/src/chain/keysinterface.rs b/lightning/src/chain/keysinterface.rs
index 2a3fb2cc8..d260d0294 100644
--- a/lightning/src/chain/keysinterface.rs
+++ b/lightning/src/chain/keysinterface.rs
@@ -1264,8 +1264,9 @@ impl KeysInterface for KeysManager {
        fn generate_channel_keys_id(&self, _inbound: bool, _channel_value_satoshis: u64, user_channel_id: u128) -> [u8; 32] {
                let child_idx = self.channel_child_index.fetch_add(1, Ordering::AcqRel);
-               // child_idx is the only thing guaranteed to make each channel unique without a restart
+               // `child_idx` is the only thing guaranteed to make each channel unique without a restart
                // (though `user_channel_id` should help, depending on user behavior). If it manages to
-               // role over, we're screwed. Because we only support 32-bit+ systems, assert that our
-               // AtomicUsize doesn't reach u32::MAX.
+               // roll over, we may generate duplicate keys for two different channels, which could result
+               // in loss of funds. Because we only support 32-bit+ systems, assert that our `AtomicUsize`
+               // doesn't reach `u32::MAX`.
                assert!(child_idx < core::u32::MAX as usize, "2^32 channels opened without restart");
                let mut id = [0; 32];