Matt Corallo a12d37e063 Drop return value from fail_htlc_backwards, clarify docs ... `ChannelManager::fail_htlc_backwards`' bool return value is quite confusing - just because it returns false doesn't mean the payment wasn't (already) failed. Worse, in some race cases around shutdown where a payment was claimed before an unclean shutdown and then retried on startup, `fail_htlc_backwards` could return true even though (a duplicate copy of the same payment) was claimed, but the claim event has not been seen by the user yet. While its possible to use it correctly, its somewhat confusing to have a return value at all, and definitely lends itself to misuse. Instead, we should push users towards a model where they don't care if `fail_htlc_backwards` succeeds - either they've locally marked the payment as failed (prior to seeing any `PaymentReceived` events) and will fail any attempts to pay it, or they have not and the payment is still receivable until its timeout time is reached. We can revisit this decision based on user feedback, but will need to very carefully document the potential failure modes here if we do.		2022-05-28 00:02:49 +00:00
..
src	Drop return value from fail_htlc_backwards, clarify docs	2022-05-28 00:02:49 +00:00
Cargo.toml	bitcoin crate 0.28.1	2022-05-05 18:04:42 +02:00