Skip to content
Bitcoin Roots

v29.4-roots.4 · Commit 7: [PATCH 07/37] 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. Before is on the left; after is on the right. Unified view fits narrow screens more easily.

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.