lndclient: handle SIMPLE_TAPROOT_FINAL in acceptor request#276
Merged
Conversation
In this commit, we add the missing case for the production taproot channel type to `newAcceptorRequest` in `lightning_client.go`. The existing switch handled the legacy `SIMPLE_TAPROOT` (staging) and `SIMPLE_TAPROOT_OVERLAY` types, but `SIMPLE_TAPROOT_FINAL` (added in lnd v0.21) fell through to the default and was rejected with "unhandled commitment type 7". Any node running an lndclient-backed acceptor (loop, tapd, custom integrations) would silently refuse every inbound production taproot open. We map it to `lnwallet.CommitmentTypeSimpleTaprootFinal` so the new variant flows through to the acceptor callback the same way as the staging and overlay variants.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
In this PR, we add the missing
SIMPLE_TAPROOT_FINALcase to theacceptor request translator in
lightning_client.go. Today the switchin
newAcceptorRequesthandlesSIMPLE_TAPROOT(staging bits) andSIMPLE_TAPROOT_OVERLAY, but the production taproot type added inlnd v0.21 falls through to the default arm and is rejected with
unhandled commitment type 7. Any node running an lndclient-backedacceptor (loop, tapd, custom integrations) would silently refuse every
inbound production taproot open, which becomes a real problem now that
lightningnetwork/lnd#10820
makes the production variant the one users actually pick.
The fix is a single case that maps
SIMPLE_TAPROOT_FINALtolnwallet.CommitmentTypeSimpleTaprootFinal, so the new variant reachesthe acceptor callback the same way as the staging and overlay variants
already do.
Targeted at
lnd-21-0sinceSIMPLE_TAPROOT_FINALonly exists in thelnd v0.21 RPC surface, and that branch already pins
lnd v0.21.0-beta.rc1.Test plan
go build ./...go test ./...an inbound
OpenChannelwithCommitmentType_SIMPLE_TAPROOT_FINAL,confirm it reaches the acceptor callback instead of erroring out with
unhandled commitment type 7.