input: add production taproot HTLC succeed input constructor
What the developer wrote
Authored by Olaoluwa Osuntokun
input: add production taproot HTLC succeed input constructor
This commit adds MakeTaprootHtlcSucceedInputFinal, a new input constructor
specifically for creating HTLC success inputs that use production taproot
witness types. This function parallels the existing MakeTaprootHtlcSucceedInput
but creates inputs with the TaprootHtlcAcceptedRemoteSuccessFinal witness type
instead of the staging variant.
The new constructor follows the same pattern and signature as its staging
counterpart, ensuring consistency in the input creation API. This allows
contract resolvers to create the appropriate input type based on whether
they are handling a staging or production taproot channel, ensuring that
the correct witness generation logic is applied during transaction creation.
This addition provides the necessary infrastructure for production taproot
channels to properly construct inputs for sweeping HTLC outputs on remote
commitment transactions with the optimized script structure.
What changed, and why it matters
This commit adds a new helper function in LND for creating a specific kind of Bitcoin transaction input used when claiming a Lightning HTLC (a payment locked by a hash/time condition) on a production taproot channel. It mirrors an existing staging-channel helper but uses the final/production witness type. There is no direct evidence in the commit of a security vulnerability; it appears to be infrastructure for an upcoming or recently enabled feature.
No immediate security action required. Reviewers should verify that callers correctly choose between the staging and final constructors and that TaprootHtlcAcceptedRemoteSuccessFinal is wired to the correct witness generation logic elsewhere in the codebase.
Security signals we found
No security-relevant signals in commit message or diff
New API surface adds a witness-type variant; correctness depends on caller selecting the right variant
No validation, bounds checking, or cryptographic changes visible
Evidence from the diff
The change introduces MakeTaprootHtlcSucceedInputFinal in input/input.go. It is structurally identical to MakeTaprootHtlcSucceedInput except it uses the TaprootHtlcAcceptedRemoteSuccessFinal witness type instead of the staging TaprootHtlcAcceptedRemoteSuccess variant. The function builds a BaseInput with that witness type, sets blockToMaturity, and returns an HtlcSucceedInput embedding the preimage. No logic changes to signing, validation, or script execution are present in the diff.
Changed components
input/input.goHTLC success input construction for production taproot channelsInspect captured patch +19 / −0
diff --git a/input/input.go b/input/input.go
index 4a9a4b5..176efeb 100644
--- a/input/input.go
+++ b/input/input.go
@@ -339,6 +339,25 @@ func MakeTaprootHtlcSucceedInput(op *wire.OutPoint, signDesc *SignDescriptor,
}
}
+// MakeTaprootHtlcSucceedInputFinal creates a new HtlcSucceedInput that can be used
+// to spend an HTLC output for a production taproot channel on the remote party's
+// commitment transaction.
+func MakeTaprootHtlcSucceedInputFinal(op *wire.OutPoint, signDesc *SignDescriptor,
+ preimage []byte, heightHint, blocksToMaturity uint32,
+ opts ...InputOpt) HtlcSucceedInput {
+
+ input := MakeBaseInput(
+ op, TaprootHtlcAcceptedRemoteSuccessFinal, signDesc,
+ heightHint, nil, opts...,
+ )
+ input.blockToMaturity = blocksToMaturity
+
+ return HtlcSucceedInput{
+ inputKit: input.inputKit,
+ preimage: preimage,
+ }
+}
+
// CraftInputScript returns a valid set of input scripts allowing this output
// to be spent. The returns input scripts should target the input at location
// txIndex within the passed transaction. The input scripts generated by this
Why this scored 17/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.