aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/descriptors.md18
-rw-r--r--doc/developer-notes.md7
-rw-r--r--doc/release-notes.md11
-rw-r--r--doc/tor.md10
4 files changed, 31 insertions, 15 deletions
diff --git a/doc/descriptors.md b/doc/descriptors.md
index c4fc2a66bf..e27ff87546 100644
--- a/doc/descriptors.md
+++ b/doc/descriptors.md
@@ -30,6 +30,7 @@ Output descriptors currently support:
- Pay-to-witness-pubkey-hash scripts (P2WPKH), through the `wpkh` function.
- Pay-to-script-hash scripts (P2SH), through the `sh` function.
- Pay-to-witness-script-hash scripts (P2WSH), through the `wsh` function.
+- Pay-to-taproot outputs (P2TR), through the `tr` function.
- Multisig scripts, through the `multi` function.
- Multisig scripts where the public keys are sorted lexicographically, through the `sortedmulti` function.
- Any type of supported address through the `addr` function.
@@ -54,6 +55,7 @@ Output descriptors currently support:
- `pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)` describes a set of P2PKH outputs, but additionally specifies that the specified xpub is a child of a master with fingerprint `d34db33f`, and derived using path `44'/0'/0'`.
- `wsh(multi(1,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))` describes a set of *1-of-2* P2WSH multisig outputs where the first multisig key is the *1/0/`i`* child of the first specified xpub and the second multisig key is the *0/0/`i`* child of the second specified xpub, and `i` is any number in a configurable range (`0-1000` by default).
- `wsh(sortedmulti(1,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))` describes a set of *1-of-2* P2WSH multisig outputs where one multisig key is the *1/0/`i`* child of the first specified xpub and the other multisig key is the *0/0/`i`* child of the second specified xpub, and `i` is any number in a configurable range (`0-1000` by default). The order of public keys in the resulting witnessScripts is determined by the lexicographic order of the public keys at that index.
+- `tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5,{pk(fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556),pk(e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13)})` describes a P2TR output with the `c6...` x-only pubkey as internal key, and two script paths.
## Reference
@@ -61,13 +63,14 @@ Descriptors consist of several types of expressions. The top level expression is
`SCRIPT` expressions:
- `sh(SCRIPT)` (top level only): P2SH embed the argument.
-- `wsh(SCRIPT)` (not inside another 'wsh'): P2WSH embed the argument.
+- `wsh(SCRIPT)` (top level or inside `sh` only): P2WSH embed the argument.
- `pk(KEY)` (anywhere): P2PK output for the given public key.
-- `pkh(KEY)` (anywhere): P2PKH output for the given public key (use `addr` if you only know the pubkey hash).
-- `wpkh(KEY)` (not inside `wsh`): P2WPKH output for the given compressed pubkey.
+- `pkh(KEY)` (not inside `tr`): P2PKH output for the given public key (use `addr` if you only know the pubkey hash).
+- `wpkh(KEY)` (top level or inside `sh` only): P2WPKH output for the given compressed pubkey.
- `combo(KEY)` (top level only): an alias for the collection of `pk(KEY)` and `pkh(KEY)`. If the key is compressed, it also includes `wpkh(KEY)` and `sh(wpkh(KEY))`.
-- `multi(k,KEY_1,KEY_2,...,KEY_n)` (anywhere): k-of-n multisig script.
-- `sortedmulti(k,KEY_1,KEY_2,...,KEY_n)` (anywhere): k-of-n multisig script with keys sorted lexicographically in the resulting script.
+- `multi(k,KEY_1,KEY_2,...,KEY_n)` (not inside `tr`): k-of-n multisig script.
+- `sortedmulti(k,KEY_1,KEY_2,...,KEY_n)` (not inside `tr`): k-of-n multisig script with keys sorted lexicographically in the resulting script.
+- `tr(KEY)` or `tr(KEY,TREE)` (top level only): P2TR output with the specified key as internal key, and optionally a tree of script paths.
- `addr(ADDR)` (top level only): the script which ADDR expands to.
- `raw(HEX)` (top level only): the script whose hex encoding is HEX.
@@ -80,12 +83,17 @@ Descriptors consist of several types of expressions. The top level expression is
- Followed by the actual key, which is either:
- Hex encoded public keys (either 66 characters starting with `02` or `03` for a compressed pubkey, or 130 characters starting with `04` for an uncompressed pubkey).
- Inside `wpkh` and `wsh`, only compressed public keys are permitted.
+ - Inside `tr`, x-only pubkeys are also permitted (64 hex characters).
- [WIF](https://en.bitcoin.it/wiki/Wallet_import_format) encoded private keys may be specified instead of the corresponding public key, with the same meaning.
- `xpub` encoded extended public key or `xprv` encoded extended private key (as defined in [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)).
- Followed by zero or more `/NUM` unhardened and `/NUM'` hardened BIP32 derivation steps.
- Optionally followed by a single `/*` or `/*'` final step to denote all (direct) unhardened or hardened children.
- The usage of hardened derivation steps requires providing the private key.
+`TREE` expressions:
+- any `SCRIPT` expression
+- An open brace `{`, a `TREE` expression, a comma `,`, a `TREE` expression, and a closing brace `}`
+
(Anywhere a `'` suffix is permitted to denote hardened derivation, the suffix `h` can be used instead.)
`ADDR` expressions are any type of supported address:
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index 2130332eec..c3a63b3523 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -1160,13 +1160,6 @@ A few guidelines for introducing and reviewing new RPC interfaces:
- *Rationale*: If not, the call can not be used with name-based arguments.
-- Set okSafeMode in the RPC command table to a sensible value: safe mode is when the
- blockchain is regarded to be in a confused state, and the client deems it unsafe to
- do anything irreversible such as send. Anything that just queries should be permitted.
-
- - *Rationale*: Troubleshooting a node in safe mode is difficult if half the
- RPCs don't work.
-
- Add every non-string RPC argument `(method, idx, name)` to the table `vRPCConvertParams` in `rpc/client.cpp`.
- *Rationale*: `bitcoin-cli` and the GUI debug console use this table to determine how to
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 53106c9f82..cb7adde470 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -59,6 +59,13 @@ Notable changes
P2P and network changes
-----------------------
+- This release removes support for Tor version 2 hidden services in favor of Tor
+ v3 only, as the Tor network [dropped support for Tor
+ v2](https://blog.torproject.org/v2-deprecation-timeline) with the release of
+ Tor version 0.4.6. Henceforth, Bitcoin Core ignores Tor v2 addresses; it
+ neither rumors them over the network to other peers, nor stores them in memory
+ or to `peers.dat`. (#22050)
+
- Added NAT-PMP port mapping support via
[`libnatpmp`](https://miniupnp.tuxfamily.org/libnatpmp.html). (#18077)
@@ -142,8 +149,8 @@ Tools and Utilities
- A new CLI `-addrinfo` command returns the number of addresses known to the
node per network type (including Tor v2 versus v3) and total. This can be
useful to see if the node knows enough addresses in a network to use options
- like `-onlynet=<network>` or to upgrade to current and future Tor releases
- that support Tor v3 addresses only. (#21595)
+ like `-onlynet=<network>` or to upgrade to this release of Bitcoin Core 22.0
+ that supports Tor v3 only. (#21595)
Wallet
------
diff --git a/doc/tor.md b/doc/tor.md
index 2640a6109b..7d134b64e0 100644
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -5,6 +5,14 @@ It is possible to run Bitcoin Core as a Tor onion service, and connect to such s
The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on port 9150. See [Tor Project FAQ:TBBSocksPort](https://www.torproject.org/docs/faq.html.en#TBBSocksPort) for how to properly
configure Tor.
+## Compatibility
+
+- Starting with version 22.0, Bitcoin Core only supports Tor version 3 hidden
+ services (Tor v3). Tor v2 addresses are ignored by Bitcoin Core and neither
+ relayed nor stored.
+
+- Tor removed v2 support beginning with version 0.4.6.
+
## How to see information about your Tor configuration via Bitcoin Core
There are several ways to see your local onion address in Bitcoin Core:
@@ -18,7 +26,7 @@ information in the debug log about your Tor configuration.
CLI `-addrinfo` returns the number of addresses known to your node per network
type, including Tor v2 and v3. This is useful to see how many onion addresses
are known to your node for `-onlynet=onion` and how many Tor v3 addresses it
-knows when upgrading to current and future Tor releases that support Tor v3 only.
+knows when upgrading to Bitcoin Core v22.0 and up that supports Tor v3 only.
## 1. Run Bitcoin Core behind a Tor proxy