#1199 Followup #1324
#1199 Followup #1324
Conversation
valentinewallace
force-pushed
the
2022-02-phantom-followup
branch
from
1a9e872 to
f486514
Compare
Codecov Report
@@ Coverage Diff @@
## main #1324 +/- ##
==========================================
+ Coverage 90.52% 91.17% +0.64%
==========================================
Files 72 72
Lines 39560 43078 +3518
==========================================
+ Hits 35811 39275 +3464
- Misses 3749 3803 +54
Continue to review full report at Codecov.
|
valentinewallace
force-pushed
the
2022-02-phantom-followup
branch
from
f486514 to
1cd98ed
Compare
valentinewallace
force-pushed
the
2022-02-phantom-followup
branch
from
1cd98ed to
db7ff46
Compare
|
Can you add some more tests - eg (a) that don't modify the onion at all, by just editing the route to have incorrect values - too-low CLTV, too low amount, etc (b) that hit |
valentinewallace
force-pushed
the
2022-02-phantom-followup
branch
from
db7ff46 to
c743adb
Compare
Thanks, I think I added these but whew each one found a bug basically (one preexisting tbf). So let me know if anything's missing |
valentinewallace
force-pushed
the
2022-02-phantom-followup
branch
from
c743adb to
b32e955
Compare
|
I'm not quite sure why the test I wrote at https://git.bitcoin.ninja/index.cgi?p=rust-lightning;a=commit;h=1907bcc5d055008eae4e378f2907cba15d719587 is failing - can you examine it a bit and include that test here? |
valentinewallace
force-pushed
the
2022-02-phantom-followup
branch
from
b32e955 to
5f8164e
Compare
This will be used in upcoming commit(s) to encrypt phantom payment failure packets.
This also fixes a bug where we were failing back phantom payments with the wrong scid, causing them to never actually be failed backwards (L3022 in channelmanager.rs) This new field will be used in upcoming commit(s) to encrypt phantom payment failure packets.
Ensure we fail back phantom malformed payments with an update_fail_htlc s.t. the error contains the sha256 of the onion, per LN protocol.
In any place where fail_htlc_backwards_internal was called for a phantom payment failure, we weren't encoding the onion failure as if the phantom were the one failing. Instead, we were encoding the failure as if it were coming from the second-to-last hop. This caused our failures to not be parsed properly on the payer's side. Places we were encoding failures incorrectly include: * on failure of a call to inbound_payment::verify * on a user call to fail_htlc_backwards Also drop some unnecessary panics when reading OnionHopData objects. This also enables one of the phantom failure tests because we can construct OnionHopDatas with invalid amounts. Lastly, remove a bogus comment
Failing an HTLC with onion error channel_disabled requires encoding a 'flags' field into the failure packet. However, we were encoding this 'flags' field for all failures packets that were failing on update_add_htlc with an update (error 0x1000 UPDATE). Discovered in the course of adding phantom payment failure tests, which also added testing for this bug
valentinewallace
force-pushed
the
2022-02-phantom-followup
branch
from
5f8164e to
694ef1e
Compare
| .expected_htlc_error_data(0x4000 | 15, &error_data); | ||
| expect_payment_failed_conditions!(nodes[0], payment_hash, true, fail_conditions); | ||
| } | ||
|
|
Closes #1308.