[ANN]BitQube (BTQ) — GPU-Mineable PoW Coin | Official Project

[BitQube]

Hello Bitcointalk community,

This is the official BitQube (BTQ) project thread.

BitQube was launched recently and mining is already active. A small number of miners have started mining BTQ, and we are now opening this official Bitcointalk thread so that miners, users, developers and the wider community can find official information and ask questions directly.

🔹 BitQube (BTQ)

* Ticker: BTQ
* Consensus: Proof-of-Work
* Algorithm: KawPoW
* Mining: GPU
* Total Supply: 8,000,000 BTQ
* Premine: 641,600 BTQ
* Open Mining: 7,358,400 BTQ

🔹 Official Sources

Website: https://bitqube.org
Explorer: https://explorer.bitqube.org
Mining Pool: https://pool.bitqube.org
GitHub: https://github.com/bitqube/bitqube

🔹 Why This Official Thread?

Some community members have already posted about BitQube on Bitcointalk.

Those discussions can be useful, but this thread is intended to be the official source for BitQube project information, updates and clarification of questions.

We welcome everyone to ask questions about:

* Mining and mining setup
* Blockchain and network
* Tokenomics and supply
* Wallets and technical issues
* Development
* Future ecosystem plans

BitQube is at an early stage, and we are building the ecosystem step by step with the community.

Welcome to BitQube.

Official BitQube Team

[BitQube]

Thank you for taking the time to actually review the BitQube repository and chain rather than simply making assumptions. We appreciate the detailed feedback, and we agree that miners should verify the code and network for themselves.

A few points deserve clarification from the BitQube team:

1. Ecosystem Reserve / 641,600 BTQ

Yes — this part is correct.

BitQube has a fixed maximum supply of 8,000,000 BTQ.

• 641,600 BTQ (8.02%) — Ecosystem Reserve, created in block 1
• 7,358,400 BTQ (91.98%) — Community mining emission

The 8.02% figure is therefore based on the total 8,000,000 BTQ maximum supply, not on the amount of BTQ that happens to exist at an early block height.

At the very beginning of a PoW chain, the reserve naturally represents a much larger percentage of the coins currently in existence because the remaining 7,358,400 BTQ has not yet been mined.

The reserve allocation is disclosed in the current BitQube README and is not hidden. It is intended for development, infrastructure, security, partnerships and listings.

2. Current holder distribution

We agree that early-chain distribution can be highly concentrated.

This is a newly launched PoW network and the majority of the eventual 7,358,400 BTQ mining emission has obviously not yet entered circulation.

We encourage miners to independently examine the explorer and distribution data rather than relying on statements from the project team.

We also agree that publishing clearer information about the reserve addresses and their intended use is beneficial for the community.

3. Mining hashrate and network security

The concern about early hashrate concentration is reasonable.

BitQube is a PoW/KawPoW network, and independent miners and independent pools are important to network decentralization.

The pool statistics have also changed since the numbers quoted in the original post. The public pool currently shows 12 miners and approximately 572 MH/s, so the quoted 8 miners / 696 MH/s is already an older snapshot.

We do NOT want BitQube to depend permanently on a single pool.

Our objective is to attract independent miners, additional pools, GPU mining operators and eventually broader infrastructure participation.

We encourage anyone with mining infrastructure to run an independent BitQube node and, where possible, operate independent mining infrastructure rather than assuming the official pool should represent the entire network.

4. Asset issuance fees

This point is correct and we want to be completely clear about it.

On BitQube mainnet, the asset issuance fees are sent to designated fee addresses rather than being sent to the traditional Ravencoin-style burn addresses.

This was an intentional protocol change and is visible directly in the source code.

Commit e93488c explicitly changed the terminology and logic from BurnAddress to FeeAddress.

The current mainnet code also identifies the fee address as a spendable administrative/project address.

The testnet configuration still uses the traditional burn addresses.

We understand why miners and asset issuers would want this clearly documented, and we agree that the documentation should explain the purpose and governance of these fees more explicitly.

5. The old about file

This criticism is valid.

The repository’s old about file still contains inherited text stating that BitQube has “no pre-mine” or developer allocation.

That text is outdated and conflicts with the current BitQube tokenomics.

The current README correctly documents the 641,600 BTQ Ecosystem Reserve.

We will treat the outdated about text as documentation that needs to be corrected rather than trying to defend an obvious inconsistency.

6. Repository / binary housekeeping

We also agree with the general principle that miners should be able to reproduce BitQube from source and verify what they are running.

