There are a few cases where the upcoming C bindings don't know how
to handle something which depends on something defined later in the
file. Instead of adding another pass to the C bindings generator,
it is much simpler to just reorder structs.
To do this, we replace get_and_clear_pending_htlcs_updated with
get_and_clear_pending_monitor_events, and which still transmits HTLCUpdates
as before, but now also transmits a new MonitorEvent::CommitmentTxBroadcasted
event when a channel's commitment transaction is broadcasted.
* Splits up the monolithic test into smaller unit tests
* Factors out helpers for graph setup
* Changes `id_to_feature_flags` to be a function, there was no
reason why it had to be a macro
* Activates a previously commented-out test that checks for
the failure case in `disable_node_test`
Due to a desire to be able to override temporary channel IDs and
onion keys, KeysInterface had two separate fetch-random-32-bytes
interfaces - an onion-key specific version which fetched 2 random
32 byte strings and a temporary-channel-id specific version.
It turns out, we never actually need to override both at once (as
creating a new channel and sending an outbound payment are always
separate top-level calls), so there's no reason to add two
functions to the interface when both really do the same thing.
This changes the LICENSE file and adds license headers to most files
to relicense under dual Apache-2.0 and MIT. This is helpful in that
we retain the patent grant issued under Apache-2.0-licensed work,
avoiding some sticky patent issues, while still allowing users who
are more comfortable with the simpler MIT license to use that.
See https://github.com/rust-bitcoin/rust-lightning/issues/659 for
relicensing statements from code authors.
Allows calling of InMemoryChannelKeys methods.
The wrapping makes it obvious to signer implementers that the pre-derived keys are a local cache and should not be trusted in a validating signer.
The commitment secret is sensitive - it can be used by an attacker to
steal funds if the node also signs the same transaction. Therefore,
only release the secret from ChannelKeys when we are revoking a
transaction.
For making debugging easy.
If the user gives a different node_secret for transport
layer (`PeerManager`) and for routing msg, internal_announcement_signatures
is the first place it causes an error.
By giving a detailed error message, user will be able to
fix the bug quickly.
... for ChannelError and APIMisuseError
Before this commit, When rl returns error, we don't know
The actual parameter which caused the error.
By returning parameterised `String` instead of predefined `&'static str`,
We can give a caller improved error message.
TestLogger now has two additional methods
1. `assert_log_contains` which checks the logged messsage
has how many entry which includes the specified string as a substring.
2. `aasert_log_regex` mostly the same with `assert_log_contains`
but it is more flexible that caller specifies regex which has
to be satisfied instead of just a substring.
For regex, tests now includes `regex` as dev-dependency.
We use them largely as indexes into a Vec<Transaction> so there's
little reason for them to be u32s. Instead, use them as usize
everywhere.
We also take this opportunity to add range checks before
short_channel_id calculation, as we could otherwise end up with a
bogus short_channel_id due to an output index out of range.
This was just an oversight when route calculation was split up into
parts - it makes no sense for get_route to require that we have a
full route message handler, only a network graph (which can always
be accessed from a NetGraphMsgHandler anyway).
Instead of making the filter_block fn in the ChainWatchInterface
trait return both a list of indexes of transaction positions within
the block and references to the transactions themselves, return
only the list of indexes and then build the reference list at the
callsite.
While this may be slightly less effecient from a memory locality
perspective, it shouldn't be materially different.
This should make it more practical to generate bindings for
filter_block as it no longer needs to reference Rust Transaction
objects that are contained in a Rust Block object (which we'd
otherwise just pass over the FFI in fully-serialized form).
non-mut references to primitives are only excess overhead, so
there's not much reason to ever have them. As a nice bonus, it also
is one less thing to worry about when generating C bindings
This is more consistent with the way we use std::cmp over the
codebase and avoids `use std`, which is only actually needed to
support older rustcs, so feels a bit awkward.
