We no longer have any public `Option<Signatures>` in our code, and
thus get warnings that the two functions which support it are
unused. Instead of removing support for them (which we may need in
the future), we add `#[allow(unused)]`.
If you try to call take_ptr on a pointer to an object which
implements Deref, rustc hits the deref recursion limit.
To avoid this, we can explicitly tell rustc that we want to treat
the pointer as a pointer and call take_ptr on it directly.
Previously, types which were declared and used in the same file
would fail if the use was before the declaration. This makes sense
in a few cases where a "parent" class returns a reference to a
"child" class and there's no reason we shouldn't support it.
This change adds a second pass to our file processing which gathers
the structs and enums whicha re declared in the file and adds them
to the type resolver first, before doing the real conversion.
`CommitmentTransaction::new_with_auxiliary_htlc_data()` includes a
unbounded generic parameter which we can't concretize and it's of
limited immediate use for users in any case. We should eventually
add a non-generic version which uses `()` for the generic but that
can come later.
`CommitmentTransaction::htlcs()` returns a reference to a Vec,
which we cannot currently map. It should, however, be exposed to
users, so in the future we'll need to have a duplication function
which returns Vec of references or a cloned Vec.
Instead of having manually-written lightning-specific code in a
supertrait walk in the middle of a large function, move it to a
utility function up next to the other manually-written-impl-block
functions.
This is a rather trivial cleanup to ensure we always have the full
path when we walk supertraits even if the supertrait is specified
with only a single ident.
In the case that we return an associated type to C (ie when
implementing a trait which returns an associated type, we had to
convert the Rust-returned concrete Rust type to the C trait struct),
we had code to manually create the neccessary trait struct at the
return site.
This was special-cased in the method-body-writing function instead
of letting the type conversion logic handle it. As a result, we are
unable to do the same conversion when it appears in a different
context, for example inside of a generic like
`Result<Self::AssocType, ErrorType>`.
To solve this, we do the actual work in a
`impl From<nativeType> for CTraitStruct` implementation and then
call `into()` from within the type conversion logic.
Instead of handling associated types separately, we can just shove
them into the same generics resolution logic we use for template
types. While we should probably have some precedence logic,
aliasing type names seems like a bad idea anyway so no effort is
made to handle it.
This removes a good chunk of code and, more importantly, tees us up
for supporting `Type<Self::AssociatedType>`-style generics.
Our bindings generator is braindead with respect to the idents
used in a trait definition - it treats them as if they were used
where the trait is being used, instead of where the trait is
defined. Thus, if the idents used in a trait definition are not
also imported the same in the files where the traits are used, we
will claim the idents are bogus.
I spent some time trying to track the TypeResolvers globally
through the entire conversion run so that we could use the original
file's TypeResolver later when using the trait, but it is somewhat
of a lifetime mess. While likely possible, import consistency is
generally the case anyway, so unless it becomes more of an issue in
the future, it likely makes the most sense to just keep imports
consistent.
This commit keeps imports consistent across trait definition files
around `MessageSendEvent` and `MessageSendEventsProvider`.
This public method allows a client to easily disconnect peers while only
owning its node id. It will clean up peer state and disconnect properly
its descriptor.
ChannelManager::force_close_channel does not fail if a non-existing channel id is being passed, making it hard to catch from an API point of view.
Makes force_close_channel return in the same way close_channel does so the user calling the method with an unknown id can be warned.
We want to make sure that we don't sign revoked transactions.
Given that ChannelKeys are not singletons and revocation enforcement is stateful,
we need to store the revocation state in KeysInterface.
Signing the commitment transaction is almost always followed by signing the attached HTLC transactions, so fold the signing operations into a single method.
This drops any direct calls to a generic `ChannelKeys::read()` and
replaces it with the new `KeysInterface::read_chan_signer()`. Still,
under the hood all of our own `KeysInterface::read_chan_signer()`
implementations simply call out to a `Readable::read()` implemention.
This adds a new method to the general cross-channel `KeysInterface`
which requires it to handle the deserialization of per-channel
signer objects. This allows the deserialization of per-channel
signers to have more context available, which, in the case of the
C bindings, includes the actual KeysInterface information itself.
There's no reason to have ChannelMonitor::write_for_disk instead of
just using the Writeable trait anymore. Previously, it was used to
differentiate with `write_for_watchtower`, but support for
watchtower-mode ChannelMonitors was never completed and the partial
bits were removed long ago.
This has the nice benefit of hitting the custom Writeable codepaths
in C bindings instead of trying to hit trait-generics paths.
It doesn't make sense to ever build a lightning node which doesn't
ever write ChannelMonitors to disk, so having a ChannelKeys object
which doesn't implement Writeable is nonsense.
Here we require Writeable for all ChannelKeys objects, simplifying
code generation for C bindings somewhat.
We only actually use two of the fields in ChannelKeys inside a
ChannelMonitor - the holder revocation_basepoint and the
derivation parameters. Both are relatively small, so there isn't
a lot of reason to hold a full copy of the ChannelKeys (with most
of the interaction with it being inside the OnchainTxHandler).
Further, this will avoid calling read on a `ChannelKeys` twice,
which is a somewhat strange API quirk.
CommitmentTransaction maintains the per-commitment transaction fields needed to construct the associated bitcoin transactions (commitment, HTLC). It replaces passing around of Bitcoin transactions. The ChannelKeys API is modified accordingly.
By regenerating the transaction when implementing a validating external signer, this allows a higher level of assurance that all relevant aspects of the transactions were checked for policy violations.
ChannelTransactionParameters replaces passing around of individual per-channel fields that are needed to construct Bitcoin transactions.
Eliminate ChannelStaticData in favor of ChannelTransactionParameters.
Use counterparty txid instead of tx in channelmonitor update.
