v29.4-roots.1 · Commit 7: [PATCH 07/13] release: establish Roots maintenance and assurance
doc/roots-features.md
Before: /dev/null · After: doc/roots-features.md
File metadata
new file mode 100644 index 0000000000000000000000000000000000000000..073fe6ce26e46d82ea1da65d389652b57b02ebc4
Download original patch · Release notes
Diff rows 1–168 of 168. Line numbers refer to the original before/after files.
+ Added− RemovedUnmarked lines are context.
Scroll the code area horizontally to read long lines. The two line-number columns refer to before and after.
doc/roots-features.md
ADDED
|
@@ -0,0 +1,168 @@
|
|
|
1
|
+
# Bitcoin Roots feature catalog
|
|
2
|
+
|
|
3
|
+
Bitcoin Roots is based directly on Bitcoin Core v29.4. It retains selected
|
|
4
|
+
operator and local-policy work whose historical lineage includes Bitcoin Knots
|
|
5
|
+
`29.3.knots20260507`; Knots is not an upstream dependency and its candidate
|
|
6
|
+
tree is not a list of shipped features.
|
|
7
|
+
|
|
8
|
+
This page is the public inventory for Roots-specific work. Ordinary Bitcoin Core
|
|
9
|
+
v29.4 functionality is documented in the built help and the manuals in this
|
|
10
|
+
directory. The commands below describe the binary that is built from this tree;
|
|
11
|
+
use `bitcoind -help` as the authority for the exact options in a given build.
|
|
12
|
+
|
|
13
|
+
## Available now
|
|
14
|
+
|
|
15
|
+
### Conservative, configurable local transaction policy
|
|
16
|
+
|
|
17
|
+
Roots retains configurable admission, relay, and mining-template policy. The
|
|
18
|
+
current daemon exposes controls including `-datacarrier`, `-datacarriercost`,
|
|
19
|
+
`-datacarriersize`, `-mempoolreplacement`, `-minrelaycoinblocks`,
|
|
20
|
+
`-minrelaymaturity`, `-permitbaremultisig`, `-subdustfeepenalty`,
|
|
21
|
+
`-blockmaxweight`, `-blockmintxfee`, and `-blockprioritysize`.
|
|
22
|
+
|
|
23
|
+
These are local node choices, not block-validity rules. A transaction rejected
|
|
24
|
+
by this policy can still be consensus-valid, and a valid block containing it
|
|
25
|
+
must remain acceptable. The retained regression coverage includes
|
|
26
|
+
[`mempool_dust.py`](/test/functional/mempool_dust.py),
|
|
27
|
+
[`mempool_subdust_fee_penalty.py`](/test/functional/mempool_subdust_fee_penalty.py),
|
|
28
|
+
[`mempool_sigoplimit.py`](/test/functional/mempool_sigoplimit.py), and
|
|
29
|
+
[`mempool_truc.py`](/test/functional/mempool_truc.py).
|
|
30
|
+
|
|
31
|
+
### Peer controls and bounded network resources
|
|
32
|
+
|
|
33
|
+
Roots carries selected peer-control and resource-bound work without changing the
|
|
34
|
+
Bitcoin P2P protocol. The current help includes compact-block reconstruction
|
|
35
|
+
bounds (`-blockreconstructionextratxn` and
|
|
36
|
+
`-blockreconstructionextratxnsize`), an orphan-transaction limit
|
|
37
|
+
(`-maxorphantx`), upload limiting (`-maxuploadtarget`), and Core-compatible peer
|
|
38
|
+
permission controls such as `-whitebind` and `-whitelist`.
|
|
39
|
+
|
|
40
|
+
The retained P2P coverage includes
|
|
41
|
+
[`p2p_disconnect_ban.py`](/test/functional/p2p_disconnect_ban.py),
|
|
42
|
+
[`p2p_eviction.py`](/test/functional/p2p_eviction.py),
|
|
43
|
+
[`p2p_filter.py`](/test/functional/p2p_filter.py), and
|
|
44
|
+
[`p2p_invalid_messages.py`](/test/functional/p2p_invalid_messages.py).
|
|
45
|
+
This is not a Network Watch or transaction/block activity feed.
|
|
46
|
+
|
|
47
|
+
### Wallet and signing hardening
|
|
48
|
+
|
|
49
|
+
The reviewed Roots wallet selection includes database and SQLite error handling,
|
|
50
|
+
external-signer integration boundaries, and spend-path hardening. Descriptor
|
|
51
|
+
wallets with SQLite are the primary supported configuration. The relevant
|
|
52
|
+
regression coverage includes
|
|
53
|
+
[`wallet_signer.py`](/test/functional/wallet_signer.py),
|
|
54
|
+
[`wallet_multiwallet.py`](/test/functional/wallet_multiwallet.py), and wallet
|
|
55
|
+
unit tests under [`src/wallet/test/`](/src/wallet/test/).
|
|
56
|
+
|
|
57
|
+
Legacy Berkeley DB support is a separate build choice. This catalog makes no
|
|
58
|
+
claim that it has been tested on a particular host library; release-compatible
|
|
59
|
+
legacy testing requires Berkeley DB 4.8.
|
|
60
|
+
|
|
61
|
+
### Runtime and operator foundations
|
|
62
|
+
|
|
63
|
+
The `getmempoolstats` RPC returns the node's collected, non-interpolated
|
|
64
|
+
mempool samples, and the `uptime` RPC uses a monotonic uptime source. These
|
|
65
|
+
interfaces are intended for node operators and tooling; their exact schemas are
|
|
66
|
+
available through `bitcoin-cli help getmempoolstats` and `bitcoin-cli help
|
|
67
|
+
uptime`. The runtime also contains support for system-RAM detection, memory
|
|
68
|
+
pressure, and advisory I/O priority where the host platform provides it. Those
|
|
69
|
+
are implementation safeguards, not a promise of identical behavior or knobs on
|
|
70
|
+
every operating system.
|
|
71
|
+
|
|
72
|
+
The retained coverage includes
|
|
73
|
+
[`rpc_uptime.py`](/test/functional/rpc_uptime.py) and unit tests in
|
|
74
|
+
[`src/stats/test/`](/src/stats/test/) and [`src/test/`](/src/test/).
|
|
75
|
+
|
|
76
|
+
### Build and platform portability
|
|
77
|
+
|
|
78
|
+
Roots uses the CMake build system with selected portability and dependency
|
|
79
|
+
support for this release. Configuration can select Qt 5 or Qt 6, and exposes
|
|
80
|
+
optional support for QR code generation, external signers, a dedicated Tor
|
|
81
|
+
subprocess, and Windows taskbar progress when their build prerequisites and
|
|
82
|
+
platform conditions are met. The dependency and platform instructions are in
|
|
83
|
+
[`doc/dependencies.md`](/doc/dependencies.md),
|
|
84
|
+
[`doc/build-unix.md`](/doc/build-unix.md), and the platform-specific build
|
|
85
|
+
guides in [`doc/`](/doc/).
|
|
86
|
+
|
|
87
|
+
Availability depends on the actual CMake summary and installed dependencies.
|
|
88
|
+
This catalog does not claim that every optional feature or platform combination
|
|
89
|
+
has been tested by the current checkout.
|
|
90
|
+
|
|
91
|
+
### Roots identity and desktop application
|
|
92
|
+
|
|
93
|
+
The daemon, command-line tools, and Qt application identify themselves as
|
|
94
|
+
Bitcoin Roots `v29.4-roots.1`. The Qt application includes Roots branding and
|
|
95
|
+
icons. In the receive-request dialog, a QR image can be saved as a PNG. On
|
|
96
|
+
Windows GUI builds where taskbar progress is enabled, synchronization progress
|
|
97
|
+
is reflected in the taskbar. The Qt source and tests are in
|
|
98
|
+
[`src/qt/`](/src/qt/), including QR export coverage in
|
|
99
|
+
[`src/qt/test/apptests.cpp`](/src/qt/test/apptests.cpp).
|
|
100
|
+
|
|
101
|
+
The generated manuals and example configuration are available in
|
|
102
|
+
[`doc/man/`](/doc/man/) and
|
|
103
|
+
[`share/examples/bitcoin.conf`](/share/examples/bitcoin.conf).
|
|
104
|
+
|
|
105
|
+
## Release and maintenance infrastructure
|
|
106
|
+
|
|
107
|
+
These facilities are for maintainers and release operators, not new consensus
|
|
108
|
+
or wallet behavior. Release tags use the Roots form
|
|
109
|
+
`v<core-version>-roots.<positive-integer>` (with a corresponding release
|
|
110
|
+
candidate form). The tag-triggered release workflow validates the checked-out
|
|
111
|
+
source and archive inputs, produces a SHA512 manifest, and creates a draft
|
|
112
|
+
release only in its protected release environment. It intentionally does not
|
|
113
|
+
restore nightly, promotion, frozen-state, or generated-evidence control planes.
|
|
114
|
+
|
|
115
|
+
[`contrib/roots/README.md`](/contrib/roots/README.md) documents the Git-native
|
|
116
|
+
workflow: inspect the explicit Core base, use ordinary Git porting or rebase
|
|
117
|
+
operations, review with `git range-diff`, and validate an annotated tag and its
|
|
118
|
+
ancestry before publishing. This repository does not claim local cryptographic
|
|
119
|
+
verification of the Core v29.4 tag because the signer public key is not present
|
|
120
|
+
in this checkout.
|
|
121
|
+
|
|
122
|
+
## Planned or under review
|
|
123
|
+
|
|
124
|
+
The following six areas are approved for evaluation in the follow-on operator
|
|
125
|
+
features plan. They are not available merely because they appear in a candidate
|
|
126
|
+
or in this roadmap.
|
|
127
|
+
|
|
128
|
+
1. Focused peer-health monitoring and safe Tor endpoint sharing.
|
|
129
|
+
2. Narrow P2P privacy and resource-use hardening.
|
|
130
|
+
3. Wallet database, flush, and backup reliability improvements.
|
|
131
|
+
4. A secure, explicitly reviewed private-key sweep flow.
|
|
132
|
+
5. Privacy-aware coin control and a per-send RBF choice.
|
|
133
|
+
6. Cross-feature regression coverage and catalog reconciliation.
|
|
134
|
+
|
|
135
|
+
Each item requires its own accepted implementation and tests before it moves to
|
|
136
|
+
the available section. In particular, endpoint sharing is not authentication or
|
|
137
|
+
pairing, and planned wallet work does not imply a guarantee about backup,
|
|
138
|
+
recovery, or private-key handling before the relevant tests exist.
|
|
139
|
+
|
|
140
|
+
## Consensus and provenance boundary
|
|
141
|
+
|
|
142
|
+
Bitcoin Roots remains compatible with Bitcoin Core consensus. It does **not**
|
|
143
|
+
enforce RDTS/BIP110 consensus rules. Policy, relay, mempool, and mining-template
|
|
144
|
+
configuration must not make a consensus-valid block invalid.
|
|
145
|
+
|
|
146
|
+
Bitcoin Core v29.4 is the direct base. Bitcoin Knots history is useful only as
|
|
147
|
+
provenance for selected policy research; it is not imported as an upstream
|
|
148
|
+
dependency. The historical replay candidate and archived maintenance branch are
|
|
149
|
+
evidence for maintainers, not product specifications.
|
|
150
|
+
|
|
151
|
+
## Deliberate non-features
|
|
152
|
+
|
|
153
|
+
Roots does not ship or promise:
|
|
154
|
+
|
|
155
|
+
- RDTS/BIP110 consensus enforcement;
|
|
156
|
+
- Network Watch, block/transaction feeds, or block/mempool visualizers;
|
|
157
|
+
- Tor "pairing" credentials, proxy credentials, control-port secrets, or
|
|
158
|
+
private-key sharing surfaces;
|
|
159
|
+
- the candidate's broad Knots common-maintenance, consensus/script, wallet, or
|
|
160
|
+
documentation overlays merely because they occurred in historical source;
|
|
161
|
+
- the discarded replay, frozen-state, generated-evidence, or promotion control
|
|
162
|
+
plane; or
|
|
163
|
+
- a VitePress documentation overlay, tonal/base16 font dependency, or other
|
|
164
|
+
separate visual identity layer.
|
|
165
|
+
|
|
166
|
+
For maintainers, [`contrib/roots/README.md`](/contrib/roots/README.md) documents
|
|
167
|
+
the Git-native maintenance workflow. For current build and runtime options, use
|
|
168
|
+
the generated manuals and the built binary help.
|