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.
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.
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.
In general, we don't need an explicit lifetime when doing something
like:
fn get_thing(&self) -> &Thing { &self.thing }.
This also makes it easier to reason about what's going on in the
bindings generation.
Instead of blindly signing provided witnessScript, signer must derive
channel keys corresponding to the provided per-commitment-point and
regenerate templated witnessScript to ensure its syntax correctness.
Instead of blindly signing provided witnessScript, signer must derive
channel keys corresponding to the provided per-commitment-point and
regenerate templated witnessScript to ensure its syntax correctness.
A dynamic-p2wsh-output like `to_local` on local commitment/HTLC txn
require a signature from delayed_payment_key to be spend. Instead of
sending private key in descriptor, we ask for spender to derive again
the corresponding ChannelKeys based on key state, uniquely identifying
a channel and encompassing its unique start data.
Descriptor modification is done in next commit.
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.
1107ab06c3 introduced an API to have a
ChannelKeys implementer sign HTLC transactions by calling into the
LocalCommitmentTransaction object, which would then store the tx.
This API was incredibly awkward, both because it required an
external signer trust our own internal interfaces, but also because
it didn't allow for any inspection of what was about to be signed.
Further, it signed the HTLC transactions one-by-one in a somewhat
inefficient way, and there isn't a clear way to resolve this (as
the which-HTLC parameter has to refer to something in between the
HTLC's arbitrary index, and its index in the commitment tx, which
has "holes" for the non-HTLC outputs and skips some HTLCs).
We replace it with a new function in ChannelKeys which allows us
to sign all HTLCs in a given commitment transaction (which allows
for a bit more effeciency on the signers' part, as well as
sidesteps the which-HTLC issue). This may also simplify the signer
implementation as we will always want to sign all HTLCs spending a
given commitment transaction at once anyway.
We also de-mut the LocalCommitmentTransaction passed to the
ChanKeys, instead opting to make LocalCommitmentTransaction const
and avoid storing any new HTLC-related data in it.
This cleans up sign_local_commitment somewhat by returning a
Result<Signaure, ()> over the local commitment transaction instead
of modifying the struct which was passed in.
This is the first step in making LocalCommitmentTransaction a
completely pub struct, using it just to communicate enough
information to the user to allow them to construct a signaure
instead of having it contain a bunch of logic.
This should make it much easier to implement a custom ChannelKeys
by disconnecting the local commitment transaction signing from our
own datastructures.
The ChanKeys is created with knowledge of the Channel's value and
funding redeemscript up-front, so we should not be providing it
when making signing requests.
HTLC Transaction can't be bumped without sighash changes
so their gneeration is one-time for nwo. We move them in
OnchainTxHandler for simplifying ChannelMonitor and to prepare
storage of keys material behind one external signer interface.
Some tests break due to change in transaction broadcaster order.
Number of transactions may vary because of temporary anti-duplicata
tweak can't dissociate between 2- broadcast from different
origins (ChannelMonitor, ChannelManager) and 2-broadcast from same
component.
Extend external signer interface to sign HTLC transactions on its
behalf without seckey passing. This move will allow us to remove
key access access from ChannelMonitor hot memory in further work.
HTLC transactions should stay half-signed by remote until
we need to broadcast them for timing-out/claiming HTLCs onchain.
Extend external signer interface to sign local commitment transactions
on its behalf without seckey passing. This move will allow us to remove
key access from ChannelMonitor hot memory in further work.
Local commitment transaction should stay half-signed by remote until
we need to broadcast for a channel force-close or a HTLC to timeout onchain.
Add an unsafe test-only version of sign_local_commitment to fulfill our
test_framework needs.
This makes Readable symmetric with Writeable and makes sense -
something which is Readable should be Readable for any stream which
implements std::io::Read, not only for a stream type it decides on.
This solves some lifetime-compatibility issues in trying to read()
from a LengthLimitingReader in arbitrary Readable impls.
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
