diff --git a/README.md b/README.md
index 0ae10cb9..d55d86ca 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,378 @@
-This branch is not usable in its current state. Please see [version3](https://github.com/libbitcoin/libbitcoin-server/tree/version3) for the latest functional branch.
+[](https://github.com/libbitcoin/libbitcoin-server/actions/workflows/ci.yml?branch=master)
+[](https://coveralls.io/github/libbitcoin/libbitcoin-server?branch=master)
+
+# libbitcoin-server
+
+*The high performance Bitcoin full node server based on [libbitcoin-node](https://github.com/libbitcoin/libbitcoin-node), [libbitcoin-system](https://github.com/libbitcoin/libbitcoin-system), [libbitcoin-database](https://github.com/libbitcoin/libbitcoin-database), and [libbitcoin-network](https://github.com/libbitcoin/libbitcoin-network).*
+
+
+
+## tl;dr
+This is the **server component of libbitcoin v4**. It integrates the basic components and offers a **high performance Bitcoin full node** with a comprehensive set of client-server interfaces like **bitcoind, electrum and stratum** as well as an intergrated **block explorer**. It makes full use of the available hardware, internet connection and availabe RAM and CPU so you can sync the Bitcoin blockchain from genesis, today and in the future.
+
+If you follow this README you will be able to build, run and monitor your own libbitcoin server (bs). Libbitcoin is a multi platform software that works on Linux, Windows and OSX (Intel and ARM).
+
+Now, If you want to see how fast your setup can sync the Bitcoin Blockchain, read on and get your libbitcoin server running today. It's pretty easy actually.
+
+**License Overview**
+
+All files in this repository fall under the license specified in [COPYING](COPYING). The project is licensed under the [GNU Affero General Public License v3.0](https://www.gnu.org/licenses/agpl-3.0.en.html). It may be used within a proprietary project, but the core library and any changes to it must be published online. Source code for this library must always remain free for everybody to access.
+
+**About libbitcoin**
+
+The libbitcoin toolkit is a set of cross platform C++ libraries for building Bitcoin applications. The toolkit consists of several libraries, most of which depend on the foundational [libbitcoin-system](https://github.com/libbitcoin/libbitcoin-system) library. Each library's repository can be cloned and built separately. There are no packages yet in distribution, however each library includes an installation script (described below) which is regularly verified via [GitHub Actions](https://github.com/features/actions).
+
+## Contents
+- [libbitcoin-server](#libbitcoin-server)
+ - [tl;dr](#tldr)
+ - [Contents](#contents)
+ - [Installation](#installation)
+ - [Linux](#linux)
+ - [Requirements](#requirements)
+ - [Build](#build)
+ - [CPU Extensions](#cpu-extensions)
+ - [macOS](#macos)
+ - [Windows](#windows)
+ - [Running bs](#running-bs)
+ - [Startup Process](#startup-process)
+ - [Logging](#logging)
+ - [Using the console](#using-the-console)
+ - [Performance](#performance)
+ - [Memory Management](#memory-management)
+ - [Kernel VM Tuning Parameters](#kernel-vm-tuning-parameters)
+
+## Installation
+The build process is essentially the same on Linux, macOS, and other Unix-like systems. It differs significantly on Windows due to the use of native Visual Studio projects and solutions. Detailed instructions are provided below.
+
+- [Linux (Ubuntu)](#linux)
+- [macOS](#macos)
+- [Windows](#windows)
+
+### Linux
+
+Linux users can build libbitcoin node with the provided installation script `install.sh` that uses Autotools and pkg-config to first build the needed dependencies (boost, libpsec256) and then fetches the latest libbitcoin projects (libbitcoin-system, libbitcoin-database, libbitcoin-network, libbitcoin-node and libbitcoin-server) from GitHub and builds the stack bottom up to the libbitcoin-server executable - `bs`.
+
+You can issue the following command to check for further parameterization of the install script:
+
+```bash
+$ install.sh --help
+```
+
+which brings up the following options:
+
+```
+Usage: ./install.sh [OPTION]...
+Manage the installation of libbitcoin-server.
+Script options:
+ --with-icu Compile with International Components for Unicode.
+ Since the addition of BIP-39 and later BIP-38
+ support, libbitcoin conditionally incorporates ICU
+ to provide BIP-38 and BIP-39 passphrase
+ normalization features. Currently
+ libbitcoin-explorer is the only other library that
+ accesses this feature, so if you do not intend to
+ use passphrase normalization this dependency can
+ be avoided.
+ --build-icu Build ICU libraries.
+ --build-boost Build Boost libraries.
+ --build-secp256k1 Build libsecp256k1 libraries.
+ --build-dir= Location of downloaded and intermediate files.
+ --prefix= Library install location (defaults to /usr/local).
+ --disable-shared Disables shared library builds.
+ --disable-static Disables static library builds.
+ --help, -h Display usage, overriding script execution.
+
+All unrecognized options provided shall be passed as configuration options for
+all dependencies.
+```
+
+In order to successfully execute `install.sh` a few requirements need to be met. This walkthrough is based on a 'current' installation of the following components. (That doesn't necessarily mean these are the minimum requirements though).
+
+#### Requirements
+* Base OS: Ubuntu 24.04.3 LTS (Noble Numbat)
+* C++13 compiler (gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04))
+* [Autoconf](https://www.gnu.org/software/autoconf/)
+* [Automake](https://www.gnu.org/software/automake/)
+* [libtool](https://www.gnu.org/software/libtool/)
+* [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/)
+* [git](https://git-scm.com/)
+* [curl](https://www.gnu.org/software/curl/)
+
+The corresponding packages can be installed with the following command:
+
+```bash
+$ sudo apt install build-essential curl git autoconf automake pkg-config libtool
+```
+
+#### Build
+Create a new directory (e.g. `/home/user/libbitcoin`), then use git to fetch the latest repository from GitHub by issuing the following command from within this directory:
+
+```bash
+git clone https://github.com/libbitcoin/libbitcoin-server
+```
+
+Enter the project directory `cd libbitcoin-server` and start the build with the following command:
+
+```bash
+$ ./install.sh --prefix=/home/user/libbitcoin/build/release_static/ --build-secp256k1 --build-boost --disable-shared
+```
+
+This will build the libbitcoin-server executable as a static release with no [CPU extensions](#cpu-extensions) built in. Use only absolute path names for prefix dir. A successful build will create the following directory/file structure:
+
+```
+~/bitcoin/libbitcoin/
+~/bitcoin/libbitcoin/build/
+~/bitcoin/libbitcoin/build/release_static/
+~/bitcoin/libbitcoin/build/release_static/bin/
+~/bitcoin/libbitcoin/build/release_static/etc/
+~/bitcoin/libbitcoin/build/release_static/include/
+~/bitcoin/libbitcoin/build/release_static/lib/
+~/bitcoin/libbitcoin/build/release_static/share/
+~/bitcoin/libbitcoin/build/release_static/share/doc/
+~/bitcoin/libbitcoin/build/release_static/share/doc/libbitcoin-database/
+~/bitcoin/libbitcoin/build/release_static/share/doc/libbitcoin-network/
+~/bitcoin/libbitcoin/build/release_static/share/doc/libbitcoin-node/
+~/bitcoin/libbitcoin/build/release_static/share/doc/libbitcoin-server/
+~/bitcoin/libbitcoin/build/release_static/share/doc/libbitcoin-system/
+~/bitcoin/libbitcoin/libbitcoin-node
+```
+Now enter the bin directory and [fire up](#running-bs) your libbitcoin server.
+
+#### CPU Extensions
+CPU Extensions are specific optimizations your CPU might or might not have. libbitcoin(-server) can be built with support for the following CPU extensions if your architecture supports them:
+
+* [SHA-NI](https://en.wikipedia.org/wiki/SHA_instruction_set)
+* [SSE4.1](https://en.wikipedia.org/wiki/SSE4)
+* [AVX2](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions)
+* [AVX512](https://en.wikipedia.org/wiki/AVX-512)
+
+To build libbitcoin-server with these extensions use the `--enable-feature` parameters like:
+
+- --enable-shani
+- --enable-sse41
+- --enable-avx2
+- --enable-avx512
+
+This command will create a static release build with all supported CPU extensions (if supported by the system). Building libbitcoin with unsupported CPU extensions might work but will lead to crashes at runtime.
+
+```bash
+$ CFLAGS="-O3" CXXFLAGS="-O3" ./install.sh --prefix=/home/user/libbitcoin/build/release_static/ --build-dir=/home/user/libbitcoin/build/temp --build-secp256k1 --build-boost --disable-shared --enable-ndebug --enable-shani --enable-avx2 --enable-sse41 --enable-isystem
+```
+
+You can check if the optimizations have been built in your binary with the following command:
+
+```bash
+$ ./bs --hardware
+```
+
+which will show your CPU architecture as well as the built in status of the supported optimizations:
+
+```
+Hardware configuration...
+arm..... platform:0.
+intel... platform:1.
+avx512.. platform:1 compiled:1.
+avx2.... platform:1 compiled:1.
+sse41... platform:1 compiled:1.
+shani... platform:1 compiled:1.
+```
+
+### macOS
+TBD
+
+### Windows
+TBD
+
+## Running bs
+Let's see what options we have for the server:
+
+```bash
+$ ./bs --help
+```
+
+The response should look like this:
+
+```
+Usage: bs [-abdfhiklnrstvw] [--config value]
+
+Info: Runs a full bitcoin server.
+
+Options (named):
+
+-a [--slabs] Scan and display store slab measures.
+-b [--backup] Backup to a snapshot (can also do live).
+-c [--config] Specify path to a configuration settings file.
+-d [--hardware] Display hardware compatibility.
+-f [--flags] Scan and display all flag transitions.
+-h [--help] Display command line options.
+-i [--information] Scan and display store information.
+-k [--buckets] Scan and display all bucket densities.
+-l [--collisions] Scan and display hashmap collision stats (may exceed
+ RAM and result in SIGKILL).
+-n [--newstore] Create new store in configured directory.
+-r [--restore] Restore from most recent snapshot.
+-s [--settings] Display all configuration settings.
+-t [--test] Run built-in read test and display.
+-v [--version] Display version information.
+-w [--write] Run built-in write test and display.
+```
+
+Did you check if all supported [CPU Extensions](#cpu-extensions) are built in (`./bn --hardware`)?
+
+### Startup Process
+
+Starting the server without passing any parameters like
+
+```
+$ ./bs
+```
+
+will do the following:
+- If there is no data store at `./bitcoin/`, the node will create one. The location can be changed in the [config](/docs/configuration.md) file (`bs.cfg`).
+- Start multiple threads to setup peer connections, to download and to process blocks in default mode (milestone sync). See [Theory of operation](/docs/theory-of-operation.md#) for more information about operating modes.
+- Expose an interactive console to do basic communication with the node -> [Using the console](#using-the-console)
+- Write various logfiles -> [Logging](#logging)
+
+Furthermore the standard parameters will perform a **milestone sync** with the Bitcoin Blockchain, as opposed to a **full validation sync**.
+
+Although this works in principle, you may want to do at least a few basic settings. You do this by passing a [config file](/docs/configuration.md) to the node:
+
+```bash
+$ ./bs --config ./bs.cfg
+```
+
+The node will now expect to find a valid [config file](/docs/configuration.md) in the current folder.
+
+Starting a **full validation sync** on the node requires to set the latest milestone block back to genesis. This is done by adding the following lines to the config file:
+
+```
+[bitcoin]
+checkpoint = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
+milestone = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
+```
+
+Further information on how to adjust the config file as well as example configurations can be found [here](/docs/configuration.md).
+
+### Logging
+libbitcoin-server creates the following files at start:
+
+* events.log
+* bs_begin.log (rotated to bs_end.log)
+* hosts.cache
+
+The events.log file records all information about the sync process, providing the current status and speed of the sync. Read [Performance](#performance) to learn how to check your sync speed through the logs.
+
+### Using the console
+Pressing **`m` + Enter** in the terminal will bring up the interactive console. This interface is mainly used for low level logging and configuration and it looks like this:
+
+```
+2025-10-17T23:47:58Z.0 Toggle: [v]erbose
+2025-10-17T23:47:58Z.0 Toggle: [o]bjects
+2025-10-17T23:47:58Z.0 Toggle: [q]uitting
+2025-10-17T23:47:58Z.0 Toggle: [f]ault
+2025-10-17T23:47:58Z.0 Toggle: [r]emote
+2025-10-17T23:47:58Z.0 Toggle: [x]proxy
+2025-10-17T23:47:58Z.0 Toggle: [p]rotocol
+2025-10-17T23:47:58Z.0 Toggle: [s]ession
+2025-10-17T23:47:58Z.0 Toggle: [n]ews
+2025-10-17T23:47:58Z.0 Toggle: [a]pplication
+2025-10-17T23:47:58Z.0 Option: [z]eroize disk full error
+2025-10-17T23:47:58Z.0 Option: [w]ork distribution
+2025-10-17T23:47:58Z.0 Option: [t]est built-in case
+2025-10-17T23:47:58Z.0 Option: [m]enu of options and toggles
+2025-10-17T23:47:58Z.0 Option: [i]nfo about store
+2025-10-17T23:47:58Z.0 Option: [h]old network communication
+2025-10-17T23:47:58Z.0 Option: [g]o network communication
+2025-10-17T23:47:58Z.0 Option: [e]rrors in store
+2025-10-17T23:47:58Z.0 Option: [c]lose the node
+2025-10-17T23:47:58Z.0 Option: [b]ackup the store
+```
+Further information about how to use the interactive console can be found [here](/docs/tbd.md)
+
+### Performance
+You can check your server's performance using the log files. To do this, check the events.log file as follows. Let's check for the **organization** of Block **700,000**. The command
+
+```bash
+$ cat ./events.log | grep 'block_organized..... 700000'
+```
+
+will give you something like this, with the number on the right representing the seconds since the server started until block 700k was organized:
+
+```
+block_organized..... 700000 11053
+```
+
+In this case it took the node 11053 seconds (or 184 minutes) to sync up to Block 700k.
+
+As the node aims to sync the Blockchain as fast as possible, we assume that if the computer is powerful enough, the limiting factor for syncing the chain is your internet connection - you simply can't sync faster than the time needed to download the Blockchain.
+
+The following diagram shows the performance data extracted from various IBDs (bs milestone and full validation, Core 30 Standard and AssumeValid) on a 64 Core, 256MB RAM machine running Ubuntu.
+
+
+brunella - Dell Precision Tower 7810
+
+- Dual Intel® Xeon® CPU E5-2683 v4 @ 2.10 GHz (32 Kerne / 64 Threads)
+- **256 GB** DDR4 ECC Registered (RDIMM)
+- 4 TB SSD Samsung 990 PRO (PCIe Gen4)
+- 2 GBit/s Fiber Internet
+
+
+
+
+
+Check [this](/docs/tbd.md) to learn more about how performance profiling and optimization works.
+
+### Memory Management
+
+In order to improve the performance on your Linux system, you probably have to alter the kernel parameters that determine the memory management of the system ([Memory Paging](https://en.wikipedia.org/wiki/Memory_paging)).
+
+#### Kernel VM Tuning Parameters
+
+These sysctl parameters optimize Linux VM dirty page writeback for high I/O workloads (e.g., databases). Set via `/etc/sysctl.conf` or `sudo sysctl`. This table shows the stock values of the current Ubuntu LTS.
+
+| Parameter | Value | Description |
+|--------------------------------|--------|-------------------------------------------------------------------|
+| `vm.dirty_background_ratio` | `10` | Initiates background writeback at 10% dirty RAM (lowers latency). |
+| `vm.dirty_ratio` | `20` | Blocks apps at 20% dirty RAM (prevents OOM). |
+| `vm.dirty_expire_centisecs` | `3000` | Marks pages "old" after 30s (1/100s units; triggers writeback). |
+| `vm.dirty_writeback_centisecs` | `500` | Wakes kworker every 5s to flush old pages. |
+
+Check your actual kernel parameters by issuing the following command:
+
+```bash
+$ sysctl vm.dirty_background_ratio vm.dirty_ratio vm.dirty_expire_centisecs vm.dirty_writeback_centisecs
+```
+
+The following parameters have been identified to be the most effective for the most computers we use for testing. They basically allow the server process to use as much RAM as possible (90%) and flush the dirty pages after 2 minutes:
+
+* vm.dirty_background_ratio = 90
+* vm.dirty_ratio = 90
+* vm.dirty_expire_centisecs = 12000
+* vm.dirty_writeback_centisecs = 12000
+
+Set them with the following commands:
+
+```bash
+$ sudo sysctl vm.dirty_background_ratio=90
+$ sudo sysctl vm.dirty_ratio=90
+$ sudo sysctl vm.dirty_expire_centisecs=12000
+$ sudo sysctl vm.dirty_writeback_centisecs=12000
+```
+
+**Tuning:** As these parameters apply globally, you can adjust them under load from a different terminal.
+
+If set this way the settings are only temporary and reset after reboot. Although there are options to set them permanently we suggest to play around with session based parameters until you found the setting that works best for your system. Note that these parameters apply to the OS and therefore to all running applications.
+
+Further information on how to adjust dirty page writeback on other operating systems can be found [here](/docs/theory-of-operation.md#linux-dirty-page-writeback-tuning-notes).
\ No newline at end of file
diff --git a/console/executor_commands.cpp b/console/executor_commands.cpp
index 9b21fdcb..5e8695d9 100644
--- a/console/executor_commands.cpp
+++ b/console/executor_commands.cpp
@@ -27,7 +27,7 @@ namespace server {
using system::config::printer;
-const std::string executor::name_{ "bn" };
+const std::string executor::name_{ "bs" };
// Command line options.
// ----------------------------------------------------------------------------
diff --git a/console/localize.hpp b/console/localize.hpp
index a1bd8cce..adc098d4 100644
--- a/console/localize.hpp
+++ b/console/localize.hpp
@@ -33,7 +33,7 @@ namespace server {
#define BS_SETTINGS_MESSAGE \
"These are the configuration settings that can be set."
#define BS_INFORMATION_MESSAGE \
- "Runs a full bitcoin node."
+ "Runs a full bitcoin node server."
// --initchain
#define BS_INITIALIZING_CHAIN \
diff --git a/docs/configuration.md b/docs/configuration.md
new file mode 100644
index 00000000..8e5ba727
--- /dev/null
+++ b/docs/configuration.md
@@ -0,0 +1,261 @@
+# Configuration
+
+libbitcoin-server `bs` can be configured in many different ways. Although it can be started without any parameters without issues, it is recommended to adjust the basic parameters to the underlying system and your own requirements.
+
+You can do this by passing a config file to the server at start with the following command:
+
+```sh
+$ ./bs --config ./bs.cfg
+```
+## Config File Structure
+The libbitcoin configuration file, referred to below as `bs.cfg`, follows the following structural format:
+
+```
+[section]
+parameter = value
+
+[section2]
+parameter2 = value
+```
+The configuration includes the following sections:
+
+- **[log]**
+ Controls the content and target directories of the log files.
+- **[database]**
+ Configuration of the store. Primarily specifying the storage location.
+- **[bitcoin]**
+ Blockchain-specific settings,
+- **[node]**
+ Configuration of the node. Number of threads, number of parallel block downloads, etc.
+- **[network]**
+ General network settings, from the user agent string to blacklists.
+- **[outbound]**
+ Control of P2P network behavior.
+- **[inbound]**
+ TBD
+- **[manual]**
+ TBD
+- **[web]**
+ TBD
+- **[explore]**
+ TBD
+- **[socket]**
+ TBD
+- **[bitcoind]**
+ TBD
+- **[electrum]**
+ TBD
+- **[stratum_v1]**
+ TBD
+- **[stratum_v2]**
+ TBD
+- **[forks]**
+ TBD
+
+There can be multiple occurences of each section, `bs` will still parse all parameters.
+
+## Sample Configurations
+The following sample configurations can be used to start libbitcoin server `bs`. Note that even with these samples, at least the path names and IP addresses must be adjusted.
+
+Use the following config settings to set up the libbitcoin server for milestone sync:
+
+
+libbitcoin-server configuration milestone sync
+
+```
+[log]
+path = /home/user/libbitcoin/log
+maximum_size = 10000000
+
+application = true
+news = true
+session = true
+protocol = false
+quitting = false
+proxy = false
+remote = true
+fault = true
+verbose = false
+#objects = false # debug builds only
+
+[database]
+path = /home/user/libbitcoin/blockchain/bitcoin
+
+[bitcoin]
+#checkpoint = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
+#milestone = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
+
+[node]
+threads = 32
+thread_priority = true
+memory_priority = true
+
+# delay_inbound = true will reject inbound requests until node is current. Speeds up IBD.
+delay_inbound = true
+
+# Number of concurrent blocks
+maximum_concurrency = 50000
+
+# Maximum Block Height. Use this for performance testing only.
+#maximum_height = 900000
+
+[network]
+#path = /home/user/libbitcoin/network
+# Thread count should the number of cores of the corresponding system
+threads = 16
+user_agent = "/libbitcoin4:0.14.2/"
+
+# Blacklisted peers due to protocol violation, version message, incoming, ...
+blacklist = 143.20.137.191
+blacklist = 143.20.137.34
+blacklist = 87.229.79.163
+blacklist = 87.229.79.127
+blacklist = 87.229.79.102
+blacklist = 31.58.215.119
+blacklist = 31.58.215.74
+
+[outbound]
+# Max number of peer connections
+connections = 100
+
+# Max number of addresses in the host pool
+host_pool_capacity = 10000
+
+connect_batch_size = 5
+
+[inbound]
+# mainnet: 8333, testnet: 18333, regtest: 18444
+connections = 0
+enable_loopback = false
+bind = [::]:8333
+bind = 0.0.0.0:8333
+```
+
+
+
+
+Use the following config settings to setup libbitcoin server for full validation sync:
+
+
+libbitcoin-server configuration full validation sync
+
+```
+[log]
+path = /home/user/libbitcoin/log
+maximum_size = 10000000
+
+application = true
+news = true
+session = true
+protocol = false
+quitting = false
+proxy = false
+remote = true
+fault = true
+verbose = false
+
+[database]
+path = /home/user/libbitcoin/blockchain/bitcoin
+
+[bitcoin]
+checkpoint = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
+milestone = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
+
+[node]
+threads = 32
+thread_priority = true
+memory_priority = true
+
+delay_inbound = true
+
+maximum_concurrency = 50000
+
+[network]
+threads = 16
+user_agent = "/libbitcoin4:0.14.2/"
+
+blacklist = 143.20.137.191
+blacklist = 143.20.137.34
+blacklist = 87.229.79.163
+blacklist = 87.229.79.127
+blacklist = 87.229.79.102
+blacklist = 31.58.215.119
+blacklist = 31.58.215.74
+
+[outbound]
+connections = 100
+
+host_pool_capacity = 10000
+
+connect_batch_size = 5
+
+[inbound]
+connections = 0
+enable_loopback = false
+bind = [::]:8333
+bind = 0.0.0.0:8333
+```
+
+
+
+Add the following settings to one of the configs above in order to add client-server endpoints: **(Work in progress/experimental)**
+
+
+libbitcoin-server endpoint configuration
+
+```
+[manual]
+# TBD
+
+[web]
+# Web User Interface (http/s, stateless html)
+# Ports: 8080/8443 (non-default, prioritizes explore)
+
+path = /home/user/libbitcoin/server/www
+default = ws.html
+server = libbitcoin/web
+connections = 100
+bind = 0.0.0.0:8080
+bind = [::]:8080
+
+[explore]
+# Native RESTful Block Explorer (http/s, stateless html/json)
+# Ports: 80/443 (use default)
+
+bind = 0.0.0.0:8181
+bind = [::]:8181
+connections = 100
+path = /home/user/libbitcoin/server/www
+default = index.html
+
+[socket]
+# Native WebSocket Query Interface (http/s->tcp/s, json, upgrade handshake)
+bind = 192.168.0.126:82
+connections = 0
+
+[bitcoind]
+# bitcoind compatibility interface (http/s, stateless json-rpc-v2)
+# TLS not integrated, no default ports.
+connections = 0
+
+[electrum]
+# electrum compatibility interface (tcp/s, json-rpc-v2)
+# clear:50001
+# TLS :50002
+
+bind = 192.168.0.126:8480
+connections = 0
+
+[stratum_v1]
+# stratum v1 compatibility interface (tcp/s, json-rpc-v1, auth handshake)
+# common default: 3333
+bind = 192.168.0.126:8580
+connections = 0
+
+[stratum_v2]
+# stratum v2 compatibility interface (tcp[/s], binary, auth/privacy handshake)
+# common default: 3336
+bind = 192.168.0.126:8690
+connections = 0
+```
+
\ No newline at end of file
diff --git a/docs/images/brunella_compare.png b/docs/images/brunella_compare.png
new file mode 100644
index 00000000..4abede83
Binary files /dev/null and b/docs/images/brunella_compare.png differ
diff --git a/docs/images/brunella_full_validation.png b/docs/images/brunella_full_validation.png
new file mode 100644
index 00000000..f146d268
Binary files /dev/null and b/docs/images/brunella_full_validation.png differ
diff --git a/docs/images/brunella_full_validation.svg b/docs/images/brunella_full_validation.svg
new file mode 100644
index 00000000..3b5dc5f1
--- /dev/null
+++ b/docs/images/brunella_full_validation.svg
@@ -0,0 +1,74669 @@
+
+
+
diff --git a/docs/images/brunella_milestone.png b/docs/images/brunella_milestone.png
new file mode 100644
index 00000000..e46aa8e4
Binary files /dev/null and b/docs/images/brunella_milestone.png differ
diff --git a/docs/images/brunella_milestone.svg b/docs/images/brunella_milestone.svg
new file mode 100644
index 00000000..bea52ab9
--- /dev/null
+++ b/docs/images/brunella_milestone.svg
@@ -0,0 +1,47657 @@
+
+
+
diff --git a/docs/images/libbitcoin-components-server.svg b/docs/images/libbitcoin-components-server.svg
new file mode 100644
index 00000000..afe15cbf
--- /dev/null
+++ b/docs/images/libbitcoin-components-server.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/docs/tbd.md b/docs/tbd.md
new file mode 100644
index 00000000..7b88ff01
--- /dev/null
+++ b/docs/tbd.md
@@ -0,0 +1,2 @@
+
+**The content you are looking for is not yet available.**
\ No newline at end of file
diff --git a/docs/theory-of-operation.md b/docs/theory-of-operation.md
new file mode 100644
index 00000000..ea3332db
--- /dev/null
+++ b/docs/theory-of-operation.md
@@ -0,0 +1,112 @@
+# Theory of Operation
+
+## Architecture Overview
+
+Libbitcoin is a full-stack C++ development toolkit for Bitcoin. It includes everything from basic hash functions (in libbitcoin-system) up to a high performance full node (libbitcoin-node) and a comprehensive client-server connection layer on top (libbitcoin-server)
+
+## Components
+
+
+
+## Startup Process
+TBD
+
+## Store Creation
+TBD
+
+## Peer Networking
+
+### Peer connections
+TBD
+
+### Sync start
+TBD
+
+## Sync Mechanisms
+libbitcoin-node distinguishes between two different methods for the initial block download (IBD).
+
+### Milestone Sync
+Milestone Sync (the default mode) is optimized for speed. If the user has previously fully validated the chain up to the configured milestone hash, expensive block validation steps below that height are skipped on subsequent synchronizations.
+
+Specifically: For blocks at or below the milestone height, all validation except identity checks (block hash, Merkle root, and witness commitment) is skipped. Block headers are always fully validated. Unlike Bitcoin Core's AssumeValid (which skips only signature verification), Libbitcoin skips nearly all block-level checks below the milestone.
+
+Starting from the milestone (and for all new blocks), full validation is applied. There are no trust assumptions — milestone optimization is secure only because the user has previously validated to that point themselves. If the user has not previously validated the chain, they should perform a full validation sync from genesis and record a new milestone for future use.
+
+There is only one level of security: full independent validation. Milestone Sync provides the same security as full validation for users who have previously validated the chain themselves, while significantly accelerating subsequent synchronizations.
+
+The following diagram shows the runtime behaviour of `bs` in milestone sync mode on a 256GB RAM, 64 Cores computer running Ubuntu:
+
+
+
+As the CPU load is significantly lower compared to a full validation sync, one can see clearly how the network performace is the bottleneck. In other words, the faster the network, the faster the sync - until the bottleneck moves to validation power again.
+
+### Full Validation Sync
+In full validation mode, the entire blockchain is fully validated from the genesis block onward, without any optimizations or shortcuts. Every block and transaction is checked against all consensus rules, including complete script and signature verification.
+
+There are never any trust assumptions — everything is independently verified. This is recommended for the initial synchronization or whenever the user has not previously validated the chain themselves. Once complete, a milestone can be recorded for faster future synchronizations while maintaining the same single level of security.
+
+The following diagram shows the runtime behaviour of `bs` in full validation sync mode on a 256GB RAM, 64 Cores computer running Ubuntu (same system as above):
+
+
+
+## Checkpoints and Milestones
+
+**Checkpoints** are fixed block hashes at specific heights that represent activated consensus rules (soft forks). They are required consensus points: the node rejects any chain that violates a checkpoint, enforcing the canonical chain up to those heights.
+
+**Milestones** are distinct from checkpoints. A milestone is an optional optimization point (not a consensus requirement) that allows skipping full block validation below its height — but only if the user has previously validated the chain to that milestone hash themselves.
+
+In the default configuration, multiple checkpoints are defined (as consensus rules), along with one milestone at a relatively recent height (currently block 900,000).
+
+To perform a full validation sync (disabling milestone optimization while preserving consensus checkpoints), set only the milestone value in the configuration file to the genesis block::
+
+```
+[bitcoin]
+milestone = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
+```
+
+Checkpoints are consensus rules and should not be disabled. Milestones introduce no trust assumptions — they rely solely on the user's prior independent validation. For maximum sovereignty on first use or after potential compromise, perform a full validation sync from genesis. For subsequent synchronizations or everyday use (after initial full validation), Milestone Sync provides the same security with significantly faster performance.
+
+## Linux Dirty Page Writeback Tuning Notes
+While standard Ubuntu installations adhere to the upstream Linux kernel defaults (`vm.dirty_bytes=0` and `vm.dirty_background_bytes=0`), enabling percentage-based control via `vm.dirty_ratio=20` and `vm.dirty_background_ratio=10`, some Ubuntu-based derivatives (e.g., Pop!_OS, Kubuntu) override these in their default sysctl configuration with fixed byte thresholds (commonly `vm.dirty_bytes=268435456` or similar values around 256 MiB).
+
+These absolute byte limits take precedence over the percentage-based settings, which can unnecessarily restrict writeback caching on systems with large amounts of RAM and result in suboptimal I/O performance even after manually increasing the ratios.
+
+In contrast, Arch Linux follows a minimalistic philosophy and ships with no default sysctl overrides that set non-zero byte values, preserving the upstream kernel defaults unless explicitly modified by the user or third-party packages.
+
+If your system—particularly on Arch—exhibits limited caching behavior despite `vm.dirty_bytes` and `vm.dirty_background_bytes` being zero (i.e., ratio adjustments have no observable effect), check for unintended overrides introduced by installed software, custom scripts, or kernel modules.
+
+### Verification and Correction
+
+To inspect the active values:
+
+```bash
+$ sysctl vm.dirty_bytes vm.dirty_background_bytes vm.dirty_ratio vm.dirty_background_ratio
+```
+
+If the byte parameters are non-zero, locate the responsible configuration file (typically under `/etc/sysctl.d/`), comment out or remove the byte entries, then reload:
+
+```bash
+$ sudo sysctl --system
+```
+
+After removing any byte overrides, your desired ratio settings will take effect as intended.
+
+If the byte values are already zero but performance remains constrained, the issue may stem from per-device dirty throttling or other kernel mechanisms outside these global parameters.
\ No newline at end of file
+
+
+
+
+
+
+
+
+
+
+
+