The big notice at the top of the release note is not interesting
to most users now and apparently comes across poorly to some.
Better to provide more information about what we do support.
This disentangles the script validation skipping from checkpoints.
A new option is introduced "assumevalid" which specifies a block whos
ancestors we assume all have valid scriptsigs and so we do not check
them when they are also burried under the best header by two weeks
worth of work.
Unlike checkpoints this has no influence on consensus unless you set
it to a block with an invalid history. Because of this it can be
easily be updated without risk of influencing the network consensus.
This results in a massive IBD speedup.
This approach was independently recommended by Peter Todd and Luke-Jr
since POW based signature skipping (see PR#9180) does not have the
verifiable properties of a specific hash and may create bad incentives.
The downside is that, like checkpoints, the defaults bitrot and older
releases will sync slower. On the plus side users can provide their
own value here, and if they set it to something crazy all that will
happen is more time will be spend validating signatures.
Checkblocks and checklevel are also moved to the hidden debug options:
Especially now that checkblocks has a low default there is little need
to change these settings, and users frequently misunderstand them as
influencing security or IBD speed. By hiding them we offset the
space added by this new option.
2fb98f6 Fix bug in dmg builder so that it actually reads in the configuration file (Don Patterson)
b01667c Mention RSVG dependency when creating the disk image on OSX (Jonas Schnelli)
09aefb5 build: Fix 'make deploy' for OSX (Cory Fields)
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
Suhas Daftuar