Now that all of the core functionality for anchor outputs has landed,
we're ready to remove the config flag that was temporarily hiding it
from our API.
This change modifies six structs that were keeping
track of anchors features with an `opt_anchors` field,
as well as another field keeping track of nonzero-fee-
anchor-support.
This allows users to bump their commitments and HTLC transactions
without having to worry about all the little details to do so. Instead,
we'll just require that they implement the `CoinSelectionSource` trait
over their wallet/UTXO source, granting the event handler permission to
spend confirmed UTXOs for the transactions it'll produce.
While the event handler should in most cases produce valid transactions,
assuming the provided confirmed UTXOs are valid, it may not produce
relayable transactions due to not satisfying certain Replace-By-Fee
(RBF) mempool policy requirements. Some of these require that the
replacement transactions have a higher feerate and absolute fee than the
conflicting transactions it aims to replace. To make sure we adhere to
these requirements, we'd have to persist some state for all transactions
the event handler has produced, greatly increasing its complexity. While
we may consider implementing so in the future, we choose to go with a
simple initial version that relies on the OnchainTxHandler's bumping
frequency. For each new bumping attempt, the OnchainTxHandler proposes a
25% feerate increase to ensure transactions can propagate under
constrained mempool circumstances.
Previously, our local signatures would always be deterministic, whether
we'd grind for low R value signatures or not. For peers supporting
SegWit, Bitcoin Core will generally use a transaction's witness-txid, as
opposed to its txid, to advertise transactions. Therefore, to ensure a
transaction has the best chance to propagate across node mempools in the
network, each of its broadcast attempts should have a unique/distinct
witness-txid, which we can achieve by introducing random nonce data when
generating local signatures, such that they are no longer deterministic.
`ChannelMonitorUpdate`s are our most size-sensitive objects - they
are the minimal objects which need to be written to disk on each
commitment update. Thus, we should be careful to ensure we don't
pack too much extraneous information into each one.
Here we add future support for removing the per-HTLC explicit
`Option<Signature>` and `HTLCInCommitmentUpdate` for non-dust HTLCs
in holder commitment tx updates, which are redundant with the
`HolderCommitmentTransaction`.
While we cannot remove them entirely as previous versions rely on
them, adding support for filling in the in-memory structures from
the redundant fields will let us remove them in a future version.
We also add test-only generation logic to test the new derivation.
Adds the macro `get_pubkey_from_node_id`
to parse `PublicKey`s back from `NodeId`s for signature
verification, as well as `make_funding_redeemscript_from_slices`
to avoid parsing back and forth between types.
Now that ready_channel is also called on startup upon deserializing
channels, we opt to rename it to a more indicative name.
We also derive `PartialEq` on ChannelTransactionParameters to allow
implementations to determine whether `provide_channel_parameters` calls
are idempotent after the channel parameters have already been provided.
`get_channel_signer` previously had two different responsibilites:
generating unique `channel_keys_id` and using said ID to derive channel
keys. We decide to split it into two methods `generate_channel_keys_id`
and `derive_channel_signer`, such that we can use the latter to fulfill
our goal of re-deriving signers instead of persisting them. There's no
point in storing data that can be easily re-derived.
The `derive_{public,private}_revocation_key` methods hash the two
input keys and then multiply the two input keys by hashed values
before adding them together. Because addition can fail if the tweak
is the inverse of the secret key this method currently returns a
`Result`.
However, it is not cryptographically possible to reach the error
case - in order to create an issue, the point-multiplied-by-hash
values must be the inverse of each other, however each point
commits the SHA-256 hash of both keys together. Thus, because
changing either key changes the hashes (and the ultimate points
added together) in an unpredictable way, there should be no way to
construct such points.
The `derive_{public,private}_key` methods hash the two input keys
and then add them to the input public key. Because addition can
fail if the tweak is the inverse of the secret key this method
currently returns a `Result`.
However, it is not cryptographically possible to reach the error
case - in order to create an issue, the SHA-256 hash of the
`base_point` (and other data) must be the inverse of the
`base_point`('s secret key). Because changing the `base_point`
changes the hash in an unpredictable way, there should be no way to
construct such a `base_point`.
