The BitcoinMW full node is a fork of the Grin full node. At the same time, as the codebase comes from Grin, the initial UTXO set comes from Bitcoin (BTC). 1 BTC at the time of the snapshot = 1 BMW. The Mainnet snapshot will be taken on Jan 3, 2022 at 18:00 UTC and Mainnet will launch on Jan 6, 2022 at 18:00 UTC.

Post fork, BitcoinMW has a slightly modified emission schedule (still maintaining Bitcoin's 21 million supply cap). For details on that, see emission schedule below.

All transactions in BitcoinMW are NIT transactions. See Gary Yu's paper for more details on NIT.

BitcoinMW has Burn Kernels. See Snape479's proposal to MWC for more details on Burn Kernels.

BitcoinMW has notarization. See Snape479's proposal to Grin for more details on Notarization. A slightly modified version, to what was proposed for MWC was implemented in BitcoinMW, as only a single notarization is allowed in the Coinbase Kernel.

BitcoinMW supports TOR and in fact, requires it. All connections are made with TOR by default. For cases where a regular TCP/IP connection is needed, it can be done via the peers_preferred/peers_allowed interface. This may be needed for mining pools to connect to one another and to reduce latency.

BitcoinMW's programming language rust has build targets for most platforms.

The primary supported platforms are: MacOS, Linux, and Windows. The build pipeline continously checks specifically ubuntu-18.04, macos-latest, windows-latest. We support, but do not test other variants of these OSes at the moment.

• rust: Install using rustup: https://rustup.rs
  • BitcoinMW currently does not support a minimum version of Rust, it is recommended to build using the latest version.
  • If rust is already installed, you can update to the latest version by running rustup update.
• clang
• ncurses and libs (ncurses, ncursesw5)
• zlib libs (zlib1g-dev or zlib-devel)
• pkg-config
• libssl-dev
• linux-headers (reported needed on Alpine linux)
• llvm
• tor

For Debian-based distributions (Debian, Ubuntu, Mint, etc), all in one line (except Rust):

apt install build-essential cmake git libgit2-dev clang libncurses5-dev libncursesw5-dev zlib1g-dev pkg-config libssl-dev llvm tor

On some versions of linux, the following is required:

sudo apt-get install -y libncursesw5

For Mac:

xcode-select --install
brew install --with-toolchain llvm
brew install pkg-config
brew install openssl
brew install tor

git clone https://github.com/bitcoinmw/bitcoinmw.git
cd bitcoinmw
cargo build --release

BitcoinMW can also be built in debug mode (without the --release flag, but using the --debug or the --verbose flag) but this will render fast sync prohibitively slow due to the large overhead of cryptographic operations.

A successful build gets you:

• target/release/bmw - the main bitcoinmw binary

All data, configuration and log files created and used by bmw are located in the hidden ~/.bmw directory (under your user home directory) by default. You can modify all configuration values by editing the file ~/.bmw/main/bmw-server.toml.

It is also possible to have bmw create its data files in the current directory. To do this, run

bmw server config

Which will generate a bmw-server.toml file in the current directory, pre-configured to use the current directory for all of its data. Running bmw from a directory that contains a bmw-server.toml file will use the values in that file instead of the default ~/.bmw/main/bmw-server.toml.

While testing, put the bmw binary on your path like this:

export PATH=`pwd`/target/release:$PATH

assuming you are running from the root directory of your BitcoinMW installation.

You can then run bmw directly (try bmw help for more options).

If you don't want to build bmw, you can always download the latest binaries from the release page: https://github.com/bitcoinmw/bitcoinmw/releases.

For a full understanding of the emission schedule, review the consensus.rs file. Briefly, the goal in BitcoinMW was to maintain the Bitcoin 21 million supply cap. That is sacrosanct. However, there are concerns about the emissions going to 0 after the last halving. Even well before that, the emissions in BTC will be negligible. Our proposed solution is a 1,000 year tail emission schedule. To do that we need to start with the 3.125 coin per 10 minute era on launch. The coins that would have been part of the rest of the 6.25 coin per 10 minute era are used for the tail emission. At the end of the 1,000 year period, the nodes will shut down. Future generations can decide how to handle that.

BitcoinMW attempts to run with sensible defaults, and can be further configured via the bmw-server.toml file. This file is generated by bmw on its first run, and contains documentation on each available option.

While it's recommended that you perform all bmw server configuration via bmw-server.toml, it's also possible to supply command line switches to bmw that override any settings in the file.

For help on bmw commands and their switches, try:

bmw help
bmw server --help
bmw client --help

Currently BitcoinMW has a log file that is stored in the same directory as bmw-server.toml file. By default this is in ~/.bmw/main/bmw-server.log. In future versions we hope to support multiple additional logging options including (multiple logs: request log, stats log, main log, messaging uploads, etc).

Currently the grin apis (both owner and foreign) are supported. Four foreign APIs have been added (get_btc_address_status, scan, get_kernels, get_all_kernels). One of the tasks is to create documentation for all of these APIs. It will be held in the wiki and maintained as such with both existing APIs and the newly added APIs. Breifly, get_btc_address_status is used by the wallet to query claim status of addresses. The rustdoc comments explain it and the wallet code can be viewed to understand it better. scan is used by the wallet as an optimized way to get all data needed to update in a single request (or series of requests if much data is needed). It improves performance of the wallet scan function (which is now built into the other commands and never needs to be called) greatly. Get all kernels is used to check the entire list of kernels. It makes checking notarizations easier, but is really just a utility function. And the get_kernels function is just a batch form of the get_kernel function. Another optimization was to request all kernels at once as opposed to just one at a time. That helped improve scan performance as well. As previously mentioned, full documentation in wiki format will be forthcoming.

Running the test suite is done with the following command:

cargo test --all

This command must be ran before any checkin. Testing is important and automated testing is vital to the success of the project. Additional tests are always greatly appreciated.

The Azure build pipeline is used for continuous integration. The pipelines can be viewed here.

One of the major improvements with NIT is that the wallet does not need to be connected in order to mine. All that's needed is an address. The address is specified in bmw-server.toml in the stratum mining config section under the recipient_address parameter. Make sure to modify that parameter with the address of your wallet. You can get the address of the bmw_wallet with the following command:

# bmw-wallet address

Your wallet will pickup the newly minted coinbase outputs via the scan function.

As with grin, a separate binary is used to mine. Currently supported miners are: lolminer, grin-miner, and gminer.

We will be coming out with a more detailed mining guide shortly.

There is much to do with BitcoinMW. Some ideas:

1.) Performance improvements (possibly a rewrite like with the bmw_wallet is needed)

2.) Improve documentation

3.) More code coverage

4.) More automation like code coverage stats

5.) Better support for multi-sig (needed in node? Or can it be done in the wallet?)

6.) Direct support for block exploring