<p>I think you misunderstand how merging pull requests and a Git based release process works on an open source project. A new release is just an old release with a bunch of changes (or pull requests) merged. Every pull request that makes it into a new release has been reviewed and tested by project contributors prior to it being merged. The author of the pull request can themselves do testing in private prior to opening the pull request in public if they so wish. You don't have to wait for a new release to run a version of the code that includes changes on top of the old release.</p>
<p>Generally users do wait for new releases rather than running the latest version of the code (the latest state of the master branch). The maintainers of the project won't cut a new release until they are happy with the level of testing that new release has been subjected to. But some bugs or problems will only be identified by users running say on an obscure operating system or running with a strange configuration. Hence after a new release is cut maintainers will often merge new pull requests to address these bugs before updating that release. The way you phrase the question it seems as if you think each release is ultimately final and there are no intermediate steps between major releases.</p>
<blockquote>
<p>I wonder if a safer approach would be to first test the new releases privately, in some selected nodes (and miners), that are constatly communicating with each other. I the software in incompatible in some way, they can swiftly coordinate to switch back to the old software. This is much harder to do when everyone has installed the new software because there is no way to communicate with all nodes.</p>
</blockquote>
<p>This change was a rather unique change as database formats are rarely switched in Core and no one envisaged this particular change from (temporarily) impacting the consensus rules of the network. If the maintainers and contributors don't identify this possibility and the testing frameworks don't test for it either it needs to be identified in the wild by users testing the release. It slipped through the author's testing, the project's testing and the release's testing.</p>

CC BY-SA 4.0
2024-04-12T12:18:39.973Z
2024-04-12T12:18:39.973Z
Michael Folkson
<p>I think the main vulnerability of Bitcoin is a new release messing things up in a way that it will completely destroy people's faith in the protocol.</p>
<p>By this I mean something like what happened in 2013 with the BerkeleyDB to LevelDB update. That could have ended a lot worse.</p>
<p>If for each release, there is a 0,1% chance of it messing things up, then given enough time some release WILL eventually mess things up.</p>
<p>I wonder if a safer approach would be to first test the new releases privately, in some selected nodes (and miners), that are constatly communicating with each other. I the software in incompatible in some way, they can swiftly coordinate to switch back to the old software. This is much harder to do when everyone has installed the new software because there is no way to communicate with all nodes.</p>
<p>(I know the software is heavily tested in Testnet beforehand, and that is a good thing, but it is not enough, like the 2013 situation showed)</p>

CC BY-SA 4.0
2024-04-15T15:20:36.707Z
It’s not clear to me how your proposal significantly differs from what is happening already when volunteers run the master branch or release candidates on mainnet before the release. It also seems more like a "give feedback to my idea prompt" than a question.
Murch
CC BY-SA 4.0
2024-04-16T16:07:07.973Z
The main difference is that no miners are involved in the testing. No blocks are actually produced by the software that is being tested, which is problematic in my opinion for the reasons presented above.
mathboi
<bitcoin-core><testnet><nodes><testing><march-2013-fork>
Testing new releases privately on selected nodes?
mathboi
# Testing new releases privately on selected nodes?

(Asked by: username_0 on 2024-04-12)

I think the main vulnerability of Bitcoin is a new release messing things up in a way that it will completely destroy people's faith in the protocol.

By this I mean something like what happened in 2013 with the BerkeleyDB to LevelDB update. That could have ended a lot worse.

If for each release, there is a 0,1% chance of it messing things up, then given enough time some release WILL eventually mess things up.

I wonder if a safer approach would be to first test the new releases privately, in some selected nodes (and miners), that are constatly communicating with each other. I the software in incompatible in some way, they can swiftly coordinate to switch back to the old software. This is much harder to do when everyone has installed the new software because there is no way to communicate with all nodes.

(I know the software is heavily tested in Testnet beforehand, and that is a good thing, but it is not enough, like the 2013 situation showed)

**Tags:** bitcoin-core, testnet, nodes, testing, march-2013-fork

> **Comments:**
> **username_1**: It’s not clear to me how your proposal significantly differs from what is happening already when volunteers run the master branch or release candidates on mainnet before the release. It also seems more like a "give feedback to my idea prompt" than a question.  
> **username_0**: The main difference is that no miners are involved in the testing. No blocks are actually produced by the software that is being tested, which is problematic in my opinion for the reasons presented above.  

---

## 1 answers

### Answer by username_2 on 2024-04-12. Score: 0

I think you misunderstand how merging pull requests and a Git based release process works on an open source project. A new release is just an old release with a bunch of changes (or pull requests) merged. Every pull request that makes it into a new release has been reviewed and tested by project contributors prior to it being merged. The author of the pull request can themselves do testing in private prior to opening the pull request in public if they so wish. You don't have to wait for a new release to run a version of the code that includes changes on top of the old release.

Generally users do wait for new releases rather than running the latest version of the code (the latest state of the master branch). The maintainers of the project won't cut a new release until they are happy with the level of testing that new release has been subjected to. But some bugs or problems will only be identified by users running say on an obscure operating system or running with a strange configuration. Hence after a new release is cut maintainers will often merge new pull requests to address these bugs before updating that release. The way you phrase the question it seems as if you think each release is ultimately final and there are no intermediate steps between major releases.

> I wonder if a safer approach would be to first test the new releases privately, in some selected nodes (and miners), that are constatly communicating with each other. I the software in incompatible in some way, they can swiftly coordinate to switch back to the old software. This is much harder to do when everyone has installed the new software because there is no way to communicate with all nodes.

This change was a rather unique change as database formats are rarely switched in Core and no one envisaged this particular change from (temporarily) impacting the consensus rules of the network. If the maintainers and contributors don't identify this possibility and the testing frameworks don't test for it either it needs to be identified in the wild by users testing the release. It slipped through the author's testing, the project's testing and the release's testing.


---

