You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1233 , we add logic to look up the altLeaves used for an anchor input, during coin selection. This must be looked up separately from assets, since altLeaves are not stored in the assets table.
Right now this is done by fetching the whole input proof, decoding only the last proof, and then reading the altLeaves from there:
This implementation works, but could cause performance issues as the total input proof size grows. That potential issue is something we also wouldn't detect in our itests, as-is.
Proposed Enhancement
A better option would be:
Add new DB table to track the outpoint -> altLeaves mapping.
Consequently, We could then look up the altLeaves directly and never decode the input proof in this DB transaction.
Since we're dealing with P2TR tx's, I think using the outpoint as the unique key for storage should be fine; it also wouldn't change in the case of re-orgs.
[edit by maintainer]
The text was updated successfully, but these errors were encountered:
In #1233 , we add logic to look up the altLeaves used for an anchor input, during coin selection. This must be looked up separately from assets, since altLeaves are not stored in the
assets
table.Right now this is done by fetching the whole input proof, decoding only the last proof, and then reading the altLeaves from there:
taproot-assets/tapdb/assets_store.go
Line 2171 in f49820f
This implementation works, but could cause performance issues as the total input proof size grows. That potential issue is something we also wouldn't detect in our itests, as-is.
Proposed Enhancement
A better option would be:
Consequently, We could then look up the altLeaves directly and never decode the input proof in this DB transaction.
Since we're dealing with P2TR tx's, I think using the outpoint as the unique key for storage should be fine; it also wouldn't change in the case of re-orgs.
[edit by maintainer]
The text was updated successfully, but these errors were encountered: