Matt Corallo [Tue, 24 Dec 2019 20:52:47 +0000 (15:52 -0500)]
Flatten OnionHopData struct with the Realm0 struct.
Previously OnionHopData contained a OnionRealm0HopData field however
instead of bumping the realm number, it has been replaced with a
length, used to indicte the length of a TLV-formatted object.
Because a TLV-formatted hop data can contain the same information as
a realm-0 hop data, we flatten the field and simply keep track of
what format it was in.
Matt Corallo [Wed, 22 Jan 2020 23:31:57 +0000 (18:31 -0500)]
Clean up documentation around spendable outputs significantly.
* Fixed a number of grammar issues
* Clarified the docs for users who are intimately farmiliar with
arbitrary lines of text copied from the BOLTs
* Added a bit more text so that things are easier to read and less
disjoint.
* Clarified exactly how the witness stack should look since I had
to go dig for it.
Update ChannelManager's ChannelMonitor Arc to be a Deref
Additional changes:
* Update fuzz crate to match ChannelManager's new API
* Update lightning-net-tokio library to match ChannelManager's new ChannelMonitor Deref API
* Update tests to match ChannelManager's new ChannelMonitor Deref API
Matt Corallo [Sat, 28 Dec 2019 06:10:14 +0000 (01:10 -0500)]
Pass node features through to RouteHops
This exposes the latest Init-context features in the ChannelDetails
passed to the Router during route calculation, which combines those
with the Node-context features tracked from node_announcements to
provide the latest Node-context features in RouteHop structs.
Fields are also added for Channel-context features, though those are
only partially used since no such features are defined today anyway.
These will be useful when determining whether to use new
TLV-formatted onion hop datas when generating onions for peers.
Matt Corallo [Sun, 29 Dec 2019 19:22:43 +0000 (14:22 -0500)]
Keep track of the Init Features for every connected/channel'd peer
Since we want to keep track of the Init-context features for every
peer we have channels with, we have to keep them for as long as the
peer is connected (since we may open a channel with them at any
point).
We go ahead and take this opportunity to create a new per-peer-state
struct which has two levels of mutexes which is appropriate for
moving channel storage to.
Since we can't process messages from a given peer in parallel, the
inner lock is a regular mutex, but the outer lock is RW so that we
can process for different peers at the same time with an outer read
lock.
Antoine Riard [Tue, 14 Jan 2020 18:47:01 +0000 (13:47 -0500)]
Bound incoming HTLC witnessScript to min/max limits
Fix a crash where previously we weren't able to detect any accepted
HTLC if its witness-encoded cltv expiry was different from expected
ACCEPTED_HTLC_SCRIPT_WEIGHT. This should work for any cltv expiry
included between 0 and 16777216 on mainnet, testnet and regtest.
Matt Corallo [Mon, 13 Jan 2020 18:43:54 +0000 (13:43 -0500)]
Fix crash when a claim tx has some non-witness inputs.
The logger which decides what to refer to an on-chain claim tx was
assuming that all inputs would have a witness. While this was fine
for the one-input case, it broke the fuzzer which was connecting a
consensus-invalid transaction. Further, in the case we have multiple
inputs, some may not have a witness, which we shouldn't crash on.
Jeffrey Czyz [Thu, 16 Jan 2020 18:48:16 +0000 (10:48 -0800)]
Remove unnecessary borrow_parts() methods
Accessing a struct through an std::syn::MutexGuard using implicit
dereferencing can confuse the borrow checker. This situation arises when
obtaining mutable references to more than one field of the struct, which
is normally allowed.
However, when using implicit dereferencing, a mutable reference to the
the entire struct is taken. Thus, attempting to access another field in
this manner will lead to a compilation error.
https://doc.rust-lang.org/error-index.html#E0499
A simple way to avoid this is to first obtain a mutable reference to the
struct using explicit dereferencing.
Matt Corallo [Mon, 13 Jan 2020 18:52:23 +0000 (13:52 -0500)]
Refactor features a bit more to describe what the constructors do
The Features::new() method is nonsense and doesn't describe what
features were being set - we introduce an empty() and supported()
constructors instead.
Matt Corallo [Mon, 13 Jan 2020 18:50:29 +0000 (13:50 -0500)]
Fix Feature endianness by swapping bytes on read/write.
The spec is a bit mum on feature endianness, so I suppose it falls
under the "everything is big endian unless otherwise specified"
clause, but we were treating it as little.
This change was made in the flat features BOLT PR, as if a channel
requires some unknown feature bits we should still rumor it, we just
shouldn't route through it.
Matt Corallo [Mon, 23 Dec 2019 22:52:58 +0000 (17:52 -0500)]
Implement Flat Features
This merges local and global features into one struct, which is
parameterized by where it appers. The parameterization restricts
which queries can be made and which features can be set, in line
with the latest BOLT 9.
Antoine Riard [Tue, 5 Nov 2019 23:51:05 +0000 (18:51 -0500)]
Drop Result for ChannelMessageHandler methods
Simplify interfaces between ChannelMessageHandler and PeerManager,
by switching all ChannelMessageHandler errors to HandleError sent
internally instead of being return. With further refactors in Router
and PeerChannelEncryptor, errors management on the PeerManager-side
won't be splitted between try_potential_handleerror and HandleError
processing.
Inside ChannelManager, we now log MsgHandleErrInternal and send
ErrorAction to PeerManager.
On a high-level, it should allow client using API to be more flexible
by polling events instead of waiting function call returns.
We also update handle_error macro to take channel_state_lock from
caller which should avoid some deadlock potential for some edges
cases.
Filter out IgnoreError in handle_error macro, update test in
consequence.
Matt Corallo [Fri, 13 Dec 2019 03:42:08 +0000 (22:42 -0500)]
Drop duplicative current-local-tx storage in channel.
We now have current-local-tx broadcast ability in channel monitors
directly (for ChannelManager deserialization), so we can just use
that instead of always having the Channel store signed ready-to-go
copies of the latest local commitment transaction.
This is further kinda nice since ChannelMonitor is live and can, eg
broadcast HTLC-Success transactions immediately as they will be
generated at broadcast time instead of in advance.
Finally, this lets us clean up a tiny bit in Channel.
Matt Corallo [Fri, 20 Dec 2019 19:53:16 +0000 (14:53 -0500)]
Remove unused lifetimes.
f71518365f61a5fe2a0340953ad6592c0d2b72cc added a series of lifetimes
which were required for an earlier version of the patch but not the
final version. They can be freely removed.
Matt Corallo [Wed, 27 Nov 2019 21:08:48 +0000 (16:08 -0500)]
Make commitment transaction signing a part of ChannelKeys.
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Matt Corallo [Tue, 26 Nov 2019 21:46:33 +0000 (16:46 -0500)]
Make ChannelKeys an API and template Channel with it.
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
Antoine Riard [Tue, 10 Dec 2019 22:25:27 +0000 (17:25 -0500)]
Add test_bump_txn_sanitize_tracking_maps
Extend test visibility of claim-tracking maps to do so.
Cover both "If 2 claimable-outpoint-spending txn are in 1 block,
clean up properly" and "Clean up claimable_outpoints when
pending_claim_requests is cleaned" fix commits in same patchset.
Matt Corallo [Tue, 10 Dec 2019 03:51:36 +0000 (22:51 -0500)]
Clean up claimable_outpoints when pending_claim_requests is cleaned
When claimable_outpoints was introduced in "Move
our_claim_txn_waiting_first_conf to pending_claim_requests", removal
of elements from it (which are just pointers into
pending_claim_requests) was never added.
Matt Corallo [Tue, 10 Dec 2019 03:14:47 +0000 (22:14 -0500)]
Correct input comparison for input-subset RBF bump creation
This resolves a regression introduced in "Implement bumping engine in
ChannelMonitor::block_connected" in which not all inputs are checked.
Several opportunities to clarify and clean up comments are also taken.
Fix test_bump_penalty_txn_on_revoked_htlcs as now remote claim txn
build the same way than us are going to be register as cleaning
pending_claim_request after ANTI_REORG_DELAY. It means during this
delay we are going to generate invalid bumped claiming txn on
already claimed outpoints. Previously these txn weren't issued
because all their outpoints would have been removed.
Fix full_stack_target by adding more input for FuzzEstimator
Antoine Riard [Mon, 9 Dec 2019 21:59:08 +0000 (16:59 -0500)]
Track and react to remote partial-claiming of pending claim request
A pending claim request may contain a set of multiple outpoints.
If one or multiple of them get claimed by remote party, our in-flight
claiming transactions aren't valid anymore so we need to react
quickly and regenerate claiming transaction with accurate set.
However, a claimed outpoint may be disconnected and we need to resurrect
back outpoint among set of orignal pending claim request.
To guarantee consistency of contentious claimed outpoint we cache it
as OnchainEvent::ContentionsOutpoint and only delete it after
ANTI_REORG_DELAY.
Fix test broken by change, partial claiming on revoked txn
force us to regenerate txn
Antoine Riard [Tue, 2 Jul 2019 19:52:58 +0000 (15:52 -0400)]
Implement bumping engine in ChannelMonitor::block_connected
Add RBF-bumping of justice txn, given they are only signed by us we
can RBF at wish.
Aggregation of bump-candidates and more aggresive bumping heuristics
are left open
Fix tests broken by introduction of more txn broadcast.
Some tests may have a relaxed check (claim_htlc_ouputs_single_tx)
as broadcast bumped txn are now interwining in previous broadcast ones
and breaking simple expectations
Use bumping engine to rebuild claiming transaction in case of partial-
claim of its outpoints set.
Antoine Riard [Tue, 10 Dec 2019 03:18:41 +0000 (22:18 -0500)]
Remove superflous pending_claims
As local onchain txn are already monitored in block_connected by
check_spend_local_transaction, it's useless to generate twice
pending claims for HTLC outputs on local commitment tx.
Antoine Riard [Tue, 10 Dec 2019 03:18:20 +0000 (22:18 -0500)]
Move our_claim_txn_waiting_first_conf to pending_claim_requests
Add claimable_outpoints maps.
Both structures are tied and should ensure their mutual consistency.
Pending_claim_requests is cached by original claim txid. Medatada
and per input material should be constant between bumped transactions,
only change should be partial-claiming of outpoints set and block
reorgs.
Due to RBF rules, if an input has been part of an aggregate tx
at first claim try, if we want the bumped tx to land nicely
in the mempool, inputs should be distributed in multiple
bumped tx but still be aggregate in a new bumped tx.