A TxCreationKeys set represents the key which will be embedded in output
scripts of a party's commitment tx state. Among them there is a always
a key belonging to counter-party, the HTLC pubkey. To dissociate
strongly, prefix keys with broadcaster/countersignatory.
A revocation keypair is attributed to the broadcaster as it's used
to punish a fraudulent broadcast while minding that such keypair
derivation method will be always used by countersignatory as it's
its task to enforce punishement thanks to the release secret.
Previously most of variable fields relative to data belonging to
our node or counterparty were labeled "local"/"remote". It has been
deemed confusing with regards to transaction construction which is
always done from a "local" viewpoint, even if owner is our counterparty
Variables should be named according to the script semantic which is
an invariant with regards to generating a local or remote commitment
transaction.
I.e a broadcaster_htlc_key will always guard a HTLC to the party able
to broadcast the computed transactions whereas countersignatory_htlc_key
will guard HTLC to a countersignatory of the commitment transaction.
The C bindings automatically create a _new() function for structs
which contain only pub fields which we know how to map. This
conflicts with the actual TxCreationKeys::new() function, so we
simply rename it to capture its nature as a derivation function.
Its somewhat awkward that ChannelManagerReadArgs requires a mutable
reference to a HashMap of ChannelMonitors, forcing the callsite to
define a scope for the HashMap which they almost certainly won't use
after deserializing the ChannelManager. Worse, to map the current
version to C bindings, we'd need to also create a HashMap binding,
which is overkill for just this one use.
Instead, we just give the ReadArgs struct ownership of the HashMap
and add a constructor which fills the HashMap for you.
Lightning OutPoints only have 16 bits to express the output index
instead of Bitcoin's 32 bits, implying that some outputs are
possibly not expressible as lightning OutPoints. However, such
OutPoints can never be hit within the lightning protocol, and must
be on-chain spam sent by a third party wishing to donate us money.
Still, in order to do so, the third party would need to fill nearly
an entire block with garbage, so this case should be relatively
safe.
A new comment in channelmonitor explains the reasoning a bit
further.
Because the C bindings maps objects into new structs which contain
only a pointer to the underlying (immovable) Rust type, it cannot
create a list of Rust types which are contiguous in memory. Thus,
in order to allow C clients to call certain Rust functions, we have
to use &[&Type] not &[Type]. This commit fixes this issue for the
get_route function.
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.
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 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 only the txid.
This is another instance of it not being possible to fully
re-implement SimpleManyChannelMonitor using only public methods. In
this case you couldn't properly register outpoints for monitoring
so that the funding transaction would be matched.
Tests use sources of randomness to produce seeds, preimages, secrets,
and ephemeral data. However, this makes comparing logs between different
test runs difficult. Remove uses of random number generators and the
current time in favor of fixed values in order to make the test output
deterministic.
When we receive an inbound HTLC from a peer on an inbound channel,
make sure the funder can still cover the additional on-chain cost
of the HTLC while maintaining their channel reserve.
When we're sending an outbound HTLC, make sure the funder can still
cover the additional on-chain cost of the HTLC while maintaining
their channel reserve.
+ implement fee spike buffer for channel initiators sending payments.
Also add an additional spec-deviating fee spike buffer on the
receiving side (but don't close the channel if this reserve is
violated, just fail the HTLC).
From lightning-rfc PR #740.
Co-authored-by: Matt Corallo <git@bluematt.me>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
`to_local` output or remote output on remote commitment transaction
needs a channel keys to be spent. As per-channel keys are derived from
KeysManager seed and per-channel secrets those must be backed up by
any descriptor bookmarking for latter spend. We test that generating
a new KeysManager loaded with such backed-up seed/per-channel secrets
return the correct keys for spending a `to_local` output.
Add sign_payment_transaction in ChanSigner to be able to spend
SpendableOutputDescriptor in test framework
Extend ChannelKeys with remote_pubkeys to access remote revocation
basepoint for witnessScript construction.
This makes it easier for our automated bindings generator to
function as it tries to automatically create a ::new if the struct
contains only pub elements who's type is convertible.
This caused a bunch of cascading changes, including
passing loggers down to Channels in function calls
rather than having each Channel have a pointer to the
ChannelManager's Logger (which was a circular reference).
Other structs that the Channel had passed its Logger to also
had their loggers removed. Other newly unused Loggers were
also removed, especially when keeping them would've caused
a bunch of extra test changes to be necessary, e.g. with
the ChainWatchInterfaceUtil's Logger.
This simplifies channelmonitor quite nicely (as expected) as we
never have to be concerned with learning data in a DataLossProtect
which is require for us to claim our funds from the latest remote
commitment transaction.
Previous to this commit, variables such as their_channel_reserve
referred to the channel reserve that _we_ are required to keep,
(the value is initially set by the remote). Similarly,
variables such as our_channel_reserve referred to the channel
reserve that we require the remote to keep.
Change this to use local_channel_reserve / remote_channel_reserve
to refer to the the channel reserve that the local is required to keep
and the channel reserve that the remote is required to keep, respectively.
