[wallet 3/3]: group key support for channel funding #1413
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 was referenced Feb 26, 2025
guggero
force-pushed
the
allocation-refactor
branch
from
8939b42 to
ee66eb9
Compare
guggero
force-pushed
the
group-key-support
branch
from
129dd06 to
76938ad
Compare
Pull Request Test Coverage Report for Build 13571552700Details
💛 - Coveralls |
guggero
force-pushed
the
group-key-support
branch
from
76938ad to
2639fa6
Compare
guggero
force-pushed
the
allocation-refactor
branch
2 times, most recently
from
86112a5 to
cdc7cb2
Compare
guggero
force-pushed
the
group-key-support
branch
from
2639fa6 to
9f24e16
Compare
guggero
force-pushed
the
allocation-refactor
branch
from
cdc7cb2 to
be499e2
Compare
guggero
force-pushed
the
group-key-support
branch
2 times, most recently
from
db987a5 to
206da82
Compare
guggero
force-pushed
the
allocation-refactor
branch
from
be499e2 to
bb88417
Compare
This commit refactors the JSON formatting of the channel related custom data fields from lnd and unit tests the JSON output.
The previous structure barely made sense with a single asset UTXO, but is completely wrong with multiple asset UTXO committed to a single channel. We fix the structure and also add more data from the encoded blob to it.
The wrong error was assigned, which caused the proof delivery failures to not surface correctly.
Not sure why the asset ID was never used in the database proof query. But now that we potentially have multiple asset outputs with the same script key but different asset IDs in the same anchor transaction, it's crucial we also add this to the query.
We recently changed the semantics around transfers. We now allow multiple virtual packets to be combined in a single transfer. Which means we have one entry in the transfer table for each on-chain transaction. But each transfer can have inputs and outputs from different asset IDs (meaning different active vPackets). This implies that it's also possible to have multiple transfer outputs with the same script key but different asset IDs, which means we need to change the way we identify the proof files.
One allocation entry means one on-chain output. So we should not create multiple allocations for the same balance (e.g. if there are multiple asset pieces with different asset IDs in the local or remote balance). Instead we just create one allocation for the sum, then let the coin distribution algorithm decide what output goes where.
guggero
force-pushed
the
group-key-support
branch
from
206da82 to
ce40ed7
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.
Adds the ability to fund multiple tranches of a grouped asset into a channel.
TODO:
Corresponding itest: lightninglabs/lightning-terminal#987
Part of the group key support saga: