Skip to content

Proof-system-v1 #1453

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

Open
wants to merge 14 commits into
base: main
Choose a base branch
from
Open

Proof-system-v1 #1453

wants to merge 14 commits into from

Conversation

gijswijs
Copy link
Contributor

@gijswijs gijswijs commented Mar 22, 2025

This pull request introduces several enhancements and refactors related to inclusion and exclusion proof handling. The key changes include:

  • STXO Commitment and Proofs:
    • Implemented commitment to spent assets within Taproot Assets using AltLeaves.
    • Added encoders and decoders for CommitmentProof structures that are used for the STXO proofs.
    • Introduced STXO inclusion proofs and proof verification for non-split assets.
    • Added STXO exclusion proofs and verification for the outputs that don't involve the asset spending the STXOs
  • Code Refactoring and Improvements:
    • Minor refactors of code throughout
    • Improved wording in comments for clarity.
    • Removed unnecessary parameters and assertions
    • Refactor the code of proof/verifier.go
  • Testing:
    • Added integration tests for STXO inclusion proofs.
    • Added integration tests for STXO exclusion proofs.
    • Implemented unit tests for CommitmentProofs encoding and decoding.

Considerations

  • Potentially remove the commit multi: remove AssertInputsUnique. Although with this proof system we are able to parse a proof for non-unique inputs, older nodes cannot. So for now this check should probably remain in place.
  • Explore adding proofs to asset splits.

This change is Reviewable

@coveralls
Copy link

coveralls commented Mar 22, 2025

Pull Request Test Coverage Report for Build 15070461131

Details

  • 453 of 633 (71.56%) changed or added relevant lines in 18 files are covered.
  • 32 unchanged lines in 10 files lost coverage.
  • Overall coverage increased (+0.3%) to 37.084%

Changes Missing Coverage Covered Lines Changed/Added Lines %
proof/records.go 14 15 93.33%
tappsbt/interface.go 0 1 0.0%
proof/mock.go 23 26 88.46%
tapchannel/aux_closer.go 0 3 0.0%
tapfreighter/wallet.go 0 4 0.0%
itest/assertions.go 0 5 0.0%
tapchannel/commitment.go 0 6 0.0%
proof/append.go 39 46 84.78%
tapchannel/aux_sweeper.go 0 9 0.0%
proof/mint.go 9 23 39.13%
Files with Coverage Reduction New Missed Lines %
commitment/tap.go 1 72.05%
address/address.go 2 67.47%
address/mock.go 2 88.24%
asset/group_key.go 2 57.89%
proof/verifier.go 2 81.42%
tappsbt/create.go 2 26.74%
asset/asset.go 4 47.35%
tapchannel/aux_leaf_signer.go 5 43.08%
tappsbt/decode.go 6 84.51%
tappsbt/encode.go 6 92.27%
Totals Coverage Status
Change from base Build 15055985108: 0.3%
Covered Lines: 26885
Relevant Lines: 72497

💛 - Coveralls

@github-project-automation github-project-automation bot moved this from 🏗 In progress to 👀 In review in Taproot-Assets Project Board Mar 28, 2025
Copy link
Member

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work, this looks pretty good 🎉
Have a couple of suggestions, after which we can probably take this out of draft.

@@ -2026,15 +2038,6 @@ func ValidateAnchorInputs(anchorPacket *psbt.Packet, packets []*tappsbt.VPacket,
)
}

// Each input must have a valid set of AltLeaves at this point.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since there might've already been alt leaves in the vPacket, should we still validate them? Or is this added back in another place in another commit? Still going through the diff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if I follow. This is a sanity check that makes sure we have at least a valid set of AltLeaves. If we don't have them here during ValidateAnchorInputs we can fail early.
Yes, we do check them during FundPacket as well, so it should not be possible to have invalid AltLEaves at this point in the code, but it doesn't hurt to check here. Also, future flows might be different and warrant a check here even more.

@gijswijs gijswijs force-pushed the proof-system-v2 branch 3 times, most recently from 9c4d5c9 to 0055fb3 Compare April 9, 2025 15:29
@guggero guggero self-requested a review April 9, 2025 15:30
@gijswijs gijswijs changed the title Proof-system-v2 Proof-system-v1 Apr 10, 2025
@guggero guggero changed the base branch from main to extract-refactors-from-proof-v1 April 11, 2025 12:42
@guggero
Copy link
Member

guggero commented Apr 11, 2025

Extracted some commits into #1465 to ease review on this one. Pushed up a rebase.

Copy link
Member

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did another pass. Definitely looks better, but I think we still need an iteration on the core verification logic, to make it easier to understand.

@guggero guggero force-pushed the extract-refactors-from-proof-v1 branch 2 times, most recently from 171f7ae to c8a7971 Compare April 11, 2025 15:19
@guggero
Copy link
Member

guggero commented Apr 11, 2025

Sorry, I don't think I made things easier for you as an author by splitting the PR into two. And now I noticed that the commit c9b1d54 does need to go into this one instead...
Let me know if I should fix my own mess by rebasing this one.

@guggero guggero changed the base branch from extract-refactors-from-proof-v1 to main April 17, 2025 16:32
Copy link
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did a clean review, focusing on the tests in particular. Feels like we're pretty close.

