Seonpyo Kim

[kcov](https://github.com/SimonKagstrom/kcov) does not help and the repository is too old.

[tarpaulin](https://github.com/xd009642/tarpaulin) is much better. Even though the `cargo test --all` passes successfully, tarpaulin gives error like ``` test consensus::validator_set::dynamic_validator::tests::validator_set ... Error: "Failed to get test coverage! Error: Failed to run...

grcov finally works with ``` RUSTFLAGS="-Zprofile -Ccodegen-units=1 -Cinline-threshold=0 -Clink-dead-code -Coverflow-checks=off -Zno-landing-pads" cargo +nightly test --all; zip -0 ccov.zip `find . \( -name "codechain*.gc*" \) -print`; grcov ccov.zip -s . -t...

But still It counts test functions' lines, I need to study more about ignore test functions from counting.

Related codes are here: [dynamic_validator](https://github.com/CodeChain-io/codechain/blob/d830be0407d1b33f3b792ce3afb01603a3aead5d/core/src/consensus/validator_set/dynamic_validator.rs#L165) [validator_list](https://github.com/CodeChain-io/codechain/blob/d830be0407d1b33f3b792ce3afb01603a3aead5d/core/src/consensus/validator_set/validator_list.rs#L96)

The two usages above are the all usages so assignees can rename it with more descriptive one

We planned to implement key aggregation with the `naive` scheme discussed in (https://blockstream.com/2018/01/23/en-musig-key-aggregation-schnorr-signatures/). The problem of the `naive` scheme was that proving the actual possession of their private keys corresponding...

Secondly, we don't want to modify the previous generation of the Schnorr signature, but just want to aggregate it when it is stored in the header of the next proposal...

Our current Schnorr single signature generation scheme is now hashing (`R` || `m`) (`R` denotes a public random nonce, `m` denotes a message) already. It is hashed inside of the...

Without `R`, the situation will be turned into a disaster. For Schnorr signatures, hashing `R` is the means of proving the ownership of random nonce `r`, unlike ECDSA. Let's suppose...