This commit adds an optional blinding point to payment descriptors and
persists them in our HTLC's extra data. A get/set pattern is used to
populate the ExtraData on our disk representation of the HTLC so that
callers do not need to worry about the underlying storage detail.
When determining the max fee rate of a channel we used to scale
the fee rate depending on our available local balance on this channel.
This lead to a special case that if a channel would be drained we
could especially decrease the fee rate even down to the fee floor.
Now we make sure that our max fee rate will not be lower than the
old fee rate to make sure in case our channel is locally drained
we do not continue to decrease fees too low.
In this commit, we update new Taproot related TLVs (nonces, partial sig,
sig with nonce, etc). Along the way we were able to get rid of some
boiler plate, but most importantly, we're able to better protect against
API misuse (using a nonce that isn't initialized, etc) with the new
options API. In some areas this introduces a bit of extra boiler plate,
and where applicable I used some new helper functions to help cut down
on the noise.
Note to reviewers: this is done as a single commit, as changing the API
breaks all callers, so if we want things to compile it needs to be in a
wumbo commit.
ShutdownInfo contains any info about a previous Shutdown message that we
have sent. This commit adds this type along with read and write methods
for it in the channel db. The existence of the ShutdownInfo on disk
represents the fact that we have previously sent the Shutdown message
and hence that we should resend it on re-establish.
Over the last few commits we have systematically eliminated all but
two states. This allows us to replace it with a boolean to encode
the two remaining states. We would like to be able to eliminate this
field entirely, but doing so requires being able to prove that the
concurrent request block is necessary. This is more difficult and
will be left to future commits.
lnwallet: remove unused channelPendingPayment channelState
Since this state is never set nor read, we remove it completely.
lnwallet: remove redundant channelDispute channelState
In this case, even though we do set this value, it is never read.
Further, the times we read the field at all from LightningChannel
we want the situation of force-closure to block any other
concurrent closure attempts, so we change the sites where we set
channelDispute to channelClosed.
lnwallet: remove redundant channelClosing channelStatus
This value is never used to impact control flow so we need not set
it. We also need not have it.
We take into account a fee buffer of twice the current fee rate
of the commitment transaction plus an additional htlc output
when we are the opener of the channel hence pay when publishing the
commitment transaction. This buffer is not consensus critical
because we only consider it when we are in control of adding a
new htlc to the state. The goal is to prevent situations
where we push our local balance below our channel reserve due to
parallel adding of htlcs to the state. Its not a panacea for these
situations but until we have __option_simplified_update__ deployed
widely on the network its a good precaution to protect against
fee spikes and parallel adding of htlcs to the update log.
Moreover the way the available balance for a channel changed.
We now need to account for a fee buffer when we are the channel
opener. Therefore all the tests had to be adopted.
Prior to this commit, taproot channels had a bug:
- If a disconnect happened before peer.AddNewChannel was called,
then the subsequent reconnect would call peer.AddNewChannel and
attempt the ChannelReestablish dance.
- peer.AddNewChannel would call NewLightningChannel with
populated nonce ChannelOpts. This in turn would call
InitRemoteMusigNonces which would create a new musig pair session
and set the channel's pendingVerificationNonce to nil.
- During the reestablish dance, ProcessChanSyncMsg would be called.
This would also call InitRemoteMusigNonces, except it would fail
since pendingVerificationNonce was set to nil in the previous
invocation.
To fix this, we add a new functional option to signal to the init logic
that it doesn't need to call InitRemoteMusigNonces in in
ProcessChanSyncMsg.
In this commit, update the start up logic to gracefully handle a
seemingly rare case. In this case, a peer detects local data loss with a
set of active HTLCs. These HTLCs then eventually expire (they may or may
not actually "exist"), causing a force close decision. Before this PR,
this attempt would fail with a fatal error that can impede start up.
To better handle such a scenario, we'll now catch the error when we fail
to force close due to entering the DLP and instead terminate the state
machine at the broadcast state. When a commitment transaction eventually
confirms, we'll play it as normal.
Fixes https://github.com/lightningnetwork/lnd/issues/7984
* lnwallet: fix log output msg
The log message is off by one.
* htlcswitch: fail channel when revoking it fails.
When the revocation of a channel state fails after receiving a new
CommitmentSigned msg we have to fail the channel otherwise we
continue with an unclean state.
* docs: update release-docs
* htlcswitch: tear down connection if revocation processing fails
If we couldn't revoke due to a DB error, then we want to also tear down
the connection, as we don't want the other party to continue to send
updates. That may lead to de-sync'd state an eventual force close.
Otherwise, the database might be able to recover come the next
reconnection attempt.
* kvdb: use sql.LevelSerializable for all backends
In this commit, we modify the default isolation level to be
`sql.LevelSerializable. This is the strictness isolation type for
postgres. For sqlite, there's only ever a single writer, so this doesn't
apply directly.
* kvdb/sqlbase: add randomized exponential backoff for serialization failures
In this commit, we add randomized exponential backoff for serialization
failures. For postgres, we''ll his this any time a transaction set fails
to be linearized. For sqlite, we'll his this if we have many writers
trying to grab the write lock at time same time, manifesting as a
`SQLITE_BUSY` error code.
As is, we'll retry up to 10 times, waiting a minimum of 50 miliseconds
between each attempt, up to 5 seconds without any delay at all. For
sqlite, this is also bounded by the busy timeout set, which applies on
top of this retry logic (block for busy timeout seconds, then apply this
back off logic).
* docs/release-notes: add entry for sqlite/postgres tx retry
---------
Co-authored-by: ziggie <ziggie1984@protonmail.com>
We use a helper function to ensure that anytime we're about to make a
normal sighash, we consult the channel type to check if we should use
the default value or sighash all explicitly.
This is a preparatory change for the upcoming "simple channel close"
feature which'll utilize RBF to allow either side to resign the co-op
close transaction for broadcast at any point.
In this commit, we update the channel state machine to use the new
ScriptDescriptor interface. This fixes some subtle issues with the
existing commits, as for p2wsh we always sign the same witness script,
but for p2tr, the witness script differs depending on which branch is
taken.
With the new abstractions, we can treat p2wsh and p2tr as the same
mostly, right up until we need to obtain a control block or a tap tweak.
All tests have been updated accordingly.
In this commit, we update the breach arb to support taproot channels. We
utilize the new taproot briefcase space to store both control blocks,
and also the first+second level scripts for the set of HTLCs.
For taproot channels, we need to thread through the control block in the
sign descriptor. We also ensure that the proper sign method is set. We
leverage the new input.Signature generalization be able to support
handling both schnorr and ECDSA signatures for the second level output.
In this commit, we add the tapscript tree to the ScriptInfo struct, as
in many cases the caller needs the tree in order to generate the control
block or obtain the taptweak which is needed to spend revoked outputs.
This ensures that when loading the channel again after a normal chan
reest, we generate the local nonces, which ensures we can then process
nonces the remote party sends us in their chan reest message.
In this commit, we update the logic to handle nonce init in
ProcessChanSyncMsg. Once a channel is already open, this is where we'll
get the new nonce data from the remote party we'll use to gain the nonce
we need to sign for their next state.
Before this commit, we would conditionally generate nonces in
RevokeCurrentCommitment. We move this to generateRevocation as this is
called when doing channel sync, and we want to make sure we send the
correct set of nonces.
In this commit, we fix a bug in the `deriveMusig2Shachain` function
where it didn't actually use the passed in revocation root as part of
the hmac invocation.
We also modify the function to be more generally useable as well, as now
the caller can just pass in the revocation root things should be derived
from.
In this commit, we update the co-op close flow to support the new musig2
keyspend flow. We'll use some new functional options to allow a caller
to pass in an active musig2 session. If this is present, then we'll use
that to complete the musig2 flow by signing with a partial signature,
and then ultimately combining the signatures at the end.
In this commit, we update the genHtlcSigValidationJobs function to be
taproot aware. As we actually need a schnorr signature for the taproot
validation, we need to coerce the entire wire type into a schnorr sig
with the ForceSchnorr() method.
