mirror of
https://github.com/lightningdevkit/rust-lightning.git
synced 2025-02-27 17:01:10 +01:00
8bf3d8dec2
Our current PaymentReceived API is incredibly easy to mis-use - the "obvious" way to implement a client is to always call `ChannelManager::claim_funds` in response to a `PaymentReceived` event. However, users are *required* to check the payment secret and value against the expected values before claiming in order to avoid a number of potentially funds-losing attacks. Instead, if we rely on payment secrets being pre-registered with the ChannelManager before we receive HTLCs for a payment we can simply check the payment secrets and never generate `PaymentReceived` events if they do not match. Further, when the user knows the value to expect in advance, we can have them register it as well, allowing us to check it for them. Other implementations already require payment secrets for inbound payments, so this shouldn't materially lose compatibility. |
||
|---|---|---|
| .. | ||
| chan_utils.rs | ||
| chanmon_update_fail_tests.rs | ||
| channel.rs | ||
| channelmanager.rs | ||
| features.rs | ||
| functional_test_utils.rs | ||
| functional_tests.rs | ||
| mod.rs | ||
| msgs.rs | ||
| onchaintx.rs | ||
| onion_route_tests.rs | ||
| onion_utils.rs | ||
| peer_channel_encryptor.rs | ||
| peer_handler.rs | ||
| reorg_tests.rs | ||
| wire.rs | ||