docs: Incorporate validator feedback (#241)

README.md

@@ -34,19 +34,19 @@ The following graphic demonstrates the interconnections between the above progra
 
 ## 2. Installation
 
-#### Prerequisites
+### Prerequisites
 
 This project requires Go version 1.21 or later.
 
 Install Go by following the instructions on
 the [official Go installation guide](https://golang.org/doc/install).
 
-#### Downloading the code
+### Downloading the code
 
 To get started, clone the repository to your local machine from Github:
 
 ```bash
-git clone git@github.com:babylonchain/finality-provider.git
+git clone https://github.com/babylonchain/finality-provider.git
 ```
 
 You can choose a specific version from
@@ -57,7 +57,7 @@ cd finality-provider # cd into the project directory
 git checkout <release-tag>
 ```
 
-#### Building and installing the binary
+### Building and installing the binary
 
 At the top-level directory of the project
 
@@ -80,48 +80,23 @@ export PATH=$HOME/go/bin:$PATH
 echo 'export PATH=$HOME/go/bin:$PATH' >> ~/.profile
 ```
 
-To build without installing,
-
-```bash
-make build
-```
-
-The above command will put the built binaries in a build directory with the
-following structure:
-```bash
-ls build
-    ├── eotsd
-    ├── fpcli
-    └── fpd
-```
-
-Another common issue with compiling is that some of the dependencies have
-components written in C. If a C toolchain is absent, the Go compiler will throw
-errors. (Most likely it will complain about undefined names/types.) Make sure a
-C toolchain (for example, GCC or Clang) is available.  On Ubuntu, this can be
-installed by running
-
-```bash
-sudo apt install build-essential
-```
-
 ## 3. Setting up a finality provider
 
-#### 3.1. Setting up a Babylon Full Node
+### 3.1. Setting up a Babylon Full Node
 
 Before setting up the finality provider toolset,
 an operator must ensure a working connection with a Babylon full node.
 It is highly recommended that operators run their own node to avoid
 trusting third parties. Instructions on how to set up a full Babylon node
-can be found in 
+can be found in
 [the Babylon documentation](https://docs.babylonchain.io/docs/user-guides/btc-timestamping-testnet/setup-node).
 
 The finality provider requires a Babylon keyring with loaded funds to be attached to it
 in order to be able to send transactions to Babylon.
 To setup such a keyring, follow the instructions in
 [the Babylon documentation](https://docs.babylonchain.io/docs/user-guides/btc-timestamping-testnet/getting-funds).
 
-#### 3.2. Setting up the EOTS Manager
+### 3.2. Setting up the EOTS Manager
 
 After a node and a keyring have been set up,
 the operator can set up and run the
@@ -130,7 +105,7 @@ A complete overview of the EOTS manager, its operation, and
 its configuration options can be found in the
 [EOTS Manager page](docs/eots.md)
 
-#### 3.3. Setting up a Finality Provider 
+### 3.3. Setting up a Finality Provider
 
 The last step is to set up and run
 the finality daemon.

docs/eots.md

@@ -2,43 +2,43 @@
 
 ## 1. Overview
 
-The EOTS daemon is responsible for managing EOTS keys,
-producing EOTS randomness, and using them to produce EOTS signatures.
+The EOTS daemon is responsible for managing EOTS keys, producing EOTS randomness, and
+using them to produce EOTS signatures.
 
 **Note:** EOTS stands for Extractable One Time Signature. You can read more about it
 in
 the [Babylon BTC Staking Litepaper](https://docs.babylonchain.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf).
-In short, the EOTS manager produces EOTS public/private randomness pairs.
-The finality provider commits the public part of this pairs to Babylon for
-every future block height that they intend to provide a finality signature for.
-If the finality provider votes for two different blocks on the same height,
-they will have to reuse the same private randomness which will lead to their
-underlying private key being exposed, leading to the slashing of them and all their delegators.
+In short, the EOTS manager produces EOTS public/private randomness pairs. The
+finality provider commits the public part of this pairs to Babylon for every future
+block height that they intend to provide a finality signature for. If the finality
+provider votes for two different blocks on the same height, they will have to reuse
+the same private randomness which will lead to their underlying private key being
+exposed, leading to the slashing of them and all their delegators.
 
 The EOTS manager is responsible for the following operations:
+
 1. **EOTS Key Management:**
     - Generates [Schnorr](https://en.wikipedia.org/wiki/Schnorr_signature) key pairs
       for a given finality provider using the
       [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)
       standard.
-    - Persists generated key pairs in the
-      internal Cosmos keyring.
+    - Persists generated key pairs in the internal Cosmos keyring.
 2. **Randomness Generation:**
     - Generates lists of EOTS randomness pairs based on the EOTS key, chainID, and
       block height.
     - The randomness is deterministically generated and tied to specific parameters.
 3. **Signature Generation:**
-    - Signs EOTS using the private key of the finality provider and the corresponding secret
-      randomness for a given chain at a specified height.
+    - Signs EOTS using the private key of the finality provider and the corresponding
+      secret randomness for a given chain at a specified height.
     - Signs Schnorr signatures using the private key of the finality provider.
 
 The EOTS manager functions as a daemon controlled by the `eotsd` tool.
 
 ## 2. Configuration
 
-The `eotsd init` command initializes a home directory for the EOTS
-manager. This directory is created in the default home location or in a location
-specified by the `--home` flag.
+The `eotsd init` command initializes a home directory for the EOTS manager. This
+directory is created in the default home location or in a location specified by
+the `--home` flag.
 
 ```bash
 eotsd init --home /path/to/eotsd/home/
@@ -52,32 +52,13 @@ ls /path/to/eotsd/home/
   ├── logs       # Eotsd logs
 ```
 
-If the `--home` flag is not specified, then the default home location will
-be used. For different operating systems, those are:
+If the `--home` flag is not specified, then the default home location will be used.
+For different operating systems, those are:
 
 - **MacOS** `~/Users/<username>/Library/Application Support/Eotsd`
 - **Linux** `~/.Eotsd`
 - **Windows** `C:\Users\<username>\AppData\Local\Eotsd`
 
-Below are the `eotsd.conf` file contents:
-
-```bash
-# Default address to listen for RPC connections
-RpcListener = 127.0.0.1:12582
-
-# Type of keyring to use
-KeyringBackend = test
-
-# Possible database to choose as backend
-Backend = bbolt
-
-# Path to the database
-Path = bbolt-eots.db
-
-# Name of the database
-Name = default
-```
-
 ## 3. Starting the EOTS Daemon
 
 You can start the EOTS daemon using the following command:
@@ -86,15 +67,18 @@ You can start the EOTS daemon using the following command:
 eotsd start --home /path/to/eotsd/home
 ```
 
-This will start the rpc server at the address specified in the configuration under
-the `RpcListener` field, which has a default value of `127.0.0.1:12582`.
-You can also specify a custom address using the `--rpc-listener` flag.
+If the `--home` flag is not specified, then the default home location will be used.
+
+This will start the EOTS rpc server at the address specified in `eotsd.conf` under
+the `RpcListener` field, which is by default set to `127.0.0.1:12582`. You can change
+this value in the configuration file or override this value and specify a custom
+address using the `--rpc-listener` flag.
 
 ```bash
 eotsd start
 
-time="2023-11-26T16:35:04-05:00" level=info msg="RPC server listening	{"address": "127.0.0.1:12582"}"
-time="2023-11-26T16:35:04-05:00" level=info msg="EOTS Manager Daemon is fully active!"
+2024-02-08T17:59:11.467212Z	info	RPC server listening	{"address": "127.0.0.1:12582"}
+2024-02-08T17:59:11.467660Z	info	EOTS Manager Daemon is fully active!
 ```
 
 All the available cli options can be viewed using the `--help` flag. These options
@@ -103,5 +87,5 @@ can also be set in the configuration file.
 **Note**: It is recommended to run the `eotsd` daemon on a separate machine or
 network segment to enhance security. This helps isolate the key management
 functionality and reduces the potential attack surface. You can edit the
-`EOTSManagerAddress` in  the configuration file of the finality provider
-to reference the address of the machine where `eotsd` is running.
+`EOTSManagerAddress` in the configuration file of the finality provider to reference
+the address of the machine where `eotsd` is running.