This fixes a bug where we might (in exceedingly rare circumstances)
accidentally ban a node for sending us the first (potentially few)
segwit blocks in non-segwit mode.
* 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
Implement `begin_ptr` and `end_ptr` in terms of C++11 code,
and add a comment that they are deprecated.
Follow-up to developer notes update in 654a211622.
75ead758 turned these into crashes in the event of a handshake failure, most
notably when a peer does not offer the expected services.
There are likely other cases that these assertions will find as well.
Base64 contains '/', and the '/' character in credentials is problematic
for AuthServiceProxy which represents the RPC endpoint as an URI with
user and password embedded.
Closes#8399.
In principle, the checksums of P2P packets are simply 4-byte blobs which
are the first four bytes of SHA256(SHA256(payload)).
Currently they are handled as little-endian 32-bit integers half of the
time, as blobs the other half, sometimes copying the one to the other,
resulting in somewhat confused code.
This PR changes the handling to be consistent both at packet creation
and receiving, making it (I think) easier to understand.
Simplified version of #8278. Assumes that every OS that (a) is supported
by Bitcoin Core (b) supports daemonization has the `daemon()` function
in its C library.
- Removes the fallback path for operating systems that support
daemonization but not `daemon()`. This prevents never-exercised code from
ending up in the repository (see discussion here:
https://github.com/bitcoin/bitcoin/pull/8278#issuecomment-242704745).
- Removes the windows-specific path. Windows doesn't support `daemon()`,
so it don't support daemonization there, automatically.
Original code by Matthew King, adapted by Wladimir van der Laan.
After #8594 the addrFrom sent by a node is not used anymore at all,
so don't bother sending it.
Also mitigates the privacy issue in (#8616). It doesn't completely solve
the issue as GetLocalAddress is also called in AdvertiseLocal, but at
least when advertising addresses it stands out less as *our* address.
Wladimir J. van der Laan