Let ChannelSigner set and spend LN scriptpubkeys
#3512
Draft
Conversation
This file contains 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 allows the `to_remote` output to easily be changed according to the features of the channel, or the evolution of the LN specification. `to_remote` could even be set to completely arbitrary scripts if compatibility with the formal LN spec is not required.
This allows the `to_local` output to easily be changed according to the features of the channel, or the evolution of the LN specification. `to_local` could even be set to completely arbitrary scripts if compatibility with the formal LN spec is not required.
This allows the htlc tx output to easily be changed according to the features of the channel, or the evolution of the LN specification. The output could even be set to completely arbitrary scripts if compatibility with the formal LN spec is not required. Builders of htlc transactions now ask a `ChannelSigner` for the appropriate revokeable script pubkey to use, and then pass it to the htlc transaction constructors.
All LN-Penalty channel signers need to be able to punish the counterparty in case they broadcast an old state. In this commit, we ask implementers of `ChannelSigner` to produce the full transaction with the given input finalized to punish the corresponding previous output. Consumers of the `ChannelSigner` trait can now be agnostic to the specific scripts used in revokeable outputs. We leave passing to the `ChannelSigner` all the previous `TxOut`'s needed to produce valid schnorr signatures under BIP 341 spending rules to a later patch.
for the revokeable scripts in the `to_local` and the htlc tx outputs.
All LN-Penalty channel signers need to be able to punish the counterparty in case they broadcast an old state. In this commit, we ask implementers of `ChannelSigner` to produce the full transaction with the given input finalized to punish the corresponding previous output. Consumers of the `ChannelSigner` trait can now be agnostic to the specific scripts used in HTLC outputs of commitment transactions. We leave passing to the `ChannelSigner` all the previous `TxOut`'s needed to produce valid schnorr signatures under BIP 341 spending rules to a later patch.
Add `ChannelSigner::sweep_counterparty_offered_htlc_output` Add `ChannelSigner::sweep_counterparty_received_htlc_output`
tankyleo
force-pushed
the
2025-01-signer-spks
branch
from
508d577 to
5b57776
Compare
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 PR allows the customization of different outputs of the commitment transaction, in preparation for taproot channels and also to allow people to set the outputs to arbitrary scripts if they don't require compatibility with the formal LN spec.
My approach is to ask the channel signers to do more work (but not more than that of most hardware wallets):
EcdsaChannelSignerwould return just the signature). I am considering having theChannelSignerreturn just the witness here, instead of the full transaction.This PR assumes that if the scripts in a channel are customized to something outside the LN spec, that channel supports zero fee htlc tx.
I mark it as draft. I understand this is a huge PR. I hope to show the full picture of how the current approach works to get approach ACKs, then happy to break it down into smaller PRs.
Remaining TODOs:
SpendableOutputDescriptorto accomodate taproot / arbitrary scripts.EcdsaChannelSignervsChannelSignerAPIs.ChannelSignerto return just the witness that finalizes the given input, instead of returning the full transaction with the given input finalized.ChannelSignerinline with the LN spec. One possible route: have theChannelSignertrait offer "ProvidedMethods" for implementers who want to stay in-line with the LN specification - people who want to depart from the spec would then override these methods.Supersedes #3454