Add VoteTally, VoteCast, VotePlan decrypting documentation

[Mr-Leshiy]

No description provided.

[zeegomo]

haven't look at non-vote-cast stuff

[zeegomo]

I think the default should be the ristretto backend where each point is 32 bytes

[Mr-Leshiy]

What do you mean by rsitretto backend ?
here is the represantation of the Cyphertext

/// ElGamal ciphertext. Given a message M represented by a group element, and ElGamal
/// ciphertext consists of (r * G; M + r * `PublicKey`), where r is a random `Scalar`.
pub struct Ciphertext {
    pub(crate) e1: GroupElement,
    pub(crate) e2: GroupElement,
}
...
impl Ciphertext {
    /// Size of the byte representation of `Ciphertext`.
    pub const BYTES_LEN: usize = GroupElement::BYTES_LEN * 2;

chain-libs/chain-vote/src/cryptography/elgamal.rs

Line 230 in 47db07a

pub const BYTES_LEN: usize = GroupElement::BYTES_LEN * 2;

So it seems to be 65 bytes for each point.

[zeegomo]

A group element could either be a point on the secp256k1 curve (like Bitcoin) or points on the Ristretto group for Curve25519 (it's a feature flag of chain-vote IIRC). The former has a 65 bytes encoding, the latter 32. The default should be ristretto for both speed and size.

[Mr-Leshiy]

But how and where could it be configured?
Maybe I missed something but I am see only a hardcoded version of GroupElement.

chain-libs/chain-crypto/src/ec/p256k1.rs

Line 13 in dcb1fb7

pub struct GroupElement(Point);

chain-libs/chain-vote/src/cryptography/zkps/unit_vector/messages.rs

Line 57 in dcb1fb7

pub struct Announcement {

[zeegomo]

there is one here as well

chain-libs/chain-crypto/src/ec/ristretto255.rs

Line 24 in dcb1fb7

pub struct GroupElement(Point);

. One of those is re-exported inside chain-vote

chain-libs/chain-vote/src/lib.rs

Line 20 in 4876be8

pub(crate) use chain_crypto::ec::ristretto255::*;

.
Default is ristretto

chain-libs/chain-vote/Cargo.toml

Line 31 in 4876be8

default = ["ristretto255"]

.
You can also try with a transaction and check its size :)

[Mr-Leshiy]

Oh my god 😳😳😳So it is configured on the building level.
Will update

[zeegomo]

I think this is 3 group elements as well. Also, we might want to introduce another symbol like GROUP-ELEMENT instead of using SIZE-ELEMENT-32/65BIT, as that might change between builds and the default could be different.
In addition, the encoding of the group element might be useful as well.

[Mr-Leshiy]

You are correct there are 3 items, but Scalars not group elements

[zeegomo]

1. technically this is not a bft signature, although in practice they are equal
2. it also contains the id of the committee member that is signing the transaction

[Mr-Leshiy]

it also contains the id of the committee member that is signing the transaction

Is it not a part of the ED25519-SIGNATURE ?
I thought it should corresponds to the following

UPDATE-PROPOSAL   = PROPOSAL-CERT IOW BFT-SIGNATURE
UPDATE-VOTE       = VOTE-CERT IOW BFT-SIGNATURE

[zeegomo]

I think it's not, BTF-SIGNATURE is just 64 bytes of signature. Look at how this is used in

chain-libs/chain-impl-mockchain/doc/format.abnf

Line 20 in 31fafb4

CONSENSUS-BFT = BFT-LEADER-ID BFT-SIGNATURE

We might need to fix UPDATE-{PROPOSAL, VOTE} if that's the case

[davidmisiak]

LGTM, I haven't tested the call manually. Also, maybe we could add some unit tests (e.g. HashBuilder)?

EDIT: Sorry, wrong tab 😅 Please ignore.