Brought up by @ffranr while reviewing lightninglabs/tap#52:
[x] We should probably store the asset type of the assets in an AssetCommitment, as part of the commitment struct itself, similar to the AssetID or group key. This helps prevent insertion of assets that have a mismatched group key set, which should never happen in practice. Right now the type is looked up by checking against a random asset in the backing CommittedAssets map, which would be overkill in the case of many upserts.
[ ] We may also want to consider a batched version of Upsert that accepts multiple assets and reuses some of the logic is parseCommon.
[ ] Lastly, an IsEqual method for both commitment types would be useful - I think right now we write this manually by computing the tree root and comparing those.
Brought up by @ffranr while reviewing lightninglabs/tap#52:
[x] We should probably store the asset type of the assets in an
AssetCommitment
, as part of the commitment struct itself, similar to theAssetID
or group key. This helps prevent insertion of assets that have a mismatched group key set, which should never happen in practice. Right now the type is looked up by checking against a random asset in the backingCommittedAssets
map, which would be overkill in the case of many upserts.[ ] We may also want to consider a batched version of
Upsert
that accepts multiple assets and reuses some of the logic isparseCommon
.[ ] Lastly, an
IsEqual
method for both commitment types would be useful - I think right now we write this manually by computing the tree root and comparing those.