bip: test vector creation

[Roasbeef]

One final thing we want to do before we request the final BIP number sis request test vectors for all the relevant sub-BIPs.

I think one way we can automate a lot of this is leverage our existing TDD tests: they're all already induvidual test vectors, so we can add a new -json flag to output them in a formatted JSON output (written to a file).

This is a master tracking issue to keep track of all the test vectors we'd want to add:

Test Vector Checklist

• asset TLV encoding

• addr encoding

• proof file encoding

• VPSBT encoding

• positive + negative tests for VM validation

• positive + negative tests for proof validation

• MS-SMT tree tests

  • creation from canned leaf (hash check to match)
  • overflow detection
  • proof compression + decompression
  • inclusion proof validation
  • exclusion proof validation

[guggero]

Adding some thoughts on this before starting work.

Format

Should we use inline test vectors as text (JSON) in the mediawiki documents or link to one or more JSON files in the repo?
=> Actual downloadable JSON files have a lot of advantages, can be turned into unit tests directly.

Proposed general JSON format (taking the MuSig2/BIP-0327 vectors as a template/inspiration):

{
    "shared_data_items": [
      "item 0",
      "item 1",
      "item 2",
      "item 3",
     ],
    "valid_test_cases": [
        {
            "shared_data_items_indices": [0, 1],
            "expected": "abc",
            "comment": "Foo bar baz",
        },
        {
            "shared_data_items_indices": [2, 3],
            "expected": "def",
            "comment": "Bar"
        }
    ],
    "error_test_cases": [
        {
            "shared_data_items_indices": [0, 4],
            "error": "invalid_pubkey",
            "comment": "Public key invalid",
            "tapd_err": "invalid public key: unsupported format"
        },

Content

Where we don't already have unit tests where we can add code to export the test vectors as JSON files, we should make sure we cover at least the following states:

• Minimal/empty set (e.g. minimal required values for an asset or vPSBT or empty MS-SMT)
• Maximal/full set (e.g. all values set on an asset or vPSBT)
• Examples for invalid values
• Positive/valid examples for different types (e.g. normal vs. collectible assets, grouped vs non-grouped assets, interactive vs. non-interactive vPSBTs)

Back-porting test vectors to unit tests

Once we have generated JSON test vectors from existing unit tests (or manually where not possible), it would make sense to then start using the test vectors for the unit tests as well, potentially replacing the original tests with the file/vector based ones.

Suggested task division

Suggesting to split the tasks in the initial issue body in the following way:
@guggero: asset TLV encoding, addr encoding, proof file encoding, vPSBT encoding
@ffranr: VM validation, proof file validation, ms-smt tests

[ffranr]

Thanks for sharing you plan Oli, it all sounds reasonable to me.

I think that file based JSON makes more sense than inline. I'll try to find example test code for handling these JSON specifications.

[Roasbeef]

or more JSON files in the repo?

Actual files IMO. I also like that format from the musig2 BIP, I helped to generate some of those initial vectors using the contents of this commit: btcsuite/btcd@1da361b. So you add a flag, that optionally writes out to json.

[dstadulis]

Fixed by #326