Safrole STF Test Vectors (GP Section 6) - Update

[davxy]

README

---

• Pedersen signature "blinding factor", which is used for ring-proof computation, is now also used to compute one of the two nonces used internally by Pedersen signature. https://github.com/davxy/bandersnatch-vrfs-spec/blob/993ed7304bde1fc2c6853c2f1fa50a3a9da7e062/specification.md?plain=1#L251-L252
  This in turn generates a different ring signature for the tickets.
• Offenders within the Input
  • Propose at least a test vector using the offenders list
• JAM Codec (*.bin files)
• Delete *.scale vectors (old compact)

---

NOTE

This is not critical for the test-vectors correctness as the aforementioned nonce is supposed to be (pseudo-)random and secret (i.e., only known to the prover). Follows that the old ring signatures are still valid wrt to the verification procedure.
But IMO is better to keep the test vectors aligned to what is currently generated by the reference implementation.

[davxy]

Added "Offenders" STF input (ref GP 0.3.1, eq. 58, 59).
Currently not used by the provided vectors (some additional vectors with offenders will be provided soon)

[emielsebastiaan]

One suggestion for a complementary test vector is the case of including a set of 17 tickets during the lottery phase.
This would cover GP-0.3.6-eq:74 (|E_T|<=K).
This would result in a not yet covered error.

[ggwpez]

Graymatter client passes all updated JSON tests (did not try the Codec stuff yet, but other CODEC stuff passes). Some comments:

• It looks like the tiny contest duration is 10 blocks, but i dont see this mentioned in the README.
• From what i understood, the keys that are passed to the ring setup need to use the padding point, but the ones that make it into the SAFROLE state should use zero.
• The punish test revealed mistakes in our implementation. Thanks for adding it.

[ggwpez]

These tests also use tickets_per_validator = 2 , or?
It just occurred to me now that this implies that 2/3+1 majority does not lead to a successful contest anymore, since (6*(2/3)+1) * 2 = 10, missing two tickets.
Maybe we should increase the tickets per validator to three for the tiny spec?

I will post the final numbers onto the jamchain website to have the unambiguous for all future tests, currently we have this.