The repository is open source and provides build instructions. Anyone operating serious mining hardware should build from a trusted source/release and verify binaries rather than blindly executing an unknown binary.

Bottom line

We don’t expect miners to trust BitQube simply because the team says so.

The chain is open source, PoW/KawPoW, and its consensus parameters, emission schedule and asset-fee rules can be inspected directly.

We welcome independent miners, developers and security researchers reviewing the code and pointing out inconsistencies.

If something is factually wrong, we will correct it.

If something is intentionally designed that way, we will explain why.

And if something in the documentation is simply outdated, we will fix the documentation.

For miners, the most important next step is exactly what the original poster suggested: verify the code, verify the chain, and make your own decision.

Thank you again for doing the technical review and raising these questions.

BitQube Team

[lightbit]

Hey! Congrats on the launch.

I couldn't find the discord link... could you please share? Thanks.

[BitQube]

Thanks for the constructive follow-up. 🙏

I agree that these are the right questions to document publicly, and I appreciate the fact that you’re approaching them from a transparency perspective rather than as a “gotcha.”

For clarity, here is our position on each point:

1) BTQ ecosystem reserve

The 641,600 BTQ premine represents approximately 8.02% of the 8,000,000 BTQ maximum supply and is intended for the BitQube ecosystem, including development, infrastructure, listings and other ecosystem requirements.

We agree that the most useful information is the on-chain address and transaction history, rather than simply describing the purpose of the allocation.

We will publish the relevant reserve address and its on-chain status so that anyone can independently verify the balance and movements through the BitQube explorer.

2) Fee addresses

We acknowledge the two fee destinations currently defined in chainparams.cpp.

Rather than making an unsupported claim about key management, we will document the actual control arrangement — including whether the addresses are single-signature or multisignature and the applicable operational controls.

Again, the objective is that users should be able to verify the information themselves rather than relying on statements from the project.

3) Initial 5,000-block mining period

Your description of the nCPUMiningEpochBlocks = 5000 configuration is an important point to explain to miners.

The initial difficulty configuration and the block-1 premine are part of the chain’s launch history. We agree that this should be explicitly documented in the ANN/README so that anyone joining later understands the conditions under which the network started.

We will distinguish clearly between:

* the 641,600 BTQ ecosystem allocation;
* normal block emissions during the initial mining period; and
* the subsequent open-mining emission available to the public.

We don’t want new miners to have to reconstruct these details from source code themselves.

4) Network hashrate and decentralization

Agreed.

A small network with a limited number of independent miners naturally has higher concentration and therefore higher theoretical reorganization/51%-type risk than a mature PoW network with diversified hashrate.

This is one of the reasons we are actively encouraging independent miners and additional pools, rather than treating the current official pool hashrate as representative of long-term network decentralization.

The current network should be evaluated according to what it actually is today, not presented as if it already has the security profile of a mature PoW network.

Most importantly, we agree with your final point:

Code + explorer + on-chain data should remain the source of truth.

We’ll work on publishing the reserve-address information and fee-address/key-management information so these points can be independently verified.

Thanks again for taking the time to inspect the repository and raise the questions publicly. This type of scrutiny is useful for an early-stage PoW project. 👍Thanks for asking! 👋

We’ve now opened the official BitQube Discord community for BTQ miners, QUBX validators, developers, ecosystem users, and community members.

💬 Official BitQube Discord:
https://discord.gg/zGmprHnbC

Everyone is welcome to join and discuss BitQube, BTQ mining, QUBX, development, the ecosystem, and the BitQube Metaverse. 🚀

Welcome to the community!

[BitQube]

Thank you — we genuinely appreciate the constructive feedback and the respectful approach. 🙏

We agree with you that the best way to address these points is through verifiable information rather than explanations alone.

We’re working on the three items you highlighted:

• Reserve address: making the 641,600 BTQ reserve clearly identifiable and traceable through the explorer.

• Fee-address control: documenting the current control structure clearly, including whether it is single-signature or multisignature and how it is managed.

• Launch conditions: updating the README so the launch, supply, premine/reserve, emission and related conditions are clearly documented in one place.

Until these updates are completed and publicly verifiable, we’re comfortable calling them “coming” rather than “done.”

BitQube is still an early-stage project, and we believe transparency should improve as the ecosystem develops. Anyone should be able to independently verify the important information without having to simply trust our statements.

Thanks again for taking the time to review the project and for keeping the discussion constructive. We’ll continue building and publishing the improvements openly. 🚀

— BitQube Team