P, the committing party "Alice"
A(which may be represented by a single person or some m-of-n federation) and the verifying party "Bob"
B(which may be represented by a single person or some m-of-n federation) need to agree on three parameters:
s, acting as a seed for all protocol-wide commitments, this must be a 8-bit value;
c, which should not be directly reflected in the transaction, containing the given CC. This parameter under some circumstances (agreed by the parties beforehand) may be absent. The value of
cmust be a 8-bit value.
f, as a difference between total transaction output amounts in satoshis and total inputs amounts, in satoshis:
f = sum(outputs) - sum(inputs). This can be done, for instance, by utilizing data from a partially-singed bitcoin transaction, or by contacting Electrum Server or Bitcoin Core backend. It should be noted, that according to Bitcoin consensus rules, this amount must always be positive and greater than zero(
f > 0); otherwise it is not a valid Bitcoin transaction and the protocol must fail.
aas a 32-bit modulo of the potentially-64 bit number
a = f mod 2^32.
cwas not defined, use
cvalue by default). This will give a commitment-factor
x = a + s + c. Since
cis a 8-bit numbers and
ais a 32-bit number, the result will fit a 64-bit number without overflow.
nfor the transaction containing the output with the given cryptographic commitment.
d = x mod n. The
dwill represent an index of the output which must contain a cryptographic commitment. All other transaction outputs will not be a valid outputs for a contain cryptographic commitment under the used protocol.
c. This will still preserve the privacy from the onchain analysis tools due to the presence of the protocol-specific parameter
s, which will be unknown for any party that does know which protocol is used by some transaction (given the fact that the used protocol can't be guessed from the transaction itself).