The aim of this section is to establish a common nomenclature to be used among the members of the institute. Our aim is to create a logic and self-consistent nomenclature to help learning.

1. Prime numbers: the lowercase letter p should represent an odd prime number;
2. Fields: for a general field the letter K should be used, while the finite field of order q = p^k, where p is an odd prime and k an integer, should be represented as F_q. For a fixed order q, the finite field F_q is unique up to isomorphisms, i.e. the same field admits different representations. When dealing with F_p we can use the isomorphism with the set of natural numbers modulo p (Z_p);
3. Elliptic curves: in general an elliptic curve is denoted by E(K), which represents the set of points satisfying the generalized Weierstrass equation with coefficients in K plus the point at infinity. Lowercase letters are used to denote scalars, while the uppercase equivalent denotes the linked EC point, e.g. qG = Q = (x_Q, y_Q). The coordinates of an EC point should be represented as in the previous example. For what concerns our purposes K will always be a prime finite field (F_p). In this case we can define an elliptic curve entirely through the so called elliptic curve domain parameters: T = (a, b, p, G, n, h).
   1. a and b defines the Weierstrass equation y^2 = x^3 + ax + b;
   2. p determines the finite field over which the curve is defined E(F_p): y^2 = x^3 + ax + b (mod p);
   3. G is a generator of a cyclic subgroup of E(F_p);
   4. n is the order of the cyclic subgroup determined by G;
   5. h is the so called cofactor, computed as h = |E(F_p)| / n.
4. Whenever a second generator is needed we use the capital letter H: this does not constitute a conflict with the cofactor since typically the two generators are NUMS (nothing up my sleeves), meaning that we do not know the discrete logarithm of one with respect to the other and viceversa;
5. Elliptic curves' key pair: the pair of private and public key should be denoted as {q, Q}, where Q = qG. Whenever a second point is needed we use the couple {r, R}; if more key pairs are needed subscripts should be used, e.g. q_1G = Q_1 = (x_1, y_1), q_2G = Q_2 = (x_2, y_2) and q_3G = Q_3 = (x_3, y_3). Notice that, for the sake of clarity, also the coordinate notations is adapted;
6. Signature algorithms: || denotes concatenation of bytes, the conversion functions should be written extensively (hash(), bytes(), int(), etc.), the cryptographically secure nonce should be denoted by k and the equivalent EC point with K = (x_K, y_K).
   1. ECDSA: {bytes(r), bytes(s)}, where r = x_K (mod n), s = k^{-1}(int(hash(m)) + rq) (mod n) and m is the message to be signed;
   2. Schnorr: {bytes(x_K), bytes(s)}, where s = k + int(hash(bytes(x_K) || bytes(P) || m))q (mod n) and K is made implicit by choosing the one with y_K a quadratic residue. In doing so we are following the BIP by Pieter Wuille; one thing we need to point out is that this requires specifically the secp256k1 curve (or at least a curve for which p = 3 (mod 4)).

Although the signature are always serialized as bytes, for the sake of simplicity we will write {r, s} and {x_K, s}, respectively.