tapfreighter: don't send proofs for tombstones, remove tombstones and burns from commitments #556
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
Roasbeef
reviewed
Oct 9, 2023
guggero
force-pushed
the
tombstone-proof-delivery
branch
from
b1a7c70
to
d4a2b8f
Compare
guggero
changed the title
ffranr
approved these changes
Oct 10, 2023
| @@ -452,18 +452,14 @@ func (c *TapCommitment) Merge(other *TapCommitment) error { | |||
|
|
|||
| // Otherwise, we'll need to merge the other asset commitments into | |||
| // this commitment. | |||
| for key, otherCommitment := range other.assetCommitments { | |||
| existingCommitment, ok := c.assetCommitments[key] | |||
| for key := range other.assetCommitments { | |||
There was a problem hiding this comment.
key might not be the correct variable name after this change. I think it's an index now. Should we just use i instead?
There was a problem hiding this comment.
No, key is still correct IMO, since assetCommitments is a map, not a slice.
Because grouped assets will have the same Tap level key, the NewTapCommitments function will overwrite all grouped assets one after each other instead of merging them. So we use the more easy to use FromAssets function instead. We'll fix the behavior of NewTapCommitments in the next commit.
This commit fixes an issue with the NewTapCommitment function which used to overwrite asset commitments if they had the same Taproot Asset commitment key (which is true for grouped assets for example).
The AssetCommitment had a field called AssetID that was quite confusing and misleading because for grouped assets this would be the hashed group key instead of the asset ID. To make the use of the field more clear and to avoid bugs (and actually fix a bug in a test), we rename the field to TapKey.
Don't attempt to send proofs for tombstone outputs.
We called ParseAndSetDebugLevels too early, so the log level config/CLI flag didn't have any effect. Also, we're going to add some trace statements to the tapscript package in the next commit, so we prepare by adding a package logger.
This is an area that is frequently visited when debugging commitment based problems. To improve clarity on some of the variable names, we perform a series of renames. We also add in some trace level log statments. This commit does NOT change any behavior in the code (other than logging).
This fixes a bug that we only discovered after sending assets many times back and forth. We didn't properly remove tombstones and burns from the commitments when creating new outputs. We did have tests that sent passive assets out from a commitment that had a tombstone. But we never spent that second output, which would have discovered the bug earlier. We'll fix this with a new integration test case in the next commit.
guggero
force-pushed
the
tombstone-proof-delivery
branch
from
d4a2b8f
to
99fc3e4
Compare
jharveyb
approved these changes
Oct 10, 2023
This test reproduced the bug fixed in the previous commit and now confirms the fix is working. This test also asserts the fix for the problem with attempting to deliver a proof for a tombstone that was done in an earlier commit.
guggero
force-pushed
the
tombstone-proof-delivery
branch
from
99fc3e4
to
b1084e8
Compare
Roasbeef
approved these changes
Oct 10, 2023
| for _, asset := range assets { | ||
| asset := asset | ||
| assetCommitments := make(AssetCommitments, len(newCommitments)) | ||
| for idx := range newCommitments { |
There was a problem hiding this comment.
Don't need to do this any longer, but does't hurt.
| @@ -474,12 +470,7 @@ func (c *TapCommitment) Merge(other *TapCommitment) error { | |||
|
|
|||
| // With either the new or merged asset commitment obtained, we | |||
| // can now (re-)insert it into the Taproot Asset commitment. | |||
| existingCommitmentCopy, err := existingCommitment.Copy() | |||
There was a problem hiding this comment.
IIRC we started to do this mainly as a precautionary mechanism.
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.
Don't attempt to send proofs for tombstone outputs.
This wasn't discovered before because we don't have the proof courier enabled by default in all our integration tests.
EDIT: I pulled in the bug fix commits from #553 since it makes more sense to have them all bundled in the same PR.
So this PR now contains all fixes for bugs recently discovered and the unit or integration test to cover them.