Skip to content
Bitcoin Roots

v31.1-roots.1 · Commit 8: [PATCH 08/17] chore(roots): integrate v31 identity and maintenance tooling

README.md

Before: README.md · After: README.md

File metadata
index cfabb7f6723b0fb1cc30db62c776875b868f42a1..b697de70ee5845a556e7cdca7c7ddf7824a0ff93 100644

Download original patch · Release notes

Diff rows 1–131 of 131. 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.

README.md CHANGED
@@ -1,79 +1,89 @@
1
- Bitcoin Core integration/staging tree
2
- =====================================
1
+ Bitcoin Roots
2
+ =============
3
3
 
4
- https://bitcoincore.org
4
+ Connected to the trunk. Conservative in policy. Neutral in consensus.
5
5
 
6
- For an immediately usable, binary version of the Bitcoin Core software, see
7
- https://bitcoincore.org/en/download/.
6
+ This is the local Core v31.1 development candidate. Publishing and release
7
+ tagging are separate from this port. See the [port review](doc/roots-v31-port-review.md)
8
+ for exact inputs, implementation dispositions and verification gaps.
8
9
 
9
- What is Bitcoin Core?
10
- ---------------------
10
+ What is Bitcoin Roots?
11
+ ----------------------
11
12
 
12
- Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully
13
+ Bitcoin Roots connects to the Bitcoin peer-to-peer network to download and fully
13
14
  validate blocks and transactions. It also includes a wallet and graphical user
14
15
  interface, which can be optionally built.
15
16
 
16
- Further information about Bitcoin Core is available in the [doc folder](/doc).
17
+ Bitcoin Roots is based on Bitcoin Core with selected policy features from the
18
+ Bitcoin Knots `29.3.knots20260507` code line. The Knots reference describes
19
+ feature lineage only; Bitcoin Core v31.1 is this candidate’s direct base.
20
+
21
+ Bitcoin Roots remains compatible with Bitcoin Core consensus. Its conservative
22
+ transaction relay and mempool policy is local and configurable: a transaction
23
+ rejected by policy can still be consensus-valid, and valid blocks containing it
24
+ remain acceptable. Bitcoin Roots does not enforce RDTS/BIP110 consensus rules.
25
+
26
+ For the selected Roots behavior implemented in this candidate, the follow-on work
27
+ that is not yet shipped, and explicit non-features, see the
28
+ [Roots feature catalog](doc/roots-features.md).
29
+
30
+ Further information is available in the [doc folder](/doc).
17
31
 
18
32
  License
19
33
  -------
20
34
 
21
- Bitcoin Core is released under the terms of the MIT license. See [COPYING](COPYING) for more
22
- information or see https://opensource.org/license/MIT.
35
+ Bitcoin Roots is released under the terms of the MIT license. See
36
+ [COPYING](COPYING) for more information or https://opensource.org/license/MIT.
23
37
 
24
38
  Development Process
25
39
  -------------------
26
40
 
27
- The `master` branch is regularly built (see `doc/build-*.md` for instructions) and tested, but it is not guaranteed to be
28
- completely stable. [Tags](https://github.com/bitcoin/bitcoin/tags) are created
29
- regularly from release branches to indicate new official, stable release versions of Bitcoin Core.
41
+ Bitcoin Roots follows Bitcoin Core development and incorporates suitable changes
42
+ for each release. Features that improve node policy, resource control, privacy,
43
+ or operation without changing Bitcoin consensus may also be maintained here.
30
44
 
31
- The https://github.com/bitcoin-core/gui repository is used exclusively for the
32
- development of the GUI. Its master branch is identical in all monotree
33
- repositories. Release branches and tags do not exist, so please do not fork
34
- that repository unless it is for development reasons.
45
+ The project distinguishes local policy from consensus. Transactions rejected by
46
+ local relay or mempool policy may still be valid under Bitcoin consensus, and
47
+ valid blocks containing them must continue to be accepted.
35
48
 
36
- The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md)
37
- and useful hints for developers can be found in [doc/developer-notes.md](doc/developer-notes.md).
49
+ The contribution guide is [CONTRIBUTING.md](CONTRIBUTING.md); developer guidance
50
+ is in [doc/developer-notes.md](doc/developer-notes.md).
38
51
 
39
52
  Testing
40
53
  -------
41
54
 
42
- Testing and code review is the bottleneck for development; we get more pull
43
- requests than we can review and test on short notice. Please be patient and help out by testing
44
- other people's pull requests, and remember this is a security-critical project where any mistake might cost people
45
- lots of money.
55
+ Testing and code review are essential for this security-critical project. Please
56
+ help by testing other contributors' pull requests.
46
57
 
47
58
  ### Automated Testing
48
59
 
49
- Developers are strongly encouraged to write [unit tests](src/test/README.md) for new code, and to
50
- submit new unit tests for old code. Unit tests can be compiled and run
51
- (assuming they weren't disabled during the generation of the build system) with: `ctest`. Further details on running
52
- and extending unit tests can be found in [/src/test/README.md](/src/test/README.md).
60
+ Developers are strongly encouraged to write [unit tests](src/test/README.md).
61
+ Unit tests can be run with `ctest`; further details are in
62
+ [/src/test/README.md](/src/test/README.md).
53
63
 
54
64
  There are also [regression and integration tests](/test), written
55
65
  in Python.
56
66
  These tests can be run (if the [test dependencies](/test) are installed) with: `build/test/functional/test_runner.py`
57
67
  (assuming `build` is your build directory).
58
68
 
59
- The CI (Continuous Integration) systems make sure that every pull request is tested on Windows, Linux, and macOS.
60
- The CI must pass on all commits before merge to avoid unrelated CI failures on new pull requests.
69
+ Continuous integration builds and tests pull requests on supported platforms.
70
+ Required checks must pass before integration.
61
71
 
62
72
  ### Manual Quality Assurance (QA) Testing
63
73
 
64
- Changes should be tested by somebody other than the developer who wrote the
65
- code. This is especially important for large or high-risk changes. It is useful
66
- to add a test plan to the pull request description if testing the changes is
67
- not straightforward.
74
+ Changes should be tested by somebody other than their author, especially when
75
+ they are large or high-risk.
68
76
 
69
- Translations
70
- ------------
77
+ Maintenance
78
+ -----------
71
79
 
72
- Changes to translations as well as new translations can be submitted to
73
- [Bitcoin Core's Transifex page](https://explore.transifex.com/bitcoin/bitcoin/).
80
+ Bitcoin Roots is maintained by the Plan ₿ Foundation under the supervision of
81
+ [Denis "Jaromil" Roio](https://jaromil.dyne.org),
82
+ [Giacomo Zucco](https://x.com/giacomozucco), and
83
+ [S₿AM](https://x.com/sbaaaam21).
74
84
 
75
- Translations are periodically pulled from Transifex and merged into the git repository. See the
76
- [translation process](doc/translation_process.md) for details on how this works.
85
+ Translations
86
+ ------------
77
87
 
78
- **Important**: We do not accept translation changes as GitHub pull requests because the next
79
- pull from Transifex would automatically overwrite them again.
88
+ Do not manually edit generated translations; see the
89
+ [translation process](doc/translation_process.md).