I did a build on a windows 10 laptop and took notes, and tried
to improve the document:
- It's the Linux subsystem for Windows, not the other way around.
- Split out dependencies: general ones, 64-bit, 32-bit. Remove the
reference to `build-unix.md`, easy enough to be self-contained.
- Place 64-bit instructions first. 99% will want these.
- Installation instructions: recommend using `/` for prefix, same as we
do on gitian builds. This will allow copying the files to a usable
(from Windows) place using just `make DESTDIR=...`.
- Remove double spaces / consistent width reformatting.
Refer to the right file in the top-level README.md.
Having only one file with test documentation saves some confusion about
where things are documented.
This introduces a 'minimum chain work' chainparam which is intended
to be the known amount of work in the chain for the network at the
time of software release. If you don't have this much work, you're
not yet caught up.
This is used instead of the count of blocks test from checkpoints.
This criteria is trivial to keep updated as there is no element of
subjectivity, trust, or position dependence to it. It is also a more
reliable metric of sync status than a block count.
> This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the -listenonion, -torcontrol and -torpassword settings. To show verbose debugging information, pass -debug=tor.
But it is correct to say that the feature is enabled *regardless* of whether a connection to Tor can be made.
I propose to clarify that so that users can eliminate these in their logs (when `listen=1` and no Tor).
And I think it's okay to clarify about the `listen` option, because on several occasions when I read this before I always assumed `listening` meant `server=1` which cost me a lot of time in troubleshooting.
```
2016-10-24 06:19:22.551029 tor: Error connecting to Tor control socket
2016-10-24 06:19:22.551700 tor: Not connected to Tor control port 127.0.0.1:9051, trying to reconnect
```
### What version of bitcoin-core are you using?
0.12.1
The new Windows Subsystem for Linux (WSL) allows a user to run a bash shell directly on Windows in an Ubuntu based environment. This can be used to cross-compile Bitcoin directly on Windows without the need for a separate Linux VM or Server. The instructions included in this commit explain how to configure the environment and build Bitcoin Core using this new feature.
* Minor formatting such as adjusting links
* Move sections of `doc/multiwallet-qt.md` to the source code and delete
the file, as it is outdated
* Fix typo in the release notes
* Amend release process to mention update of BLOCK_CHAIN_SIZE
- Changed Debian 8.5.0 ISO CD ROM URL by redirecting from current (which now has only 8.6.0) to a persistent archive link which should not change anytime soon.
- Added a link to official Debian checksum verification procedure (which is more verbose and also acts as a backup source of SHA256sum's)
- Fix capitalization (iso)
- Python 3 now supported.
- Bump boost version to 1.61 - one boost patch no longer needed.
- All checked with OpenBSD 5.9, except for the clang part, I left this
as-is for someone adventurous.
- Mention overriding resource limits, OpenBSD's default ulimit does not
suffice for building Bitcoin Core with gcc 4.9.3.
Wladimir J. van der Laan