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:
|
// TODO(jhb): replace full proof fetch with |
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]
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
assetstable.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]