-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[custom channels 5/5]: merge custom channel staging branch into master #8960
Conversation
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 Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
Pull reviewers statsStats of the last 30 days for lnd:
|
This prefix seems to have been dropped in the latest rebase? |
1341c89
to
008d29b
Compare
Oops, I haven't actually pushed it yet... It's now up to date and also rebased on top of the first refactor work in the channel state machine. |
4900438
to
529fd75
Compare
529fd75
to
94230af
Compare
I addressed some of the TODOs and fixes the unit and integration test failures. Also added release notes that cover all new functionality of this PR. I added a "Status" section to each part of this PR in the main PR body, will update that whenever status changes. |
94230af
to
626d901
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a quick review on part 5, commits look pretty good. Will do a deep dive, meanwhile let me know if you need help patching unit tests and itest, especially for packages sweep
and contractcourt
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so the biggest thing I want to challenge is the idea that we should use an Option for the tapscript root. IIRC we always have a tapscript root, irrespective of the presence of any aux leaves. We may not have any aux leaves and so I think it makes sense for that to be an option but we can probably save ourselves the effort and just compute the BIP86 root during initialization rather than computing it at the end and having to thread through optional arguments everywhere. The more cases we can eliminate earlier the better, I think. I'm open to some pushback here, though.
Other than that I have some SWE notes intended to simplify some of the interface/implementation code here.
NOTE: my review ONLY covers PART 1
I pulled in the msg router specific comments from this PR into the original PR adding it: #8520 Ideally we can get this one in quickly, then rebase this over it. |
We don't always have a tapscript root. When we do musig2 today for taproot channels, we don't have that extra tweak, so it's effectively BIP 86. This ensures that the only way the output can be spent is via the musig2 multi-sig with no script path. Only with the new aux chan added here is the concept of a tapscript root for the funding output relevant.
FWIW, the BIP 86 root is basically just |
Why don't we just compute the BIP86 value and drop it into that structure so that we can unify the types without needing the Option? I'm trying to push for symmetry/uniformity and I think there is natural symmetry here since there is always a value for this. I just think in the nil case you're computing it later? |
The BIP86 script root is an empty byte slice: https://github.com/btcsuite/btcd/blob/master/txscript/taproot.go#L290 |
626d901
to
b6a20c7
Compare
Rebased after #8520 and addressed some first comments. |
This will be used by external callers to modify the way we resolve contracts on chain. For a given contract, we'll store an extra "blob", that will later be presented during the sweeping phase.
This'll be used to store the extra resolution information for the commitment outputs.
This way we can re-use it. We also make it slightly more generalized.
In this commit, we refactor all the other constructors for the input to use MakeBaseInput. We also add a new set of functional options as well. This'll be useful later on to ensure that new options are properly applied to all the input types.
We also update breachedOutput w/ the new API.
We convert it to use lnwallet.AddrWithKey, as in the future, knowing the internal key for an address will be useful.
In this commit, we add a new AuxSweeper interface. This'll take a set of inputs, and a change addr for the sweep transaction, then optionally return a new sweep output to be added to the sweep transaction. We also add a new NotifyBroadcast method. This'll be used to notify that we're _about_ to broadcast a sweeping transaction. The set of inputs is passed in, which allows the caller to prepare for the ultimate broadcast of the sweeping transaction. We also add ExtraTxOut to BumpRequest pass fees to NotifyBroadcast. This allows the callee to know the total fee of the sweeping transaction.
In this commit, we start to use the AuxSweeper (if present) to obtain a new extra change addr we should add to the sweeping transaction. With this, we'll take the set of inputs and our change addr, and then maybe gain a new change addr to add to the sweep transaction. The extra change addr will be treated as an extra required tx out, shared across all the relevant inputs. This'll also be used in NeedWalletInput to make sure that we add an extra input if needed to be able to pay for the change addr.
This is a hold over until the aux resolution is finalized for HTLC outputs.
For the upcoming aux sweeper integration, the internal key is needed for the call backs.
Similar to the sweeper, when we're about to make a new breach transaction, we ask the sweeper for a new change address, if it has one. Then when we go to publish, we notify broadcast.
This bit will be false by default in current production deployments.
We also add a sanity check to make sure they can't be signaled without the aux interfaces.
ef45c6b
to
bdaa9f4
Compare
Ok, fixed the last merge conflict and also an issue in the way I updated |
Fixes #8769.
This is the cleaned up code of previous PRs that all went into the
0-19-staging
branch and represents all the changes needed to get custom channels intolnd
.Reviewers please read
All commits have been pre-reviewed in previous PRs by at least one person.
We are looking for a second round review, mostly with focus on safety and stability when running with non-custom channels.
The idea is that reviewers get assigned to a certain range of commits within this PR. We decided to not do multiple PRs to keep rebase effort minimal (and so we have all context in a single PR).
The following parts exist (see commit message prefixes marking the start of a part):
-PART1--
: General tapscript leaf awareness and aux leaf store-PART2--
: Custom records on HTLCs, SCID alias management, TLV traffic shaper-PART3--
: Aux funding and RPC/CLI custom data integration-PART4--
: Invoice HTLC modifier and aux channel closer-PART5--
: Force close sweepingIncluded changes from recent PRs to the
0-19-staging
branchThe following PRs HAVE been integrated either into a previous part or this last, 5th part:
Not included PRs to the
0-19-staging
branchThe following PRs have NOT yet been integrated into this PR (as they're currently in-flight):
protofsm.MsgEndpoint
methods #9110