globalboost / bug-bounties

We are offering a bounty for reporting and/or fixing bugs in our impact repos. The goal is to identify and resolve any issues that may impact the usability or functionality of impactchain(s)

GlobalBoost Core integration/staging tree

https://bitcoincore.org

What is GlobalBoost?

GlobalBoost is an experimental digital currency that enables instant payments to anyone, anywhere in the world. GlobalBoost uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. GlobalBoost Core is the name of open source software which enables the use of this currency.

For more information, as well as an immediately useable, binary version of the GlobalBoost Core software, see https://globalboostcore.org/en/download/

License

GlobalBoost Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is regularly built and tested, but is not guaranteed to be completely stable. Tags are created regularly to indicate new official, stable release versions of GlobalBoost Core.

The contribution workflow is described in CONTRIBUTING.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python, that are run automatically on the build server. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The Travis CI system makes sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.

Translators should also subscribe to the mailing list.

bug-bounties's Issues

the node is not producing the blocks and stuck at block no 2881

Title:

the node is not producing the blocks anymore

Description:

Have been running the impact node from last 7 days and suddenly notice that the block is not producing any more. When i checked the logs in detail, i found that the block has been stopped at number 2881

Reproduce

You should see the issue if you are already running the node, please go to the logs and check if its printing the same blocks.

And if you are not running the nodes, you can follow the document below to setup and run the node
https://globalboost.github.io/impactprotocol-book/

Expected behavior:

You should see new blocks being produce in every 12 seconds

Actual behavior:

The blocks are not getting produced and its being stuck at 2881

Context:

I am using the macOS machine and terminal shell to run the node

Assignee: @impact-team

Labels: bug, documentation

Minimum Hardware Requirement

on the installation pages the dev team has giving the details already:
RAM: 4GB RAM(or 8GB for better performance)
CPU: 2Cores cpu
Disk: 256GB SSD Disk

Details:
Anyone can create new nodes under the minimum specification, i see as of now (20/may/23, 10:54AM UTC+7) there is still 5% testnet user are using below minimum requirement hardware. i've try myself using 1 core of cpu nodes are okay on testnet as long as we're limiting the cpu usage (otherwise it's automatically get killed), or using systemctl to automatically restart the apps if it's got killed by system. but it could having much problem on the future mainnet.

Problem:
If there are too many blockchain validator nodes that do not meet the minimum specifications on a Substrate based blockchain, it can have several implications:

1. Performance degradation: Validator nodes that are below the minimum specifications may struggle to handle the computational and storage requirements of the blockchain network. As a result, the overall performance of the network can suffer, leading to slower transaction processing times and decreased responsiveness.
2. Increased risk of forks: Validator nodes that are unable to keep up with the network demands may experience delays in propagating blocks or validating transactions. This situation can potentially lead to increased fork rates, where different parts of the network have different views of the blockchain's state. Forks can undermine the consensus mechanism and compromise the security and integrity of the blockchain.
3. Centralization risk: If a significant number of validator nodes fail to meet the minimum specifications, it may result in a more centralized network. A decentralized blockchain relies on a diverse set of validators to maintain security and prevent any single entity from gaining too much control. If many validators are unable to participate effectively, it can concentrate power in the hands of a few well-equipped nodes, undermining the decentralization principles.
4. Network instability: Inadequate validator nodes may experience frequent crashes, downtime, or unreliable connectivity. This instability can disrupt the consensus process and the overall network operation. Validators are expected to be available and reliable to maintain the blockchain's stability and ensure the accuracy of the shared ledger.

Solution:
It should better if the team creating a system check before node running, if it's didn't meet the minimum requirement hardware, the nodes should be killed and not allowed to run the node apps.

Disk Full cleaned up but auto restart will keep failing

One of my nodes currently has a disk full problem, i'm trying to remove some old files (and was getting around 17Gb free disk space), the trying to re-run (restart) the impactprotocol nodes, but it's keep failing and can't run with some error said database not on the right version.

Details:
the nodes with disk full will stop nodes automatically, but having more free space doesn't automatically allow nodes running with simple restart.

Problem:
there is still giving error for directly restart the nodes.
here is the logs:

May 23 00:41:35 testnet3 impact[4040030]: 2023-05-23 00:41:35 Impact Protocol Node
May 23 00:41:35 testnet3 impact[4040030]: 2023-05-23 00:41:35 ✌️ version 3.0.0-dev-2e7bbbc4751
May 23 00:41:35 testnet3 impact[4040030]: 2023-05-23 00:41:35 ❤️ by Parity Technologies [email protected], 2023-2023
May 23 00:41:35 testnet3 impact[4040030]: 2023-05-23 00:41:35 📋 Chain specification: Impact Protocol EVM Testnet
May 23 00:41:35 testnet3 impact[4040030]: 2023-05-23 00:41:35 🏷 Node name: NakedDog
May 23 00:41:35 testnet3 impact[4040030]: 2023-05-23 00:41:35 👤 Role: AUTHORITY
May 23 00:41:35 testnet3 impact[4040030]: 2023-05-23 00:41:35 💾 Database: RocksDb at /tmp/impactnode/chains/impact_testnet/db/full
May 23 00:41:35 testnet3 impact[4040030]: 2023-05-23 00:41:35 ⛓ Native runtime: impact-runtime-268 (impact-runtime-0.tx2.au10)
May 23 00:41:35 testnet3 systemd[1]: impact.service: Main process exited, code=exited, status=1/FAILURE
May 23 00:41:35 testnet3 systemd[1]: impact.service: Failed with result 'exit-code'.
May 23 00:41:46 testnet3 systemd[1]: impact.service: Scheduled restart job, restart counter is at 4973.
May 23 00:41:46 testnet3 systemd[1]: Stopped Impact Protocol Node.
May 23 00:41:46 testnet3 systemd[1]: Started Impact Protocol Node.
May 23 00:41:46 testnet3 impact[4040051]: Error: Service(Client(Backend("Database version cannot be read from existing db_version file")))

Solution:
i only found the simple solution is removing the /db/full folder. at my case, i need to remove the folder "/tmp/impactnode/chains/impact_testnet/db/full" then restart the nodes app will works. but this need time to sync. as on testnet it's only around 50k blocks which reached within 3 mins. but on mainnet it could be millions to billions blocks and this will need a lot of time to get synced.