Upon deserialization/reload we need to be able to register each
outpoint which spends the commitment txo which a channelmonitor
believes to be on chain. While our other internal tracking is
likely sufficient to regenerate these, its much easier to simply
track all outpouts we've ever generated, so we do that here.
Previously, if new ouputs were found to be watched as part
of channel operations, the block was rescan which triggers
again parser and generation of transactions already issued.
This commit first modifies the test framework without
altering further ChannelMonitor.
ChannelMonitor refactoring is introduced in a latter commit.
This implements the new TLV variable-length encoding for onion hop
data, opting to send it if the RouteHop's node_features indicates
support. It also uses the new process_inline method in ChaCha20 to
optimize a few things (though it grows a new TODO for a
probably-important optimization).
There's quite a bit of machinery included here, but it neatly
avoids any dynamic allocation during TLV deserialization, and the
calling side looks nice and simple. The macro-generated code is
pretty nice, though has some redundant if statements (I haven't
checked if they get optimized out yet, but I can't imagine they
don't).
This adds a number of new stream adapters to track and/or calculate
the number of bytes read/written to an underlying stream, as well
as wrappers for the two (?!) variable-length integer types that TLV
introduces.
This prepares for variable-length per-hop-data by wrapping the full
hop_data field in a decrypting stream, with a few minor
optimizations and redundant allocations to boot.
This, as it should be, restricts OnionHopData to only being able to
represent valid states, while still allowing for tests to generate
bogus hop data fields to test deserialization.
Its a bit awkward to have an hmac field covering the struct that
its in, and there is little difference in removing it, so just pull
it out and use a [u8; 32] where we care about the hmac.
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.
We previously tracked funding transaction confirmation by marking
funding_tx_confirmations to 1 when we see it in a block and
incrementing each block thereafter if its non-0. To avoid
double-incrementing the first confirmation, we did the increment
(and funding_locked check) after doing the first-confirmation
checks. Thus, we'd never hit the funding_locked case during the
first confirmation.
To address this, we simply swap the order of the checks, though
bumping the funding_tx_confirmations increment up to the top.
Reported-by: Igor Cota <igor@codexapertus.com>
PeerManager determines whether the initial_routing_sync feature bit
should be set when sending Init messages to peers. Move this to the
Router as it is better able to determine if a full sync is needed.
If our counterparty burns their funds by revoking their current
commitment transaction before we've sent them a new one, we'll step
forward the remote commitment number. This would be otherwise fine
(and may even encourage them to broadcast their revoked state(s) on
chain), except that our new EnforcingChannelKeys expects us to not
jump forward in time. Since it isn't too important that we punish
our counterparty in such a corner-case, we opt to just close the
channel in such a case and move on.
Create a MessageType abstraction and use it throughout the wire module's
external interfaces. Include an is_even method for clients to determine
how to handle unknown messages.
