v29.4-roots.2 · Commit 14: [PATCH 14/21] docs: define follow-on operator scope
doc/roots-features.md
Before: doc/roots-features.md · After: doc/roots-features.md
File metadata
index 073fe6ce26e46d82ea1da65d389652b57b02ebc4..fedd1e0a9650920b5c959c5a3a33c9b1d31d2e9a 100644
Download original patch · Release notes
Diff rows 1–38 of 38. 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
CHANGED
|
@@ -121,21 +121,21 @@ 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 |
|
|
@@ -156,6 +156,9 @@ Roots does not ship or promise:
|
|
| 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
|
|
|
|
| 121 |
|
| 122 |
## Planned or under review
|
| 123 |
|
| 124 |
+
The following 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.
|
| 129 |
2. Narrow P2P privacy and resource-use hardening.
|
| 130 |
3. Wallet database, flush, and backup reliability improvements.
|
| 131 |
+
4. An optional thin per-send RBF control.
|
| 132 |
+
5. Cross-feature regression coverage and catalog reconciliation.
|
|
|
|
| 133 |
|
| 134 |
Each item requires its own accepted implementation and tests before it moves to
|
| 135 |
+
the available section. Planned wallet reliability work does not imply a
|
| 136 |
+
guarantee about backup or recovery before the relevant tests exist. The plan
|
| 137 |
+
does not include Tor endpoint sharing, private-key sweeping, or broad or
|
| 138 |
+
privacy-aware coin control.
|
| 139 |
|
| 140 |
## Consensus and provenance boundary
|
| 141 |
|
|
|
|
| 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 |
+
- Tor endpoint sharing or a dedicated endpoint-sharing UI;
|
| 160 |
+
- private-key sweeping, or broad or privacy-aware coin control and payment
|
| 161 |
+
history redesign;
|
| 162 |
- the candidate's broad Knots common-maintenance, consensus/script, wallet, or
|
| 163 |
documentation overlays merely because they occurred in historical source;
|
| 164 |
- the discarded replay, frozen-state, generated-evidence, or promotion control
|