multi: implement awareness of the final/production taproot channel variant #9985
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit introduces seven new witness types specifically designed for production taproot channels that use the final optimized script structure. These witness types correspond to the existing staging taproot witness types but are intended for channels using the finalized taproot specification with optimized scripts that employ OP_CHECKSIGVERIFY instead of OP_CHECKSIG + OP_DROP. The new witness types cover all taproot channel operations including local and remote commitment spends, second-level HTLC transactions, direct HTLC sweeps, and revocation scenarios. Each production witness type follows the established naming convention by appending "Final" to distinguish them from their staging counterparts. The witness generation logic for these new types mirrors the existing taproot implementation but will be used when the channel type indicates a production taproot channel rather than a staging one. This ensures that the correct script tree structure and witness format is used for each channel type.
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.
This commit extends all HTLC contract resolvers to accept and store channel type information, which is essential for determining whether to use staging or production taproot witness types during contract resolution. Each resolver constructor now accepts a channeldb.ChannelType parameter and stores it as a field within the resolver struct. The channel arbitrator has been updated to extract channel type information from the channel state and pass it to all resolver constructors. This ensures that each resolver has the necessary context to make appropriate decisions about script generation and witness type selection based on the specific channel type being resolved. Helper methods isTaprootFinal() have been added to each resolver to provide a clean interface for determining when production taproot witness types should be used. This lays the groundwork for the resolvers to properly handle both staging and production taproot channels with the correct script optimizations. The changes maintain backward compatibility with existing channel types while providing the infrastructure needed for production taproot channel support throughout the contract resolution system.
This commit implements the core logic for selecting appropriate witness types based on channel type in the contract resolution system. The commit sweep resolver, HTLC timeout resolver, and HTLC success resolver have been updated to use production taproot witness types when handling final taproot channels. For each resolver, the witness type selection follows a consistent three-way pattern: production taproot channels use Final witness types, staging taproot channels use the existing taproot witness types, and legacy channels continue to use their established witness types. This ensures that each channel type uses the appropriate script structure and witness generation logic. The HTLC success resolver required the addition of a new production input constructor to properly handle direct HTLC sweeps on remote commitments with production taproot channels. The HTLC timeout resolver was updated to handle both second-level timeout transactions and direct timeout sweeps with the correct production witness types. These changes ensure that production taproot channels benefit from the optimized script structure using OP_CHECKSIGVERIFY while maintaining full backward compatibility with staging taproot and legacy channel types.
This commit completes the production taproot integration by updating the UTXO nursery to properly handle production taproot channels. The nursery is responsible for incubating time-locked outputs from commitment transactions and must use the correct witness types for successful sweeping operations. The witness type selection logic has been updated in three key areas within the IncubateOutputs function: incoming HTLC resolution handling, outgoing HTLC resolution handling, and baby output creation through makeBabyOutput. Each location now uses a consistent three-way selection pattern that chooses production taproot witness types for final channels, staging types for development channels, and legacy types for traditional channels. A new helper method isProdTaprootResolution has been added to determine production taproot channels by examining the presence of a ResolutionBlob, which indicates auxiliary channel information used by production taproot implementations. The makeBabyOutput function has been converted to a method to access this helper function. The NurseryReport function has been updated to include all new Final witness types in its switch statements, ensuring that production taproot outputs are properly categorized and reported. This maintains consistency in the nursery's reporting system while supporting the new witness types.
This commit introduces the infrastructure necessary to distinguish between staging and production taproot channels in the channel database. A new TaprootFinalBit flag is added to the ChannelType enumeration to identify channels that use the final taproot specification with optimized scripts. The IsTaprootFinal() method provides a clean interface for determining when a channel uses production taproot scripts versus the staging implementation. Production taproot channels are characterized by their use of feature bits 80/81 and optimized script structures that employ OP_CHECKSIGVERIFY for improved efficiency and reduced transaction sizes. This channel type distinction is essential for the contract resolution system to select appropriate witness types and script generation options. The bit must be set alongside SimpleTaprootFeatureBit to ensure proper channel type validation and backwards compatibility with existing taproot implementations.
This commit extends the taproot HTLC script generation functions to accept TaprootScriptOpt parameters, enabling callers to specify whether production or staging script variants should be generated. The SenderHTLCScriptTaproot and ReceiverHTLCScriptTaproot functions now accept a variadic opts parameter that is forwarded to the underlying script tree construction. This change provides the necessary infrastructure for the wallet and contract resolution systems to generate the appropriate script trees based on channel type. Production taproot channels can now pass the WithProdScripts() option to generate optimized scripts using OP_CHECKSIGVERIFY, while staging channels continue to use the existing development script structure. The modification maintains backward compatibility by making the opts parameter variadic with sensible defaults. Existing callers that do not specify options will continue to generate staging scripts as before, ensuring no disruption to current functionality while enabling future production script support.
This commit updates the wallet's commitment transaction generation logic to use appropriate script options based on the channel type. The commitment builder now determines whether a channel uses production taproot scripts and passes the WithProdScripts() option accordingly to HTLC script generation functions. The changes affect three key areas of the wallet: channel state management, commitment transaction construction, and funding reservation handling. Each area now properly detects production taproot channels using the IsTaprootFinal() method and applies the correct script generation options to ensure consistency with the channel's script optimization level. This integration ensures that production taproot channels generate commitment transactions with optimized script trees using OP_CHECKSIGVERIFY, while maintaining full compatibility with staging taproot and legacy channel types. The script option selection is applied consistently across all commitment transaction scenarios including local commits, remote commits, and HTLC processing.
This commit extends the Lightning RPC interface to support production taproot channels by adding a new SIMPLE_TAPROOT_FINAL commitment type. This allows external clients to explicitly request channels that use the finalized taproot specification with optimized script structures and feature bits 80/81. The RPC server has been updated to properly handle the new commitment type during channel opening operations, mapping the SIMPLE_TAPROOT_FINAL type to the appropriate internal channel type flags including both SimpleTaprootFeatureBit and TaprootFinalBit. This ensures that channels opened through the RPC interface are properly configured with production taproot capabilities. The existing SIMPLE_TAPROOT commitment type has been clarified in its documentation to indicate that it represents the staging version using development scripts, providing clear distinction between the two taproot variants available to RPC clients. The protobuf definitions and generated code have been updated accordingly to support this new functionality.
This commit extends the funding manager's commitment type negotiation logic to handle production taproot channels. The negotiation system now recognizes and properly processes requests for channels using the final taproot specification with feature bits 80/81 and optimized script structures. The commitment type negotiation has been enhanced to distinguish between staging and production taproot variants during the channel opening process. When a production taproot channel is requested, the negotiation logic ensures that both parties support the necessary feature bits and applies the appropriate channel type configuration including the TaprootFinalBit flag. Comprehensive test coverage has been added to validate the negotiation behavior for production taproot channels, ensuring that the funding process correctly handles feature bit validation, commitment type mapping, and error conditions. The tests verify that production taproot channels are only established when both peers indicate support for the finalized taproot features.
This commit adds comprehensive integration test coverage for production taproot channels to validate end-to-end functionality in realistic scenarios. The tests verify that production taproot channels can be successfully opened, operated, and closed using the finalized taproot specification with optimized scripts and feature bits 80/81. The integration tests cover channel opening with the SIMPLE_TAPROOT_FINAL commitment type, ensuring that the complete channel lifecycle works correctly with production taproot features. Test utilities have been enhanced to support production taproot channel creation and validation, providing the necessary infrastructure for comprehensive testing scenarios. Additional unit tests have been added to the input package to validate size calculations and witness generation for production taproot witness types. These tests ensure that the new Final witness types produce correctly sized witnesses and transactions, maintaining the expected efficiency benefits of the optimized script structure. The test coverage helps ensure that production taproot channels operate correctly across all system components while maintaining compatibility with existing channel types and providing confidence in the production readiness of the implementation.
This commit adds preparatory infrastructure and TODO markers in the watchtower justice kit generation for future production taproot channel support. The changes establish placeholders for channel type detection and script option selection that will be needed when watchtowers begin handling breach scenarios for production taproot channels. The current implementation includes commented code structures that demonstrate the intended approach for integrating production script options into the justice transaction generation process. When channel type information becomes available in the BreachRetribution structure, these placeholders can be activated to ensure that watchtowers generate justice transactions using the appropriate script optimization level. This preparatory work ensures that the watchtower system has a clear path toward production taproot support while maintaining current functionality for staging taproot and legacy channels. The TODO comments provide explicit guidance for future development when watchtower breach handling for production taproot channels is implemented.
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request implements comprehensive support for production taproot channels in LND, introducing the ability to create and manage channels using the finalized taproot specification with optimized script structures. Production taproot channels utilize feature bits 80/81, and utilize resolution scripts that have been optimized using miniscript.
This PR builds on top of #9982 which adds some prepatory TLVs to support splicing in the future.
In aggregate, these changes are intended to implement the final set of upcoming changes to the taproot chans spec.
Implementation Overview
Core Infrastructure
The implementation introduces a comprehensive witness type system that distinguishes between staging and production taproot channels. Seven new "Final" witness types have been added to handle all taproot channel operations including commitment spends, HTLC resolution, and revocation scenarios.
A new channel type bit
TaprootFinalBithas been added to the channel database infrastructure, allowing the system to persistently track whether a channel uses production or staging taproot scripts.Contract Resolution System
The contract court system has been extensively updated to support production taproot channels throughout the resolution process. All HTLC resolvers now accept channel type information and use it to select appropriate witness types during contract resolution. The UTXO nursery has been integrated to properly handle time-locked outputs from production taproot channels.
The witness type selection follows a consistent three-way pattern throughout the codebase: production taproot channels use Final witness types, staging taproot channels use existing taproot witness types, and legacy channels continue using their established witness types.
Script Generation and Wallet Integration
The wallet's commitment transaction generation logic has been updated to use appropriate script options based on the channel type. A new script option system allows callers to specify whether production or staging script variants should be generated, with the wallet automatically selecting the correct option based on the channel's type.
Script generation functions throughout the input package now accept
TaprootScriptOptparameters that enable production script generation when appropriate.External Interfaces
The RPC interface has been extended with a new
SIMPLE_TAPROOT_FINALcommitment type that allows external clients to explicitly request production taproot channels. The funding manager's negotiation logic has been updated to handle production taproot channel requests and ensure that both parties support the necessary feature bits before establishing the channel.Backward Compatibility
This implementation maintains full backward compatibility with existing channel types. Staging taproot channels continue to function exactly as before, and legacy channels remain unaffected. The new production taproot functionality is additive and does not modify any existing behavior.
TODO Checklist