Update readmes

Author: ImplOfAnImpl

README.md

@@ -2,8 +2,6 @@
 
 Welcome to the official Github repository for Mintlayer, an innovative, open-source blockchain project. For detailed technical insights, we recommend visiting our [documentation](https://docs.mintlayer.org/).
 
-Please note, the code in this repository is currently under active development. Consequently, it should not be deemed production-ready. Nonetheless, you're invited to test the code in our active testnet environment.
-
 ## Security
 
 Discovered a potential security issue? We urge you to contact us directly at security@mintlayer.org. When reporting, please encrypt your report using Ben's GPG key which can be found [here](https://www.mintlayer.org/assets/keys/ben).
@@ -54,24 +52,26 @@ You can either keep running the code from source, using `cargo run --release --b
 
 ### Running software and how to control logging
 
-The logging of mintlayer-core is configured via the `RUST_LOG` environment variable. All log messages are printed to the terminal screen; we prefer simplicity over complicated log machinery. For example, to see all logs of the `info` level and above (the default level for normal operation), you can run the node with `RUST_LOG=info cargo run --bin node-daemon -- testnet`. If you're facing an issue, it's recommended to use `RUST_LOG=debug` instead. We recommend using these commands that not only print the logs on the screen, but also write them to a file in case you face an issue. On Linux, this can be achieved using `tee` as shown below.
+Normally, the logging of mintlayer-core is configured via the `RUST_LOG` environment variable and all log messages are printed to the terminal screen. For example, to see all logs of the `info` level and above (the default level for normal operation), you can run the node with `RUST_LOG=info cargo run --bin node-daemon -- testnet`. If you're facing an issue, it's recommended to use `RUST_LOG=debug` instead. We recommend using the commands that not only print the logs on the screen, but also write them to a file in case you face an issue. On Linux, this can be achieved using `tee` as shown below.
 
 If the `RUST_LOG` environment variable is not specified, the log level `info` will be used by default.
 
+Additionally, independent of what is printed to the console, node's logs may also be automatically written to the data directory (on Linux, they will be inside `~/.mintlayer/mainnet/logs/` and `~/.mintlayer/testnet/logs/` for mainnet and testnet respectively); this is controlled by the `--log-to-file` option (e.g. `--log-to-file true`), which is accepted by both node-daemon and node-gui. By default, its value is false for node-daemon and true for node-gui. The log files are rotated based on size, so older logs will be automatically deleted eventually. Also note that the log level used in this case is always `info`, regardless of the value of `RUST_LOG`.
+
 Here are the commands as recommended for different scenarios:
 
 #### Assuming you're using the source code
 
-Every release has a tag and a release branch. Make sure you checkout the release you need. For example, if you need v0.5.1, you should first run the following to check out the release branch:
+Every release has a tag and a release branch. Make sure you checkout the release you need. For example, if you need v1.0.0, you should first run the following to check out the release branch:
 
 ```sh
-git checkout release-v0.5.1
+git checkout release-v1.0.0
 ```
 
 or to checkout the tag:
 
 ```sh
-git checkout tags/v0.5.1
+git checkout tags/v1.0.0
 ```
 
 Release branches are more recommended than tags, because they get necessary security patches, if any. Tags are just markers.
@@ -156,11 +156,16 @@ cargo build --bin wallet-cli --target=aarch64-unknown-linux-gnu --release
 
 The artifacts can be found in `target/aarch64-unknown-linux-gnu/release`, or a similar directory name.
 
-
 ## Wallets
 
 For more information about the wallets and their usage, [visit this readme file](wallet/README.md).
 
+## Trezor support
+
+Mintlayer wallets support Trezor hardware wallets, though it's still in Beta at this moment.
+
+For details, [visit this readme file](wallet/TREZOR_SUPPORT.md).
+
 ## The API server
 
 The API server is a tool for indexing the blockchain. Its source code is contained in this repository and its [readme can be found in its directory](api-server/README.md).

api-server/README.md

@@ -4,7 +4,7 @@
 
 The Mintlayer API server is a tool that scans the blockchain and publishes its data in a database for easy access. Technically speaking, this is done to achieve the trade-off where the blockchain itself contains the minimal required amount of data, while the API server indexes all the data for easy reach. The API server is used by block explorers and web wallets. The API server is made to be usable in many ways, including in exchanges, by people interested in writing tooling for the blockchain, or anything else.
 
-For example to understand what problem the API server solves, the node software only stores blocks of the blockchain, but it does not index the transactions by their id. Meaning: Attempting to find a transaction by its id is virtually impossible without going through all blocks. This same applies to more information that's not directly, minimally, required to operate the blockchain. In that case, using the API server solves all these problems, since the API server is made to index the information and put it in the database.
+For example to understand what problem the API server solves, the node software only stores blocks of the blockchain, but it does not index the transactions by their id. Meaning: Attempting to find a transaction by its id is virtually impossible without going through all blocks. The same applies to more information that's not directly, minimally, required to operate the blockchain. In that case, using the API server solves all these problems, since the API server is made to index the information and put it in the database.
 
 ## Architecture
 

build-tools/linux-systemd-service/README.md

@@ -7,7 +7,7 @@ Note: If you're running mintlayer in your home or behind a consumer router, thes
 
 Also, there are managed services that do this for you, but they're more expensive. We never had to use any of them, but it's up to you. One that comes to mind is Plesk. It's made to make server management easier. But it's not free.
 
-1. NEVER run mintlayer software as root or a user that has access to root. It's preferable to create a separate user for this
+1. NEVER run mintlayer software as root or a user that has access to root. It's preferable to create a separate user for this.
 2. NEVER keep all your server ports open. This is a huge security flaw that can endanger both your server and make stealing your coins easy. Mintlayer needs only port 13031 (testnet p2p) or 3031 (mainnet p2p). All other ports (maybe besides ssh) should be blocked by a firewall.
 3. DO NOT allow public access to RPC (port 13030 for testnet, 3030 for mainnet). RPC basically gives full control and it's meant for the owner.
 4. DO NOT bind RPC to 0.0.0.0 unless you know what you're doing. The correct way to reach your RPC is with an ssh tunnel, not by opening the RPC to the public.

rpc/README.md

@@ -51,7 +51,7 @@ for example, to get the current state of chainstate
 as another example, since this is websocket, you can also subscribe to events. So to do that, send the function:
 
 ```
-{"jsonrpc": "2.0", "method": "chainstate_subscribe_events", "params":[{}], "id": 1}
+{"jsonrpc": "2.0", "method": "chainstate_subscribe_to_events", "params":[{}], "id": 1}
 ```
 
 which will return a confirmation with a result. Then, the node will notify you for events, like new blocks becoming the chainstate tip.

wallet/README.md

@@ -8,7 +8,7 @@ We assume here that you already have a mintlayer node running as a daemon. If yo
 
 ### How are wallets stored?
 
-Our wallets use BIP-39 for deriving a master key from seed words. It also uses BIP-32 for deriving child keys, and finally BIP-44 is used for path derivation. The path is `m/44'/'19788/'0/0/0` for mainnet and `m/44'/'1/'0/0/0` for testnet.
+Our wallets use BIP-39 for deriving a master key from seed words. They also use BIP-32 for deriving child keys, and finally BIP-44 is used for path derivation. The path is `m/44'/'19788/'0/0/0` for mainnet and `m/44'/'1/'0/0/0` for testnet.
 
 Wallets load the 12- or 24-word seed (and possibly the passphrase as well), then follow the above-mentioned standards for key derivation.
 

wallet/TREZOR_SUPPORT.md

@@ -0,0 +1,145 @@
+## Using Mintlayer with Trezor
+
+In order to use a Trezor device with Mintlayer, you'll have to:
+- Flash the device with custom firmware provided by Mintlayer.
+- Use one of the Mintlayer Core wallets - node-gui or wallet-cli. I.e. Trezor Suite won't be able to see your ML coins. Also, at this moment Mojito wallet doesn't support Trezor either, though there are plans to add the support in the future.
+
+Note: Core wallets still require you to create a wallet file on your computer. In this case though only public keys will be kept in the wallet file (unless you explicitly add a standalone private key to it). Also note that you have to create a separate wallet file for each device/passphrase combination.
+
+### Caveats
+
+From the Trezor perspective, there are two types of firmware: a) the official one, signed by Trezor and perfectly safe to use; b) custom-built one, potentially unsafe to use.
+
+Since Mintlayer is not officially supported by Trezor, the firmware we provide falls into the latter category. This has certain implications:
+- When installing the firmware, the device will show the warning "UNSAFE, DO NOT USE!".
+- When installing custom firmware over the official one, **the device will be wiped clean**. Make sure you have a backup of your seed phrase.
+- When installing custom firmware over different custom firmware, the device will **not** be wiped clean. This makes it succeptible to the so-called "evil maid attack",
+where the attacker has physical access to your device. It goes like this:
+  * The "maid" temporarily steals your device and installs on it firmware that she has built herself; it looks identical to the previously installed firmware, but also logs the PIN and the passphrase entered by the user. Then she puts the device back.
+  * You use the device.
+  * She steals the device again and can now extract the logged PIN and passphrase. Moreover, knowing the PIN and being able to flash arbitrary firmware, she can now extract the seed phrase as well. So now she can either steal your coins right away or
+  simply put the device back and wait until you accumulate more of them.
+
+  So:
+  * keep your device in a safe place;
+  * preferably, use a dedicated device with a dedicated seed phrase and PIN specifically for Mintlayer;
+- In order to install custom firmware on a Trezor Safe family device (e.g. Safe 3 or Safe 5), you have to [unlock the bootloader first](https://trezor.io/learn/security-privacy/how-trezor-keeps-you-safe/unlocking-the-bootloader-on-trezor-safe-devices);
+this is an irreversible operation after which the device authenticity check will no longer work. This means that every time you use Trezor Suite, you will be presented with a warning "Your device may have been compromised" (unless you disable
+the authenticity check in the Trezor Suite's device settings).
+
+### Building and flashing the firmware
+
+#### A note about versioning
+
+Firmware built from the Mintlayer fork has two version numbers:
+- A version number assigned by Trezor; this is the original release that we've based our release upon
+  and this is what is shown to you on the device screen when you flash the firmware.
+- An additional version number assigned by us, to which we refer as "Mintlayer firmware version".
+  It is obtainable via `trezorctl mintlayer get-firmware-info` and it's what
+  our wallets display in their UI.
+
+The table of correspondence between the two versions can be found in the [firmware repository](https://github.com/mintlayer/mintlayer-trezor-firmware/blob/mintlayer-master/README.md).
+
+The Mintlayer firmware version determines the compatibility between the firmware and the Core wallets:
+
+| Mintlayer Core version | Required Mintlayer firmware version |
+| ---                    | ---                                 |
+| 1.1.0                  | 1.x.x                               |
+
+Note: if you've built Core wallets directly from `master` instead of using a specific release,
+you'll probably won't be able to use a specific release for the firmware either.
+Instead, you'll have to build it from `mintlayer-master`.
+
+#### How to build
+
+##### Get the source code
+
+Clone the repository and `cd` into it:
+```sh
+git clone --recurse-submodules https://github.com/mintlayer/mintlayer-trezor-firmware
+cd mintlayer-trezor-firmware
+```
+
+Then checkout the required revision:
+- If you want the latest version that is in development, checkout the `mintlayer-master` branch:
+  ```sh
+  git checkout --recurse-submodules mintlayer-master
+  ```
+- If you want a particular release, checkout the tag corresponding to that release. The list of tags
+  can be found [here](https://github.com/mintlayer/mintlayer-trezor-firmware/tags).
+  Assuming that you've chosen `mintlayer-v1.0.0`, run:
+  ```sh
+  git checkout --recurse-submodules mintlayer-v1.0.0
+  ```
+
+##### Install `Nix`
+
+On a Debian-based system you can do this via `sudo apt install nix-bin`.
+
+Check that `Nix` works by running `nix-shell -p hello --run hello`
+
+If you're getting the error `getting status of /nix/var/nix/daemon-socket/socket: Permission denied`
+on your Linux machine, you may need to add the current user to the `nix-users` group:
+```sh
+sudo usermod -aG nix-users your_username
+```
+You'll also need to re-login after that.
+
+If you're getting the error `file 'nixpkgs' was not found in the Nix search path`, add
+the `nixpkgs` channel by running:
+```sh
+nix-channel --add https://nixos.org/channels/nixos-25.05 nixpkgs
+nix-channel --update
+```
+
+Run `nix-shell -p hello --run hello` again. If everything is ok, it should print `Hello, world!`.
+
+##### Install required Python dependencies via `Poetry`
+
+```sh
+nix-shell --run "poetry install"
+```
+
+##### Build the firmware
+
+Run:
+
+```sh
+TREZOR_MODEL=T3T1 nix-shell --run "poetry run make -C core vendor build_firmware"
+```
+
+The value of the `TREZOR_MODEL` env variable determines the target device which the firmware will be built for.
+The possible values are:
+| TREZOR_MODEL value | Device model      |
+| ---                | ---               |
+| T2T1               | Model T           |
+| T2B1               | Safe 3 revision A |
+| T3B1               | Safe 3 revision B |
+| T3T1               | Safe 5            |
+
+Note:
+- Trezor Safe 3 revision A and B look identical. To determine the revision of your particular device,
+  first connect the device (which means, both connect it physically and enter the PIN) and then run:
+  ```sh
+  nix-shell --run "poetry run trezorctl get-features"
+  ```
+  Look for the `internal_model` value in the output.
+- Trezor Model One is not supported.
+
+##### Flash the firmware
+
+First you need to put your device into bootloader mode. To do so
+- On Safe 3, hold the left button when connecting the USB cable.
+- On Model T and Safe 5, swipe across the screen when connecting the USB cable.
+
+After that the device will present you with an option to install firmware, select that option.
+
+Now you can flash the firmware by running:
+```sh
+nix-shell --run "poetry run make -C core upload"
+```
+
+Note: instead of executing `nix-shell --run "poetry run the_command"` every time, you can enter
+the nix-shell by running `nix-shell`
+and then inside the nix-shell enter poetry shell by running `poetry shell`.
+After this, you can run the commands directly, e.g. `trezorctl get-features`.

wallet/wallet-rpc-daemon/README.md

@@ -28,10 +28,10 @@ Using `curl` over HTTP (replace all caps placeholders as appropriate):
 curl -H 'Content-Type: application/json' -d '{"jsonrpc": "2.0", "id": ID, "method": METHOD, "params": [PARAM1, PARAM2, ...]}' http://USER:PASS@HOST:PORT
 ```
 
-for example, to get the balance of account with index 0 from an open wallet, with RPC, assuming authentication is disabled
+for example, to get the balance of account with index 0 from an open wallet, counting only confirmed UTXOs, assuming authentication is disabled
 
 ```sh
-curl -H 'Content-Type: application/json' -d '{"jsonrpc": "2.0", "id": 1, "method": "account_balance", "params": {"account": 0}}' http://127.0.0.1:3034
+curl -H 'Content-Type: application/json' -d '{"jsonrpc": "2.0", "id": 1, "method": "account_balance", "params": {"account": 0, "utxo_states": ["Confirmed"]}}' http://127.0.0.1:3034
 ```
 
 For websocket, you can use `websocat` (replace all caps placeholders as appropriate):
@@ -49,7 +49,7 @@ and then type in the method invocations one per line in the following format:
 for example, to get the balance of account with index 0 from an open wallet, with RPC
 
 ```
-{"jsonrpc": "2.0", "id": 1, "method": "account_balance", "params": {"account": 0}}
+{"jsonrpc": "2.0", "id": 1, "method": "account_balance", "params": {"account": 0, "utxo_states": ["Confirmed"]}}
 ```
 
 as another example, since this is websocket, you can also subscribe to events. So to do that, send the function:
@@ -83,7 +83,7 @@ The mechanism to subscribe to and to deliver events follows the [Ethereum pubsub
 However, the emitted events take slightly different shape.
 
 To see how the events are defined in full detail, see the `Event` type
-in [src/service/events.rs](src/service/events.rs).
+in [events.rs](/wallet/wallet-rpc-lib/src/service/events.rs).
 
 ### NewBlock