Skip to content
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

[tapdb]: add script key type enum, run Golang based post migration checks #1198

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

guggero
Copy link
Member

@guggero guggero commented Nov 15, 2024

Early draft, CI probably broken.

TODOs:

  • Unit tests
  • Integration tests
  • Align ListAssets and ListBalances RPCs in terms of assets to show
  • Replace "exclude key" mechanism to hide channel funding assets with type based query

cc @GeorgeTsagk: this mechanism can be used to add asset burns to the new table retroactively.

With this commit we add a new numeric type for the type of a script key.
This will be a Golang enum/const that's going to be assigned manually
when declaring a key as known.
For existing keys, we'll add a new mechanism in the following commits
that runs on startup after we detect a SQL migration was applied that
will attempt the detection of the type of those keys.
With this commit we add a type enum to the script key. This will mostly
be used on the database level to filter assets when listing or
calculating balances.
We can only be 100% certain about the type of a key in the case of
BIP-0086 or where we explicitly create them in the tapchannel package.
Anything else is a bit of a guess, since the keys are coming over the
RPC interface. So we just assume any key that has a non-empty script
path is an externally-defined (external app) script spend.

This heuristic should be good enough to filter out channel related
assets or assets that can't be spent without external instructions in
balance RPC calls.
In order for burn keys to be stored with the correct type, we need to
detect them before storing the transfer outputs to the database.
We can't set the script key type before, because we're carrying around
the script key in a virtual packet, where that information isn't
available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🏗 In progress
Development

Successfully merging this pull request may close these issues.

2 participants