]> git.bitcoin.ninja Git - rust-lightning/commit
Batch-sign local HTLC txn with a well-doc'd API, returning sigs
authorMatt Corallo <git@bluematt.me>
Mon, 20 Apr 2020 02:59:53 +0000 (22:59 -0400)
committerMatt Corallo <git@bluematt.me>
Sat, 25 Apr 2020 01:23:51 +0000 (21:23 -0400)
commit7159d1546ae92281a7e0533813a6e7558f16354a
tree1066b2ca86135f4a765ef113093c6398fb38a6d8
parentbf74bb625fb92f3a0345bee31fca97487e3aa6e7
Batch-sign local HTLC txn with a well-doc'd API, returning sigs

1107ab06c33bd360bdee7ee64f4b690e753003f6 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.
lightning/src/chain/keysinterface.rs
lightning/src/ln/chan_utils.rs
lightning/src/ln/channel.rs
lightning/src/ln/channelmonitor.rs
lightning/src/ln/onchaintx.rs
lightning/src/util/enforcing_trait_impls.rs
lightning/src/util/mod.rs