Attributable failures prefactor #3650
Conversation
|
👋 Thanks for assigning @arik-so as a reviewer! |
joostjager
force-pushed
the
attributable-failures-prefactor
branch
from
894c91e to
f82cb5a
Compare
|
Rebased |
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
joostjager
force-pushed
the
attributable-failures-prefactor
branch
from
f82cb5a to
8d01eb9
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3650 +/- ##
==========================================
- Coverage 89.24% 89.22% -0.02%
==========================================
Files 155 155
Lines 119280 119314 +34
Branches 119280 119314 +34
==========================================
+ Hits 106446 106463 +17
- Misses 10240 10248 +8
- Partials 2594 2603 +9 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
🔔 1st Reminder Hey @arik-so! This PR has been waiting for your review. |
joostjager
force-pushed
the
attributable-failures-prefactor
branch
from
8d01eb9 to
47a06c5
Compare
| @@ -909,15 +907,17 @@ pub(super) fn build_failure_packet( | |||
| hmac.input(&packet.encode()[32..]); | |||
| packet.hmac = Hmac::from_engine(hmac).to_byte_array(); | |||
|
|
|||
| packet | |||
| OnionErrorPacket { data: packet.encode() } | |||
There was a problem hiding this comment.
Bleh, it seems pretty weird that we now have OnionErrorPackets flying around (at least outside of onion_utils.rs) that are both decrypted and encrypted. I think the reason it was written the way it was previously was specifically to avoid that - holding the encoded bytes until we get around to encrypting, then making it an OnionErrorPacket. It seems much too easy now to double-en/decrypt or forget to en/decrypt.
There was a problem hiding this comment.
I think a similar situation already existed for intermediate nodes? In
rust-lightning/lightning/src/ln/onion_utils.rs
Line 1389 in 4c43a5b
OnionErrorPacket received from downstream is encrypted into again an OnionErrorPacket.
The way I see it is that there's "data" in the packet that needs to be encrypted, and it doesn't matter whether that data is 0, 1, 2, etc times encrypted already.
There was a problem hiding this comment.
Open to alternatives of course. Were you thinking of pulling the encrypt step into build_failure_packet too?
There was a problem hiding this comment.
Yea, certainly not saying the old code was perfect and indeed its already the case that things are encrypted multiple times. I guess I just saw OnionErrorPacket as "encrypted thing ready to go over the wire/received on the wire". Certainly stuff internal to onion_utils doesn't matter quite as much, but once it leaves onion_utils.rs it looks like it'd be really easy to have code that just forgets to encrypt/decrypt (ie the callsite would just read build_failure_packet and the fact that its unencrypted isn't obvious).
Pulling the encrypt step into build_failure_packet seems like one perfectly good way to address it.
There was a problem hiding this comment.
Done. Just kept a non-public unencrypted version of build_failure_packet for the bolt test vector test.
joostjager
force-pushed
the
attributable-failures-prefactor
branch
3 times, most recently
from
fe6cd21 to
baffc82
Compare
lightning/src/ln/onion_utils.rs
Outdated
| shared_secret: &[u8], raw_packet: &[u8], | ||
| ) -> msgs::OnionErrorPacket { | ||
| /// Encrypts/decrypts a failure packet. | ||
| pub(super) fn crypt_failure_packet(shared_secret: &[u8], packet: &mut OnionErrorPacket) { |
There was a problem hiding this comment.
Does this need to remain public now?
There was a problem hiding this comment.
It's used in onion_route_tests.rs - I think there is no other way to make it available there, or is there?
There was a problem hiding this comment.
Often we do a test wrapper like the below. For four LoC we could even just copy them into the tests, though.
#[cfg(test)]
pub fn test_crypt_failure_packet(shared_secret, packet) { crypt_failure_packet(shared_secret, packet) }
There was a problem hiding this comment.
Well, it's about testing that function also, so wouldn't want to copy it.
Created the test wrapper.
joostjager
force-pushed
the
attributable-failures-prefactor
branch
from
baffc82 to
9fbbcdc
Compare
Prepares for extending OnionErrorPacket with attribution data.
This commits prepares the persistence layer for the addition of attribution data. Changes: - Expand InboundHTLCRemovalReason serialization instead of using the macro. When attribution data is added, it can't just be serialized along with the existing fields because it would break backwards compatibility. Instead the new field needs to go into the tlv block. - Stop using OnionErrorPacket in the UpdateFailHTLC message. When attribution data is added to OnionErrorPacket, it would not be serialized for the wire properly because also here the new field needs to go in the tlv extension of the message. - Prepare HTLCFailReasonRepr serialization for that addition of attribution data. Co-authored-by: Matt Corallo <[email protected]>
joostjager
force-pushed
the
attributable-failures-prefactor
branch
from
db221e2 to
1426197
Compare
Preparatory non-functional commits extracted from #3611