Arik Sosman [Fri, 20 May 2022 17:56:10 +0000 (10:56 -0700)]
Merge pull request #1456 from jkczyz/2022-04-effective-capacity
Use `EffectiveCapacity` in `Score` trait
Arik Sosman [Thu, 19 May 2022 17:07:35 +0000 (10:07 -0700)]
Fix rust beta docs lightning-invoice crate.
Elias Rohrer [Fri, 20 May 2022 15:17:29 +0000 (17:17 +0200)]
Use new spec repository URL.
Jeffrey Czyz [Wed, 27 Apr 2022 20:55:33 +0000 (15:55 -0500)]
Score without uncertainty for exact liquidity
For direct channels, the channel liquidity is known with certainty. Use
this knowledge in ProbabilisticScorer by either penalizing with the
per-hop penalty or u64::max_value depending on the amount.
Jeffrey Czyz [Fri, 22 Apr 2022 13:21:18 +0000 (08:21 -0500)]
Pass effective capacity to scorer
Scorers could benefit from having the channel's EffectiveCapacity rather
than a u64 msat value. For instance, ProbabilisticScorer can give a more
accurate penalty when given the ExactLiquidity variant. Pass a struct
wrapping the effective capacity, the proposed amount, and any in-flight
HTLC value.
Jeffrey Czyz [Tue, 17 May 2022 21:57:55 +0000 (16:57 -0500)]
Use correct penalty and CLTV delta in route hints
For route hints, the aggregate next hops path penalty and CLTV delta
should be computed after considering each hop rather than before.
Otherwise, these aggregate values will include values from the current
hop, too.
Jeffrey Czyz [Tue, 17 May 2022 21:43:36 +0000 (16:43 -0500)]
Use the correct amount when scoring route hints
When scoring route hints, the amount passed to the scorer should include
any fees needed for subsequent hops. This worked correctly for single-
hop hints since there are no further hops, but not for multi-hint hops
(except the final one).
Jeffrey Czyz [Sun, 23 Jan 2022 23:25:38 +0000 (17:25 -0600)]
Distinguish maximum HTLC from effective capacity
Using EffectiveCapacity in scoring gives more accurate success
probabilities when the maximum HTLC value is less than the channel
capacity. Change EffectiveCapacity to prefer the channel's capacity
over its maximum HTLC limit, but still use the latter for route finding.
Matt Corallo [Wed, 4 May 2022 17:49:09 +0000 (17:49 +0000)]
Store an `events::PaymentPurpose` with each claimable payment
In
fc77c57c3c6e165d26cb5c1f5d1afee0ecd02589 we stopped using the
`FInalOnionHopData` in `OnionPayload::Invoice` directly and intend
to remove it eventually. However, in the next few commits we need
access to the payment secret when claimaing a payment, as we create
a new `PaymentPurpose` during the claim process for a new event.
In order to get access to a `PaymentPurpose` without having access
to the `FinalOnionHopData` we here change the storage of
`claimable_htlcs` to store a single `PaymentPurpose` explicitly
with each set of claimable HTLCs.
Matt Corallo [Wed, 4 May 2022 16:29:29 +0000 (16:29 +0000)]
Enable removal of `OnionPayload::Invoice::_legacy_hop_data` later
In
fc77c57c3c6e165d26cb5c1f5d1afee0ecd02589 we stopped using the
`FinalOnionHopData` in `OnionPayload::Invoice` directly and renamed
it `_legacy_hop_data` with the intent of removing it in a few
versions. However, we continue to check that it was included in the
serialized data, meaning we would not be able to remove it without
breaking ability to serialize full `ChannelManager`s.
This fixes that by making the `_legacy_hop_data` an `Option` which
we will happily handle just fine if its `None`.
Jeffrey Czyz [Thu, 5 May 2022 21:19:40 +0000 (16:19 -0500)]
PathBuildingHop::value_contribution_msat in Debug
Matt Corallo [Wed, 18 May 2022 19:22:42 +0000 (19:22 +0000)]
Merge pull request #1476 from tnull/2022-05-maximum-path-length
Consider maximum path length during path finding.
Elias Rohrer [Wed, 18 May 2022 16:50:43 +0000 (18:50 +0200)]
Consider maximum path length during path finding.
Matt Corallo [Sun, 15 May 2022 19:13:43 +0000 (19:13 +0000)]
Randomize the `ConnectStyle` during tests
We have a bunch of fancy infrastructure to ensure we can connect
blocks using all our different connection interfaces, but we only
bother to use it in a few select tests.
This expands our use of `ConnectStyle` to most of our tests by
simply randomizing the style in each test. This makes our tests
non-deterministic, but we print the connection style at start so
that it's easy to reproduce a failure deterministically.
Matt Corallo [Sun, 15 May 2022 19:38:01 +0000 (19:38 +0000)]
Make tests more robust against different connection styles
In the next commit we'll randomize the `ConnectStyle` used in each
test. However, some tests are slightly too prescriptive, which we
address here in a few places.
Matt Corallo [Sun, 15 May 2022 19:03:45 +0000 (19:03 +0000)]
Add new block `ConnectionStyle`s for `transaction_unconfirmed`
Previously `transaction_unconfirmed` was never called in tests!
valentinewallace [Tue, 17 May 2022 20:10:09 +0000 (16:10 -0400)]
Merge pull request #1472 from TheBlueMatt/2022-06-less-secp-ctx
Pull secp256k1 contexts from per-peer to per-PeerManager
Matt Corallo [Tue, 17 May 2022 17:32:46 +0000 (17:32 +0000)]
Merge pull request #1418 from bruteforcecat/timeout-outbound-paymnet-retires-instead-of-count-out
add timeout retry strategy to outbound payment
KaFai Choi [Sat, 14 May 2022 02:52:38 +0000 (09:52 +0700)]
add timeout retry strategy to outbound payment
Matt Corallo [Mon, 16 May 2022 21:48:51 +0000 (21:48 +0000)]
Merge pull request #1485 from ViktorTigerstrom/2022-05-add-force-close-param
Add missing `counterparty_node_id` in `force_close_channel` calls
Viktor Tigerström [Mon, 16 May 2022 20:25:46 +0000 (22:25 +0200)]
Add missing `counterparty_node_id` in `force_close_channel` calls
Arik Sosman [Mon, 16 May 2022 19:44:16 +0000 (12:44 -0700)]
Merge pull request #1479 from ViktorTigerstrom/2022-05-pass-counterparty-id-to-functions
Pass `counterparty_node_id` to `ChannelManager` functions
valentinewallace [Mon, 16 May 2022 18:21:39 +0000 (14:21 -0400)]
Merge pull request #1475 from atalw/2022-04-paymentforwarded-event
Expose `next_channel_id` in `PaymentForwarded` event
Matt Corallo [Sun, 15 May 2022 18:47:32 +0000 (18:47 +0000)]
Store full blocks in the test blockchain tracker instead of headers
atalw [Fri, 22 Apr 2022 07:03:18 +0000 (12:33 +0530)]
Add `next_channel_id` in `PaymentForwarded` event
This update also includes a minor refactor. The return type of
`pending_monitor_events` has been changed to a `Vec` tuple with the
`OutPoint` type. This associates a `Vec` of `MonitorEvent`s with a
funding outpoint.
We've also renamed `source/sink_channel_id` to `prev/next_channel_id` in
the favour of clarity.
Matt Corallo [Sat, 14 May 2022 19:35:47 +0000 (19:35 +0000)]
Merge pull request #1429 from TheBlueMatt/2022-04-drop-no-conn-possible
Viktor Tigerström [Fri, 13 May 2022 21:52:20 +0000 (23:52 +0200)]
Update `OpenChannelRequest` documentation
As the `counterparty_node_id` is now required to be passed back to the
`ChannelManager` to accept or reject an inbound channel request, the
documentation is updated to reflect that.
Viktor Tigerström [Thu, 12 May 2022 22:13:39 +0000 (00:13 +0200)]
Pass `counterparty_node_id` to `accept_inbound_channel`
Viktor Tigerström [Thu, 12 May 2022 21:59:41 +0000 (23:59 +0200)]
Pass `counterparty_node_id` to `funding_transaction_generated`
Viktor Tigerström [Thu, 12 May 2022 21:26:32 +0000 (23:26 +0200)]
Pass `counterparty_node_id` to `force_close_channel`
Viktor Tigerström [Thu, 12 May 2022 20:31:29 +0000 (22:31 +0200)]
Pass `counterparty_node_id` to `close_channel` functions
KaFai Choi [Mon, 18 Apr 2022 03:32:13 +0000 (10:32 +0700)]
move Time trait from scoring mod to util::time and set it visibile within crate
Viktor Tigerström [Fri, 13 May 2022 21:43:25 +0000 (23:43 +0200)]
Add `counterparty_node_id` to `FundingGenerationReady`
Jeffrey Czyz [Fri, 13 May 2022 17:20:56 +0000 (12:20 -0500)]
Merge pull request #1480 from tnull/2022-05-fix-test-warnings
Fix unused code warnings test.
Elias Rohrer [Fri, 13 May 2022 16:03:51 +0000 (18:03 +0200)]
Fix unused code warnings.
Matt Corallo [Mon, 9 May 2022 23:03:50 +0000 (23:03 +0000)]
Pull secp256k1 contexts from per-peer to per-PeerManager
Instead of including a `Secp256k1` context per
`PeerChannelEncryptor`, which is relatively expensive memory-wise
and nontrivial CPU-wise to construct, we should keep one for all
peers and simply reuse it.
This is relatively trivial so we do so in this commit.
Since its trivial to do so, we also take this opportunity to
randomize the new PeerManager context.
Matt Corallo [Wed, 11 May 2022 17:24:16 +0000 (17:24 +0000)]
Merge pull request #1023 from TheBlueMatt/2021-07-par-gossip-processing
Matt Corallo [Wed, 11 May 2022 16:12:15 +0000 (16:12 +0000)]
Merge pull request #1477 from dunxen/2022-05-invoice-expiry-nits
Duncan Dean [Wed, 11 May 2022 08:57:38 +0000 (10:57 +0200)]
Address post-ACK formatting nits from #1474
Matt Corallo [Tue, 12 Apr 2022 19:19:00 +0000 (19:19 +0000)]
Add a few more simple tests of the PeerHandler
These increase coverage and caught previous lockorder inversions.
Matt Corallo [Tue, 12 Apr 2022 19:16:38 +0000 (19:16 +0000)]
Add support for testing recvd messages in TestChannelMessageHandler
Matt Corallo [Tue, 12 Apr 2022 19:05:15 +0000 (19:05 +0000)]
Require `PartialEq` for `wire::Message` in `cfg(test)`
...and implement wire::Type for `()` for `feature = "_test_utils"`.
Matt Corallo [Mon, 11 Apr 2022 17:34:11 +0000 (17:34 +0000)]
Drop a needless match in favor of an `if let`
Matt Corallo [Tue, 22 Mar 2022 21:03:41 +0000 (21:03 +0000)]
[net-tokio] Explicitly yield after processing messages from a peer
This reduces instances of disconnect peers after single timer
intervals somewhat, at least on Tokio 1.14.
Matt Corallo [Fri, 25 Feb 2022 21:57:57 +0000 (21:57 +0000)]
Drop `PeerHolder` as it now only has one field
Matt Corallo [Mon, 11 Oct 2021 05:03:45 +0000 (05:03 +0000)]
Keep the same read buffer unless the last message was overly large
This avoids repeatedly deallocating-allocating a Vec for the peer
read buffer after every message/header.
Matt Corallo [Wed, 6 Oct 2021 16:58:56 +0000 (16:58 +0000)]
Create a simple `FairRwLock` to avoid readers starving writers
Because we handle messages (which can take some time, persisting
things to disk or validating cryptographic signatures) with the
top-level read lock, but require the top-level write lock to
connect new peers or handle disconnection, we are particularly
sensitive to writer starvation issues.
Rust's libstd RwLock does not provide any fairness guarantees,
using whatever the OS provides as-is. On Linux, pthreads defaults
to starving writers, which Rust's RwLock exposes to us (without
any configurability).
Here we work around that issue by blocking readers if there are
pending writers, optimizing for readable code over
perfectly-optimized blocking.
Matt Corallo [Sun, 3 Oct 2021 21:44:52 +0000 (21:44 +0000)]
Wake reader future when we fail to flush socket buffer
This avoids any extra calls to `read_event` after a write fails to
flush the write buffer fully, as is required by the PeerManager
API (though it isn't critical).
Matt Corallo [Wed, 6 Oct 2021 04:45:07 +0000 (04:45 +0000)]
Limit blocked PeerManager::process_events waiters to two
Only one instance of PeerManager::process_events can run at a time,
and each run always finishes all available work before returning.
Thus, having several threads blocked on the process_events lock
doesn't accomplish anything but blocking more threads.
Here we limit the number of blocked calls on process_events to two
- one processing events and one blocked at the top which will
process all available events after the first completes.
Matt Corallo [Wed, 6 Oct 2021 06:10:01 +0000 (06:10 +0000)]
Avoid the peers write lock unless we need it in timer_tick_occurred
Similar to the previous commit, this avoids "blocking the world" on
every timer tick unless we need to disconnect peers.
Matt Corallo [Sat, 25 Sep 2021 22:24:23 +0000 (22:24 +0000)]
Avoid taking the peers write lock during event processing
Because the peers write lock "blocks the world", and happens after
each read event, always taking the write lock has pretty severe
impacts on parallelism. Instead, here, we only take the global
write lock if we have to disconnect a peer.
Matt Corallo [Wed, 6 Oct 2021 04:29:19 +0000 (04:29 +0000)]
[net-tokio] Call PeerManager::process_events without blocking reads
Unlike very ancient versions of lightning-net-tokio, this does not
rely on a single global process_events future, but instead has one
per connection. This could still cause significant contention, so
we'll ensure only two process_events calls can exist at once in
the next few commits.
Matt Corallo [Wed, 6 Oct 2021 06:58:15 +0000 (06:58 +0000)]
Process messages with only the top-level read lock held
Users are required to only ever call `read_event` serially
per-peer, thus we actually don't need any locks while we're
processing messages - we can only be processing messages in one
thread per-peer.
That said, we do need to ensure that another thread doesn't
disconnect the peer we're processing messages for, as that could
result in a peer_disconencted call while we're processing a
message for the same peer - somewhat nonsensical.
This significantly improves parallelism especially during gossip
processing as it avoids waiting on the entire set of individual
peer locks to forward a gossip message while several other threads
are validating gossip messages with their individual peer locks
held.
Matt Corallo [Fri, 30 Jul 2021 18:03:28 +0000 (18:03 +0000)]
Process messages from peers in parallel in `PeerManager`.
This adds the required locking to process messages from different
peers simultaneously in `PeerManager`. Note that channel messages
are still processed under a global lock in `ChannelManager`, and
most work is still processed under a global lock in gossip message
handling, but parallelizing message deserialization and message
decryption is somewhat helpful.
Matt Corallo [Tue, 10 May 2022 23:23:57 +0000 (23:23 +0000)]
Merge pull request #1474 from dunxen/2022-05-actually-add-expiry
lightning-invoice/utils: Actually add expiry to invoices
Duncan Dean [Tue, 10 May 2022 17:01:15 +0000 (19:01 +0200)]
Add expiry to non-phantom invoice utils
Duncan Dean [Tue, 10 May 2022 16:56:02 +0000 (18:56 +0200)]
Actually add expiry to phantom invoice utils
Matt Corallo [Mon, 9 May 2022 19:11:56 +0000 (19:11 +0000)]
Merge pull request #1465 from tnull/2022-05-encode-update-type-bytes
Encode & test `channel_update` message type in failure messages.
Matt Corallo [Mon, 9 May 2022 16:29:57 +0000 (16:29 +0000)]
Merge pull request #1471 from ViktorTigerstrom/2022-05-test-disconnected-before-funding-broadcasted
Add test coverage for `ClosureReason::DisconnectedPeer`
valentinewallace [Mon, 9 May 2022 16:09:52 +0000 (12:09 -0400)]
Merge pull request #1467 from arik-so/fuzz_new_target_docs
Add documentation for creating new fuzz test targets.
Viktor Tigerström [Sun, 8 May 2022 21:45:08 +0000 (23:45 +0200)]
Add test for `ClosureReason::DisconnectedPeer`
Add test that ensures that channels are closed with
`ClosureReason::DisconnectedPeer` if the peer disconnects before the
funding transaction has been broadcasted.
Elias Rohrer [Fri, 6 May 2022 17:46:49 +0000 (19:46 +0200)]
Encode channel update type in failure messages.
Jeffrey Czyz [Thu, 5 May 2022 19:08:16 +0000 (14:08 -0500)]
Merge pull request #1389 from lightning-signer/2022-03-bitcoin
Update bitcoin crate to 0.28.1
Arik Sosman [Thu, 5 May 2022 00:34:35 +0000 (17:34 -0700)]
Add documentation for creating new fuzz test targets.
Devrandom [Thu, 5 May 2022 16:04:55 +0000 (18:04 +0200)]
Improve ShutdownScript::new_witness_program
Devrandom [Thu, 5 May 2022 15:59:38 +0000 (17:59 +0200)]
bitcoin crate 0.28.1
Jeffrey Czyz [Thu, 5 May 2022 13:26:59 +0000 (08:26 -0500)]
Merge pull request #1468 from johnpc/fix-contributing-typo
fix typos in CONTRIBUTING.md
John Corser [Thu, 5 May 2022 01:35:50 +0000 (18:35 -0700)]
fix typos in CONTRIBUTING.md
valentinewallace [Thu, 5 May 2022 00:36:03 +0000 (20:36 -0400)]
Merge pull request #1463 from TheBlueMatt/2022-05-lol-more-underflow
Reject outbound channels if the total reserve is larger than funding
Matt Corallo [Wed, 4 May 2022 20:29:38 +0000 (20:29 +0000)]
Merge pull request #1449 from TheBlueMatt/2022-04-fix-remote_ip_race
[lightning-net-tokio] Fix race-y unwrap fetching peer socket address
Matt Corallo [Wed, 4 May 2022 18:48:19 +0000 (18:48 +0000)]
Merge pull request #1430 from vincenzopalazzo/macros/channel_reestablish_v2
send warning when we receive a old commitment transaction
Jeffrey Czyz [Wed, 4 May 2022 13:28:06 +0000 (08:28 -0500)]
Merge pull request #1416 from jurvis/jurvis/persist-scorer
Add utils to persist scorer in BackgroundProcessor
Vincenzo Palazzo [Wed, 4 May 2022 07:23:05 +0000 (09:23 +0200)]
send warning when we receive a old commitment transaction
During a `channel_reestablish` now we send a warning message when we receive a old commitment transaction from the peer.
In addition, this commit include the update of functional test to make sure that the receiver will generate warn messages.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
valentinewallace [Wed, 4 May 2022 00:44:42 +0000 (20:44 -0400)]
Merge pull request #1461 from TheBlueMatt/2022-05-unconf-0-not-half
Force-close channels on reorg only if the funding is unconfirmed
Matt Corallo [Tue, 3 May 2022 22:44:26 +0000 (22:44 +0000)]
Merge pull request #1444 from ViktorTigerstrom/2022-04-use-counterparty-htlc-max-for-chan-updates
Set `ChannelUpdate` `htlc_maximum_msat` using the peer's value
Jurvis Tan [Tue, 3 May 2022 22:29:11 +0000 (15:29 -0700)]
Set last_prune_call outside of persistence block
Jurvis Tan [Thu, 28 Apr 2022 05:16:38 +0000 (22:16 -0700)]
Add utils to persist scorer in BackgroundProcessor
move last_prune_call back
Viktor Tigerström [Tue, 26 Apr 2022 22:43:06 +0000 (00:43 +0200)]
Add correct `ChannelUpdate` `htlc_maximum_msat` test
Viktor Tigerström [Thu, 21 Apr 2022 22:02:27 +0000 (00:02 +0200)]
Set `ChannelUpdate` `htlc_maximum_msat` using the peer's value
Use the `counterparty_max_htlc_value_in_flight_msat` value, and not the
`holder_max_htlc_value_in_flight_msat` value when creating the
`htlc_maximum_msat` value for `ChannelUpdate` messages.
BOLT 7 specifies that the field MUST be less than or equal to
`max_htlc_value_in_flight_msat` received from the peer, which we
currently are not guaranteed to adhere to by using the holder value.
Viktor Tigerström [Tue, 26 Apr 2022 22:39:52 +0000 (00:39 +0200)]
Add test for configurable in-flight limit
Viktor Tigerström [Tue, 26 Apr 2022 22:37:45 +0000 (00:37 +0200)]
Make our in-flight limit percentage configurable
Add a config field
`ChannelHandshakeConfig::max_inbound_htlc_value_in_flight_percent_of_channel`
which sets the percentage of the channel value we cap the total value of
outstanding inbound HTLCs to.
This field can be set to a value between 1-100, where the value
corresponds to the percent of the channel value in whole percentages.
Note that:
* If configured to another value than the default value 10, any new
channels created with the non default value will cause versions of LDK
prior to 0.0.104 to refuse to read the `ChannelManager`.
* This caps the total value for inbound HTLCs in-flight only, and
there's currently no way to configure the cap for the total value of
outbound HTLCs in-flight.
* The requirements for your node being online to ensure the safety of
HTLC-encumbered funds are different from the non-HTLC-encumbered funds.
This makes this an important knob to restrict exposure to loss due to
being offline for too long. See
`ChannelHandshakeConfig::our_to_self_delay` and
`ChannelConfig::cltv_expiry_delta` for more information.
Default value: 10.
Minimum value: 1, any values less than 1 will be treated as 1 instead.
Maximum value: 100, any values larger than 100 will be treated as 100
instead.
Matt Corallo [Tue, 3 May 2022 19:16:29 +0000 (19:16 +0000)]
Merge pull request #1452 from tnull/2022-04-honor-gossip-timestamp-filters
Initiate gossip sync only after receiving GossipTimestampFilter.
Matt Corallo [Mon, 2 May 2022 15:07:20 +0000 (15:07 +0000)]
Tweak `test_unconf_chan` to test that we don't prematurely close
Matt Corallo [Tue, 3 May 2022 16:53:10 +0000 (16:53 +0000)]
Merge pull request #1460 from TheBlueMatt/2022-04-liquidity-log
Provide a utility to log the ProbabilisticScorer's contents
Elias Rohrer [Tue, 3 May 2022 07:13:09 +0000 (09:13 +0200)]
Initiate sync only after receiving `GossipTimestampFilter`.
Matt Corallo [Mon, 2 May 2022 20:45:17 +0000 (20:45 +0000)]
Reject outbound channels if the total reserve is larger than funding
In
2826af75a5761859dedcddc870de0753ae4ecde4 we fixed a fuzz crash
in which the total reserve values in a channel were greater than
the funding amount, checked when an incoming channel is accepted.
This, however, did not fix the same issue for outbound channels,
where a peer can accept a channel with a nonsense reserve value in
the `accept_channel` message. The `full_stack_target` fuzzer
eventually found its way into the same issue, which this resolves.
Thanks (again) to Chaincode Labs for providing the fuzzing
resources which found this bug!
Matt Corallo [Mon, 2 May 2022 20:21:44 +0000 (20:21 +0000)]
Merge pull request #1447 from andozw/seana.
20220422.avoid-storing-FinalOnionHopData
Avoid storing a full FinalOnionHopData in OnionPayload::Invoice
Matt Corallo [Thu, 28 Apr 2022 22:32:52 +0000 (22:32 +0000)]
Provide a utility to log the ProbabilisticScorer's contents
I wrote this when debugging a user's scorer and figured it may be
useful upstream.
Matt Corallo [Thu, 28 Apr 2022 17:10:04 +0000 (10:10 -0700)]
Avoid storing a full FinalOnionHopData in OnionPayload::Invoice
We only use it to check the amount when processing MPP parts, but
store the full object (including new payment metadata) in it.
Because we now store the amount in the parent structure, there is
no need for it at all in the `OnionPayload`. Sadly, for
serialization compatibility, we need it to continue to exist, at
least temporarily, but we can avoid populating the new fields in
that case.
Matt Corallo [Tue, 21 Dec 2021 22:10:43 +0000 (22:10 +0000)]
Store total payment amount in ClaimableHTLC explicitly
...instead of accessing it via the `OnionPayload::Invoice` form.
This may be useful if we add MPP keysend support, but is directly
useful to allow us to drop `FinalOnionHopData` from `OnionPayload`.
Matt Corallo [Tue, 21 Dec 2021 20:21:34 +0000 (20:21 +0000)]
Pass FinalOnionHopData to payment verify by reference, not clone
Matt Corallo [Mon, 25 Apr 2022 18:39:28 +0000 (18:39 +0000)]
Add a test for socket connection races
Sadly this does not reproduce the issue fixed in the previous
commit.
Matt Corallo [Mon, 2 May 2022 02:51:50 +0000 (02:51 +0000)]
Force-close channels on reorg only if the funding is unconfirmed
Currently, if a channel's funding is locked in and then later
reorg'd back to half of the channel's minimum-depth we will
immediately force-close the channel. However, this can happen at
the fork-point while processing a reorg, and generally reorgs do
not reduce the block height at all, making this a rather useless
endeavor.
Ideally we'd never auto-force-close channels at all due to a reorg,
instead simply marking it as inactive until the funding
transaction is re-confirmed (or allowing the user to attempt to
force-close or force-closing once we're confident we have
completed reorg processing if we're at risk of losing funds
already received in the channel).
Sadly, we currently do not support changing a channel's SCID and
updating our SCID maps, so we cannot yet remove the automated
force-close logic. Still, there is no reason to do it until a
funding transaction has been removed from the chain.
This implements that change - only force-closeing once a channel's
funding transaction has been reorg'd out (still potentially at a
reorg's fork point). This continues to imply a 1-confirmation
channel will always be force-closed after a reorg of the funding
transaction, and will imply a similar behavior with 0-conf
channels.
Matt Corallo [Fri, 29 Apr 2022 19:50:37 +0000 (19:50 +0000)]
Merge pull request #1451 from TheBlueMatt/2022-04-moar-mpp-fail-test
Add test coverage for failure of inconsistent MPP parts
Matt Corallo [Thu, 28 Apr 2022 21:56:49 +0000 (21:56 +0000)]
Merge pull request #1454 from TheBlueMatt/2022-04-fuzz-underflow
Reject channels if the total reserves are larger than the funding
Matt Corallo [Thu, 28 Apr 2022 21:14:19 +0000 (21:14 +0000)]
Merge pull request #1425 from valentinewallace/2021-04-wumbo
Wumbo!
Matt Corallo [Thu, 28 Apr 2022 19:46:22 +0000 (19:46 +0000)]
Correct error when a peer opens a channel with a huge push_msat
The calculation uses the reserve, so we should mention it in the
error we send to our peers.
Matt Corallo [Thu, 28 Apr 2022 19:46:13 +0000 (19:46 +0000)]
Reject channels if the total reserves are larger than the funding
The `full_stack_target` fuzzer managed to find a subtraction
underflow in the new `Channel::get_htlc_maximum` function where we
subtract both sides' reserve values from the channel funding. Such
a channel is obviously completely useless, so we should reject it
during opening instead of integer-underflowing later.
Thanks to Chaincode Labs for providing the fuzzing resources which
found this bug!
Valentine Wallace [Fri, 15 Apr 2022 22:10:39 +0000 (18:10 -0400)]
Enable wumbo channels to be created
Also redefine MAX_FUNDING_SATOSHIS_NO_WUMBO to no longer be off-by-one.
Valentine Wallace [Fri, 15 Apr 2022 21:34:59 +0000 (17:34 -0400)]
config: add max_funding_satoshis to enforce for inbound channels
and a bonus grammar fix