diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/build-osx.md | 31 | ||||
| -rw-r--r-- | doc/release-notes-19776.md | 9 | ||||
| -rw-r--r-- | doc/shared-libraries.md | 3 | ||||
| -rw-r--r-- | doc/tor.md | 7 |
4 files changed, 39 insertions, 11 deletions
diff --git a/doc/build-osx.md b/doc/build-osx.md index 0a091f6afd..c1d101fde1 100644 --- a/doc/build-osx.md +++ b/doc/build-osx.md @@ -19,7 +19,7 @@ Then install [Homebrew](https://brew.sh). ## Dependencies ```shell -brew install automake berkeley-db4 libtool boost miniupnpc pkg-config python qt libevent qrencode sqlite +brew install automake libtool boost miniupnpc pkg-config python qt libevent qrencode ``` If you run into issues, check [Homebrew's troubleshooting page](https://docs.brew.sh/Troubleshooting). @@ -30,7 +30,22 @@ If you want to build the disk image with `make deploy` (.dmg / optional), you ne brew install librsvg ``` -## Berkeley DB +The wallet support requires one or both of the dependencies ([*SQLite*](#sqlite) and [*Berkeley DB*](#berkeley-db)) in the sections below. +To build Bitcoin Core without wallet, see [*Disable-wallet mode*](#disable-wallet-mode). + +#### SQLite + +Usually, macOS installation already has a suitable SQLite installation. +Also, the Homebrew package could be installed: + +```shell +brew install sqlite +``` + +In that case the Homebrew package will prevail. + +#### Berkeley DB + It is recommended to use Berkeley DB 4.8. If you have to build it yourself, you can use [this](/contrib/install_db4.sh) script to install it like so: @@ -41,7 +56,11 @@ like so: from the root of the repository. -**Note**: You only need Berkeley DB if the wallet is enabled (see [*Disable-wallet mode*](/doc/build-osx.md#disable-wallet-mode)). +Also, the Homebrew package could be installed: + +```shell +brew install berkeley-db4 +``` ## Build Bitcoin Core @@ -72,14 +91,14 @@ from the root of the repository. make deploy ``` -## `disable-wallet` mode +## Disable-wallet mode When the intention is to run only a P2P node without a wallet, Bitcoin Core may be -compiled in `disable-wallet` mode with: +compiled in disable-wallet mode with: ```shell ./configure --disable-wallet ``` -In this case there is no dependency on Berkeley DB 4.8 and SQLite. +In this case there is no dependency on [*Berkeley DB*](#berkeley-db) and [*SQLite*](#sqlite). Mining is also possible in disable-wallet mode using the `getblocktemplate` RPC call. diff --git a/doc/release-notes-19776.md b/doc/release-notes-19776.md new file mode 100644 index 0000000000..5553c5a7bd --- /dev/null +++ b/doc/release-notes-19776.md @@ -0,0 +1,9 @@ +Updated RPCs +------------ + +- The `getpeerinfo` RPC returns two new boolean fields, `bip152_hb_to` and + `bip152_hb_from`, that respectively indicate whether we selected a peer to be + in compact blocks high-bandwidth mode or whether a peer selected us as a + compact blocks high-bandwidth peer. High-bandwidth peers send new block + announcements via a `cmpctblock` message rather than the usual inv/headers + announcements. See BIP 152 for more details. (#19776) diff --git a/doc/shared-libraries.md b/doc/shared-libraries.md index e960863a80..147e223711 100644 --- a/doc/shared-libraries.md +++ b/doc/shared-libraries.md @@ -41,9 +41,10 @@ The interface is defined in the C header `bitcoinconsensus.h` located in `src/sc - `bitcoinconsensus_ERR_TX_SIZE_MISMATCH` - `txToLen` did not match with the size of `txTo` - `bitcoinconsensus_ERR_DESERIALIZE` - An error deserializing `txTo` - `bitcoinconsensus_ERR_AMOUNT_REQUIRED` - Input amount is required if WITNESS is used +- `bitcoinconsensus_ERR_INVALID_FLAGS` - Script verification `flags` are invalid (i.e. not part of the libconsensus interface) ### Example Implementations -- [NBitcoin](https://github.com/NicolasDorier/NBitcoin/blob/master/NBitcoin/Script.cs#L814) (.NET Bindings) +- [NBitcoin](https://github.com/MetacoSA/NBitcoin/blob/5e1055cd7c4186dee4227c344af8892aea54faec/NBitcoin/Script.cs#L979-#L1031) (.NET Bindings) - [node-libbitcoinconsensus](https://github.com/bitpay/node-libbitcoinconsensus) (Node.js Bindings) - [java-libbitcoinconsensus](https://github.com/dexX7/java-libbitcoinconsensus) (Java Bindings) - [bitcoinconsensus-php](https://github.com/Bit-Wasp/bitcoinconsensus-php) (PHP Bindings) diff --git a/doc/tor.md b/doc/tor.md index 12b5f70245..692041ccea 100644 --- a/doc/tor.md +++ b/doc/tor.md @@ -37,7 +37,7 @@ In a typical situation, this suffices to run behind a Tor proxy: ./bitcoind -proxy=127.0.0.1:9050 -## 2. Run a Bitcoin Core hidden server +## 2. Manually create a Bitcoin Core onion service If you configure your Tor system accordingly, it is possible to make your node also reachable from the Tor network. Add these lines to your /etc/tor/torrc (or equivalent @@ -46,7 +46,6 @@ versions of Tor see [Section 3](#3-automatically-listen-on-tor).* HiddenServiceDir /var/lib/tor/bitcoin-service/ HiddenServicePort 8333 127.0.0.1:8334 - HiddenServicePort 18333 127.0.0.1:18334 The directory can be different of course, but virtual port numbers should be equal to your bitcoind's P2P listen port (8333 by default), and target addresses and ports @@ -92,7 +91,7 @@ for normal IPv4/IPv6 communication, use: ./bitcoind -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover -## 3. Automatically listen on Tor +## 3. Automatically create a Bitcoin Core onion service Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket API, to create and destroy 'ephemeral' onion services programmatically. @@ -130,6 +129,6 @@ in the tor configuration file. The hashed password can be obtained with the comm - Do not add anything but Bitcoin Core ports to the onion service created in section 2. If you run a web service too, create a new onion service for that. - Otherwise it is trivial to link them, which may reduce privacy. Hidden + Otherwise it is trivial to link them, which may reduce privacy. Onion services created automatically (as in section 3) always have only one port open. |