Skip to content
Bitcoin Roots

v30.3-roots.1 · Commit 5: [PATCH 05/68] feat(qt): preserve Roots identity and GUI support on Core 30.3

README.md

Before: README.md · After: README.md

File metadata
index cfabb7f6723b0fb1cc30db62c776875b868f42a1..6425b4a23b39116eea64751065a224de06f14c78 100644

Download original patch · Release notes

Diff rows 1–126 of 126. 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,84 @@
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
+ For an immediately usable binary release, see
7
+ [plan-b.foundation/bitcoin-roots](https://plan-b.foundation/bitcoin-roots/).
8
8
 
9
- What is Bitcoin Core?
10
- ---------------------
9
+ What is Bitcoin Roots?
10
+ ----------------------
11
11
 
12
- Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully
12
+ Bitcoin Roots connects to the Bitcoin peer-to-peer network to download and fully
13
13
  validate blocks and transactions. It also includes a wallet and graphical user
14
14
  interface, which can be optionally built.
15
15
 
16
- Further information about Bitcoin Core is available in the [doc folder](/doc).
16
+ Bitcoin Roots is based on Bitcoin Core with selected policy features from the
17
+ Bitcoin Knots `29.3.knots20260507` code line. The Knots reference describes
18
+ feature lineage only; Bitcoin Core v30.3 is the direct base.
19
+
20
+ Bitcoin Roots remains compatible with Bitcoin Core consensus. Its conservative
21
+ transaction relay and mempool policy is local and configurable: a transaction
22
+ rejected by policy can still be consensus-valid, and valid blocks containing it
23
+ remain acceptable. Bitcoin Roots does not enforce RDTS/BIP110 consensus rules.
24
+
25
+ Further information is available in the [doc folder](/doc).
17
26
 
18
27
  License
19
28
  -------
20
29
 
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.
30
+ Bitcoin Roots is released under the terms of the MIT license. See
31
+ [COPYING](COPYING) for more information or https://opensource.org/license/MIT.
23
32
 
24
33
  Development Process
25
34
  -------------------
26
35
 
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.
36
+ Bitcoin Roots follows Bitcoin Core development and incorporates suitable changes
37
+ for each release. Features that improve node policy, resource control, privacy,
38
+ or operation without changing Bitcoin consensus may also be maintained here.
30
39
 
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.
40
+ The project distinguishes local policy from consensus. Transactions rejected by
41
+ local relay or mempool policy may still be valid under Bitcoin consensus, and
42
+ valid blocks containing them must continue to be accepted.
35
43
 
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).
44
+ The contribution guide is [CONTRIBUTING.md](CONTRIBUTING.md); developer guidance
45
+ is in [doc/developer-notes.md](doc/developer-notes.md).
38
46
 
39
47
  Testing
40
48
  -------
41
49
 
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.
50
+ Testing and code review are essential for this security-critical project. Please
51
+ help by testing other contributors' pull requests.
46
52
 
47
53
  ### Automated Testing
48
54
 
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).
55
+ Developers are strongly encouraged to write [unit tests](src/test/README.md).
56
+ Unit tests can be run with `ctest`; further details are in
57
+ [/src/test/README.md](/src/test/README.md).
53
58
 
54
59
  There are also [regression and integration tests](/test), written
55
60
  in Python.
56
61
  These tests can be run (if the [test dependencies](/test) are installed) with: `build/test/functional/test_runner.py`
57
62
  (assuming `build` is your build directory).
58
63
 
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.
64
+ Continuous integration builds and tests pull requests on supported platforms.
65
+ Required checks must pass before integration.
61
66
 
62
67
  ### Manual Quality Assurance (QA) Testing
63
68
 
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.
69
+ Changes should be tested by somebody other than their author, especially when
70
+ they are large or high-risk.
68
71
 
69
- Translations
70
- ------------
72
+ Maintenance
73
+ -----------
71
74
 
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/).
75
+ Bitcoin Roots is maintained by the Plan ₿ Foundation under the supervision of
76
+ [Denis "Jaromil" Roio](https://jaromil.dyne.org),
77
+ [Giacomo Zucco](https://x.com/giacomozucco), and
78
+ [S₿AM](https://x.com/sbaaaam21).
74
79
 
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.
80
+ Translations
81
+ ------------
77
82
 
78
- **Important**: We do not accept translation changes as GitHub pull requests because the next
79
- pull from Transifex would automatically overwrite them again.
83
+ Do not manually edit generated translations; see the
84
+ [translation process](doc/translation_process.md).