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.
To avoid reviewers confusion, rename counterparty_to_self_delay
to counteparty_selected_contest_delay, i.e the justice delay announced
by a channel counterparty restraining our transactions, and to_self_delay
to locally_selected_contest_delay, i.e the justice delay announced by us
restraining counterparty's transactions
We deviate from wider nomenclature by prefixing local data with a
locally_ extension due to the leak of this value in transactions/scripts
builder, where the confusion may happen.
Rename further AcceptChannelData to the new nomenclature.
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
Until we get the bindings generation process super stable, let the
bindings get stale with respect to the main repo while still letting
`cargo check` pass.
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.
In general, it maps:
* Traits to a struct with a void* and a list of function pointers,
emulating what the compiler will do for a dyn trait anyway,
* Structs as a struct with a single opaque pointer to the
underlying type and a flag to indicate ownership. While this is
a bit less effecient than just a direct pointer, it neatly lets
us expose in the public interface the concept of ownership by
setting a flag in the generated struct.
* Unit enums as enums with each type copied over and conversion
functions,
* Non-unit enums have each field converted back and forth with a
type flag and a union across all the C-mapped fields.
In order to calculate a route, it is likely that users need to take
a read()-lock on NetGraphMsgHandler::network_graph. This is not
possible naively from C bindings, as Rust's native RwLock is not
exposed.
Thus, we provide a simple wrapper around the RwLockReadGuard and
expose simple accessor methods.
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.
Instead of using the explicit type which is being returned, refer
to them as Self::AssociatedType, to make clear to the bindings what
type of thing is being returned.
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.
We wanted to bump to 1.29 to continue to support mrustc bootstrapping, but on 1.29
there's a bug preventing us from compiling the lightning package only, thus parts
of lightning-net-tokio cause a compilation error.
The advantage of bumping the MSRV is an improved borrow checker which should
enable improved code quality, and not having jump through weird hoops sometimes
to get 1.22 working.