The linter is failing, and also the unit tests panic as one of the test cases is incomplete:

--- FAIL: TestVerifyV1ExclusionProof (0.12s)
    --- FAIL: TestVerifyV1ExclusionProof/multiple_assets_with_an_exclusion_proof_each (0.00s)

@gijswijs gijswijs requested a review from Roasbeef May 13, 2025 17:57
Copy link
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 25 of 25 files at r1, 28 of 28 files at r2, 9 of 9 files at r3, all commit messages.
Reviewable status: all files reviewed, 61 unresolved discussions (waiting on @gijswijs and @guggero)

Copy link
Member

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed a single fixup commit that adds more unit tests (and also uncovered a small bug that is fixed too). Feel free to check and apply that commit directly (not attribution required).

Other than that only nits are left in the code (which I didn't fix, I leave that to you).

The litd itest failure is related to the changes here though:

error funding channel: unable to bind PSBT: rpc error: code = Unknown desc = error verifying PSBT: funding output not found in PSBT

So I'll need to take a look into that. But hopefully it's something small (will take a closer look tomorrow).

@gijswijs gijswijs requested a review from guggero May 15, 2025 14:41
@gijswijs gijswijs force-pushed the proof-system-v2 branch 2 times, most recently from 81c690e to 2bc57a2 Compare May 15, 2025 15:42
@Roasbeef
Copy link
Member

So I'll need to take a look into that. But hopefully it's something small (will take a closer look tomorrow).

I think what's missing is that we need to mind the alt leaves when we manually create the funding output our selves.

@guggero
Copy link
Member

guggero commented May 15, 2025

I think what's missing is that we need to mind the alt leaves when we manually create the funding output our selves.

Yeah, I got everything to work today. Now I'm just making sure this doesn't introduce another backward incompatibility vector.

gijswijs and others added 14 commits May 16, 2025 13:33
Because we retrieve AltLeaves from the proof during anchor input
validation, we don't need to store them in the vInputs struct. This commit
removes the AltLeaves field from the vInputs struct and the associated
methods.
Since we're only ever passing nil (and we use the previous witness
in the script/burn key), we just remove the witness parameter
completely.
This commit stores the STXOs in the output commitments using AltLeaves.
This commit adds a new field to the CommitmentProof struct that will
house STXO proofs. We also add encoding/decoding functions for that new
sub type and update the test vectors accordingly.
Co-authored-by: Gijs van Dam <gijs@lightning.engineering>
Instead of using alt leaves from the inputs, we use the alt leaves from
the proof. We also remove the deduplication func
`AddLeafKeysVerifyMerge` because it's not needed anymore.
This commit adds the STXO exclusion proof to the proof parameters. It
stores them in `params.ExclusionProofs[].CommitmentProof.STXOProofs[]`
where they are later encoded when creating the actual proofs.
The proof version is bumped to indicate the usage and support of stxo
style proofs.
`verifyExclusionProofs` now checks if the stxo exclusion proofs are
present in the `ExclusionProofs[idx].CommitmentProof` and if so will
verify those in preference of the old style proofs.
This commit adds an itest that test whether the stxo exclusion proof is
added to the proof suffix and whether the proof is actually a valid
exclusion proof for the minimal asset we expect to see in the stxo set.
This commit adds v1 inclusion proof verification.
Since we now produce STXO commitments in certain situations, it makes
sense to update the test vectors that are produced from a regtest itest
run and are therefore not deterministic.
This commit moves the split commit witness trimming into the
addToFundingCommitment and then use that function in both places where
we create a commitment from assets during the channel funding process.
To avoid breaking backward compatibility with older nodes and existing
channels, we need to make sure we don't add STXO proofs to channel
related transactions.
@guggero guggero force-pushed the proof-system-v2 branch from 2bc57a2 to 76c0706 Compare May 16, 2025 14:11
@guggero
Copy link
Member

guggero commented May 16, 2025

I've pushed up a set of changes that make everything backward compatible. What we decided to do in this PR is the following:

  • We do NOT produce any V1 proofs in this PR (outside of unit tests). Otherwise newly minted or transferred assets would not be recognized by older nodes ("unknown proof version 1").
  • We DO however add STXO commitments to root outputs and add STXO inclusion/exclusion proofs to any generated proofs.
    • STXO commitments are only added to root outputs so on-chain sends to older nodes still work as expected. So we can test that we can correctly spend any inputs that have STXO commitments in them.
    • Without a proof being set as V1, any STXO inclusion/exclusion proofs will not be verified. But we can make sure that old nodes can correctly parse such proofs but just put the data in the unknownOddTypes as they don't know them yet.
  • For channels, we disable both of the above. Meaning we don't produce any STXO commitments and we don't use V1 proofs either. Doing so unilaterally would result in a mismatch in signatures and force closures. Which means we'll need a specific upgrade plan for channels in the future.

Copy link
Member

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the above comment and a (hopefully) green CI, I approve this PR. Great work, super happy to finally see this getting over the finish line.

@gijswijs gijswijs requested a review from Roasbeef May 19, 2025 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 👀 In review
Development

Successfully merging this pull request may close these issues.

6 participants