common/test: don't use an empty note field in test vectors.
What changed, and why it matters
This commit only updates a test program that prints sample data for BOLT12 invoice proofs. It changes the test to leave the optional 'note' field blank (NULL) instead of using an empty string, matching a recent specification change that says the field may be omitted when empty. There is no change to production code, no security fix, and no vulnerability.
No security action needed. Treat as a normal test-maintenance commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff modifies common/test/run-bolt12_proof_vectors.c, a unit-test vector generator for BOLT12 invoice proof paths. The generate_valid_vector() helper now conditionally prints the JSON “note” member only when note is non-NULL, and several call sites pass NULL instead of “”. This aligns test output with the BOLT12 rule that writers MAY omit an empty note field. No runtime, parsing, or cryptographic logic in Core Lightning is changed.
Changed components
common/test/run-bolt12_proof_vectors.cInspect captured patch +6 / −5
diff --git a/common/test/run-bolt12_proof_vectors.c b/common/test/run-bolt12_proof_vectors.c
index 4e79d760..ce535200 100644
--- a/common/test/run-bolt12_proof_vectors.c
+++ b/common/test/run-bolt12_proof_vectors.c
@@ -189,7 +189,8 @@ static void generate_valid_vector(const char *name,
tal_hexstr(tmpctx, invoice_wire, tal_bytelen(invoice_wire)));
printf("\"preimage\":\"%s\",\n",
tal_hexstr(tmpctx, preimage->r, sizeof(preimage->r)));
- printf("\"note\":\"%s\",\n", note);
+ if (note)
+ printf("\"note\":\"%s\",\n", note);
printf("\"invoice_fields\":[\n");
print_fields_json(inv->fields, tal_count(inv->fields), include_field, NULL);
printf("]\n");
@@ -540,7 +541,7 @@ int main(int argc, char *argv[])
assert(inv);
printf("\"valid_vectors\":[\n");
- generate_valid_vector("full_disclosure", inv, &preimage, 'B', "", include_all, false);
+ generate_valid_vector("full_disclosure", inv, &preimage, 'B', NULL, include_all, false);
printf(",\n");
/* For the rest, remove features and experimental field: keep it vanilla */
inv->invoice_features = tal_free(inv->invoice_features);
@@ -553,7 +554,7 @@ int main(int argc, char *argv[])
inv = invoice_decode(tmpctx, invstr, strlen(invstr), NULL, NULL, &fail);
assert(inv);
- generate_valid_vector("minimal_disclosure", inv, &preimage, 'B', "",
+ generate_valid_vector("minimal_disclosure", inv, &preimage, 'B', NULL,
include_minimal, false);
printf(",\n");
generate_valid_vector("with_note", inv, &preimage, 'B', "test note",
@@ -564,13 +565,13 @@ int main(int argc, char *argv[])
* is entirely omitted, so its subtree hash appears in proof_missing_hashes AFTER
* the hash for the adjacent type82 leaf (which shares the same 4-leaf subtree
* and is resolved first during DFS). */
- generate_valid_vector("left_subtree_omitted", inv, &preimage, 'B', "",
+ generate_valid_vector("left_subtree_omitted", inv, &preimage, 'B', NULL,
include_amount, false);
printf(",\n");
/* This vector demonstrates that proof_omitted_tlvs present with length 0 is
* accepted identically to the field being absent. The spec says writers MAY
* omit the field when empty, so readers must accept both forms. */
- generate_valid_vector("empty_proof_omitted_tlvs_explicit", inv, &preimage, 'B', "",
+ generate_valid_vector("empty_proof_omitted_tlvs_explicit", inv, &preimage, 'B', NULL,
include_all, true);
printf("\n],\n");
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.