[5/? ] - lnwallet: add taproot funding support to the internal wallet flow (reservations)

[Roasbeef]

Change Description

This depends on #7340.

In this PR, we build on all the prior commits and integrate the new taproot channels into the existing internal funding flow. Along the way, we do some refactoring to unify things like signing and verifying incoming commitment transaction signatures.

For our local nonce, we use the existing functional option type to derive the nonce based on the initial shachain pre-image we'll use as our revocation.

We also hook up the new funding flow to the existing internal wallet integration tests:

⛰   go test -v -run=TestLightningWallet/btcwallet/btcd:single_funding_workflow_musig2
=== RUN   TestLightningWallet
=== PAUSE TestLightningWallet
=== CONT  TestLightningWallet
=== RUN   TestLightningWallet/btcwallet/btcd:single_funding_workflow_musig2
--- PASS: TestLightningWallet (7.94s)
    --- PASS: TestLightningWallet/btcwallet/btcd:single_funding_workflow_musig2 (0.46s)
PASS
ok  	github.com/lightningnetwork/lnd/lnwallet/test/btcd	8.225s

The last ~14 commits are new. Along the way some rebase issues were found and fixed in commits marked as [temp].

The next PR in this series will modify the channel state machine to understand the new commitment dance.

Steps to Test

Steps for reviewers to follow to test the change.

Pull Request Checklist

Testing

• Your PR passes all CI checks.
• Tests covering the positive and negative (error paths) are included.
• Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

• The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
• Commits follow the Ideal Git Commit Structure.
• Any new logging statements use an appropriate subsystem and logging level.
• There is a change description in the release notes, or [skip ci] in the commit message for small changes.

📝 Please see our Contribution Guidelines for further guidance.

[ellemouton]

very nice!

[lightninglabs-deploy]

@Crypt-iQ: review reminder
@Roasbeef, remember to re-request review from reviewers when ready

[Roasbeef]

Initial round of comments addressed, PTAL!

[yyforyongyu]

So this is the nonce that's sent in open_channel by the funder and can be used to generate the final sig when receiving funding_signed.nonce from the fundee right?

[Roasbeef]

Correct, this is where we use the counter based method to generate nonces we can always arrive at again.

In part 4, I started to also bind the nonce creation with the tx hash of the tx we're about to sign. However at this point, we need to send a nonce, and don't yet know the tx hash so we can't do so.

We'll still do that each time we go to sign a new commitment, as the tx hash then is already known.

[Roasbeef]

Latest round of comments addressed, PTAL!

[yyforyongyu]

Verrry close🤙🤙🤙 Need to fix the itest compile error, plus the linter error.

[yyforyongyu]

just occurs to me, why is this named simple taproot🤓?

[Roasbeef]

So initial AJ had a much more feature complete and ambitious proposal to basically do everything (taproot, PTLCs, new commitment type, scriptless scripts) all in one. I thought it was a bit too much to bite off at once, so two spec meetings around I proposed a staged roll out proposal: musig2 output first, then PTLC+scriptless script, then commitment format changes). Thus was born "simple taproot".

[ellemouton]

LGTM 🔥 🥕⚡

A couple of linter errors to catch - most of them are lll ones

[ellemouton]

non blocking
am assuming we will calculate the witness script then for taproot chans at the time of spending since we would need to know which which branch we are spending in any case to build the control block at spend time. Other option would be to add a isLocalCommit bool to the CommitScriptToSelf method and then pre-compute and return the witness script & control block. That way we also dont have to derive the tree twice.

[Roasbeef]

See later in the series, this is modified further to include the full script tree information.

[yyforyongyu]

Let's fix the linter errors and we can⛵️

[yyforyongyu]

Leaving some notes for other reviewers, was wondering if lc.currentHeight is always updated to date here since NewAnchorResolutions makes a separate call to db and creates a new LightningWallet. This is fine as we'd only call it when StateCommitmentBroadcasted, which means the db has the latest view of the local commit, and no other goroutines can update it anymore because it's closed.