[ANN] CivicNet (CIVIC) | Hybrid PoW+PoS, ASIC-Resistant | CPU Mining

[CivicLight]

Is there a build for the newer system? I am getting the following error on my 26.04 Ubuntu: ./civicnet-qt: error while loading shared libraries: libfmt.so.8: cannot open shared object file: No such file or directory. How do I correct this error?

Thanks for reporting this!

This error happens because our binary was compiled against libfmt version 8, but newer Ubuntu releases (like 24.04+) ship with a newer version of libfmt by default, which isn't backward-compatible at the shared library level.

You have a few options to fix this on your end:

Option 1 - Install libfmt8 directly (if available in your repos):
```
sudo apt install libfmt8
```

Option 2 - If libfmt8 isn't available in your package manager, you can create a symlink to your existing newer libfmt:
```
# First, find which version you have:
find / -name "libfmt.so*" 2>/dev/null

# Then symlink it (adjust the version number to match what you found):
sudo ln -s /usr/lib/x86_64-linux-gnu/libfmt.so.9 /usr/lib/x86_64-linux-gnu/libfmt.so.8
sudo ldconfig
```
Note: this works in most cases since libfmt maintains good backward compatibility, but isn't 100% guaranteed depending on the exact API used.

Option 3 - Build from source instead, which will link against whatever libfmt version is available on your system:
```
git clone https://github.com/CivicLight/CivicNet.git
cd CivicNet
./autogen.sh && ./configure && make
```

We'll look into providing a statically-linked build in a future release to avoid this kind of dependency mismatch on newer distros. Thanks again for flagging it!

[sdnz]

It seems still cannot find peer with new binary. Is the seed node running with new release yet? 

[Firsttime13]

Is there a build for the newer system? I am getting the following error on my 26.04 Ubuntu: ./civicnet-qt: error while loading shared libraries: libfmt.so.8: cannot open shared object file: No such file or directory. How do I correct this error?

Thanks for reporting this!

This error happens because our binary was compiled against libfmt version 8, but newer Ubuntu releases (like 24.04+) ship with a newer version of libfmt by default, which isn't backward-compatible at the shared library level.

You have a few options to fix this on your end:

Option 1 - Install libfmt8 directly (if available in your repos):
```
sudo apt install libfmt8
```

Option 2 - If libfmt8 isn't available in your package manager, you can create a symlink to your existing newer libfmt:
```
# First, find which version you have:
find / -name "libfmt.so*" 2>/dev/null

# Then symlink it (adjust the version number to match what you found):
sudo ln -s /usr/lib/x86_64-linux-gnu/libfmt.so.9 /usr/lib/x86_64-linux-gnu/libfmt.so.8
sudo ldconfig
```
Note: this works in most cases since libfmt maintains good backward compatibility, but isn't 100% guaranteed depending on the exact API used.

Option 3 - Build from source instead, which will link against whatever libfmt version is available on your system:
```
git clone https://github.com/CivicLight/CivicNet.git
cd CivicNet
./autogen.sh && ./configure && make
```

We'll look into providing a statically-linked build in a future release to avoid this kind of dependency mismatch on newer distros. Thanks again for flagging it!

Under option 3, here is the error I get when trying the make cmd: make: *** No targets specified and no makefile found.  Stop.

[CivicLight]

It seems still cannot find peer with new binary. Is the seed node running with new release yet? 

Update: Our node is now running the correct pchMessageStart values (matching commit 4c527e8 / V1.0.1).

Thanks for flagging this - you were right, our production node was temporarily running on the older parameters while we handled some infrastructure work. This has now been corrected without any chain reset, so the network should be consistent going forward.

Please try connecting again:
addnode=103.180.165.99:9333

Regarding the build issue from your second question ("No targets specified and no makefile found") - this happens when ./autogen.sh or ./configure didn't complete successfully before running make. Could you scroll up in your terminal and check if either of those steps printed any errors? Common causes are missing build dependencies (autoconf, libtool, pkg-config, or the boost/berkeley-db dev packages). If you can share the output from ./autogen.sh && ./configure, we can help pinpoint what's missing.

[CivicLight]

Update: Windows Wallet (v1.0.1) is now available!

Following up on the pchMessageStart fix and the Windows build questions from earlier - we've published an updated release with a proper Windows GUI wallet build.

Download: https://github.com/CivicLight/CivicNet/releases/tag/V1.0.1

What's included:
- civicnet-qt.exe - standalone Windows GUI wallet, no external dependencies needed (statically linked)
- Includes the pchMessageStart fix (magic bytes now correctly match the network)
- New installs will automatically connect to our official node - no manual addnode setup required
- Fixed wallet ticker (now correctly shows CIVIC) and application icon

Linux binaries are also available in the same release. For the earlier libfmt.so.8 error on Linux, please see the fix options in our previous reply above (installing libfmt8, symlinking, or building from source).

Let us know if you run into any issues!

[Firsttime13]

Update: Windows Wallet (v1.0.1) is now available!

Following up on the pchMessageStart fix and the Windows build questions from earlier - we've published an updated release with a proper Windows GUI wallet build.

Download: https://github.com/CivicLight/CivicNet/releases/tag/V1.0.1

What's included:
- civicnet-qt.exe - standalone Windows GUI wallet, no external dependencies needed (statically linked)
- Includes the pchMessageStart fix (magic bytes now correctly match the network)
- New installs will automatically connect to our official node - no manual addnode setup required
- Fixed wallet ticker (now correctly shows CIVIC) and application icon

Linux binaries are also available in the same release. For the earlier libfmt.so.8 error on Linux, please see the fix options in our previous reply above (installing libfmt8, symlinking, or building from source).

Let us know if you run into any issues!

Here is the error that appears after the ./configure cmd is given: libdb_cxx headers missing, CivicNet Core requires this library for wallet functionality (--disable-wallet to disable wallet functionality). I have the most up to date library already installed. Is there a way to import the PvtKey to the web wallet instead of using seed phrases?

[CivicLight]

Update: Windows Wallet (v1.0.1) is now available!

Following up on the pchMessageStart fix and the Windows build questions from earlier - we've published an updated release with a proper Windows GUI wallet build.

Download: https://github.com/CivicLight/CivicNet/releases/tag/V1.0.1

What's included:
- civicnet-qt.exe - standalone Windows GUI wallet, no external dependencies needed (statically linked)
- Includes the pchMessageStart fix (magic bytes now correctly match the network)
- New installs will automatically connect to our official node - no manual addnode setup required
- Fixed wallet ticker (now correctly shows CIVIC) and application icon

Linux binaries are also available in the same release. For the earlier libfmt.so.8 error on Linux, please see the fix options in our previous reply above (installing libfmt8, symlinking, or building from source).

Let us know if you run into any issues!

Here is the error that appears after the ./configure cmd is given: libdb_cxx headers missing, CivicNet Core requires this library for wallet functionality (--disable-wallet to disable wallet functionality). I have the most up to date library already installed. Is there a way to import the PvtKey to the web wallet instead of using seed phrases?

Thanks for reporting both!

On the build error (libdb_cxx missing) - are you building on Linux or Windows? That'll help us give you the right fix (the dependency setup is different between the two).

On importing a private key to the web wallet:

Currently the web wallet does not support private key import - it only supports the seed phrase (mnemonic) method.

[CivicLight]

Update: We now have a proper domain!

CivicNet has moved to a proper domain setup, with everything organized and secured under HTTPS.

New links:

Website :	civiclight.xyz
Pool :	pool.civiclight.xyz
Block Explorer :	explorer.civiclight.xyz
Web Wallet :	webwallet.civiclight.xyz

DNS Seed:

We've also set up a proper DNS seed (dnsseed.civiclight.xyz), so new nodes running the latest client can now discover peers automatically without needing to manually configure addnode.

What this means for you:

• Existing miners and node operators: nothing changes, your current setup keeps working exactly the same
• New users: cleaner, permanent URLs to bookmark going forward
• New node operators: peer discovery now works automatically out of the box

As always, thanks for the feedback that's pushed us to keep improving this.

[Firsttime13]

Update: Windows Wallet (v1.0.1) is now available!

Following up on the pchMessageStart fix and the Windows build questions from earlier - we've published an updated release with a proper Windows GUI wallet build.

Download: https://github.com/CivicLight/CivicNet/releases/tag/V1.0.1

What's included:
- civicnet-qt.exe - standalone Windows GUI wallet, no external dependencies needed (statically linked)
- Includes the pchMessageStart fix (magic bytes now correctly match the network)
- New installs will automatically connect to our official node - no manual addnode setup required
- Fixed wallet ticker (now correctly shows CIVIC) and application icon

Linux binaries are also available in the same release. For the earlier libfmt.so.8 error on Linux, please see the fix options in our previous reply above (installing libfmt8, symlinking, or building from source).

Let us know if you run into any issues!

Here is the error that appears after the ./configure cmd is given: libdb_cxx headers missing, CivicNet Core requires this library for wallet functionality (--disable-wallet to disable wallet functionality). I have the most up to date library already installed. Is there a way to import the PvtKey to the web wallet instead of using seed phrases?

Thanks for reporting both!

On the build error (libdb_cxx missing) - are you building on Linux or Windows? That'll help us give you the right fix (the dependency setup is different between the two).

On importing a private key to the web wallet:

Currently the web wallet does not support private key import - it only supports the seed phrase (mnemonic) method.

I am using Ubuntu 26.04 as my building platform. All updates have been done and dependencies added.

[CivicLight]

Update: Windows Wallet (v1.0.1) is now available!

Following up on the pchMessageStart fix and the Windows build questions from earlier - we've published an updated release with a proper Windows GUI wallet build.

Download: https://github.com/CivicLight/CivicNet/releases/tag/V1.0.1

What's included:
- civicnet-qt.exe - standalone Windows GUI wallet, no external dependencies needed (statically linked)
- Includes the pchMessageStart fix (magic bytes now correctly match the network)
- New installs will automatically connect to our official node - no manual addnode setup required
- Fixed wallet ticker (now correctly shows CIVIC) and application icon

Linux binaries are also available in the same release. For the earlier libfmt.so.8 error on Linux, please see the fix options in our previous reply above (installing libfmt8, symlinking, or building from source).

Let us know if you run into any issues!

Here is the error that appears after the ./configure cmd is given: libdb_cxx headers missing, CivicNet Core requires this library for wallet functionality (--disable-wallet to disable wallet functionality). I have the most up to date library already installed. Is there a way to import the PvtKey to the web wallet instead of using seed phrases?

Thanks for reporting both!

On the build error (libdb_cxx missing) - are you building on Linux or Windows? That'll help us give you the right fix (the dependency setup is different between the two).

On importing a private key to the web wallet:

Currently the web wallet does not support private key import - it only supports the seed phrase (mnemonic) method.

I am using Ubuntu 26.04 as my building platform. All updates have been done and dependencies added.

If building from source on Ubuntu 26.04 feels confusing, you don't have to - just use the prebuilt Windows QT wallet v1.0.1, or the web wallet (now supports both recovery phrase and private key import): https://webwallet.civiclight.xyz

[CivicLight]

🔥 Update: civiclight v2 is here — real ASIC resistance, live July 23

We've been upfront from the start that the original civiclight algorithm was CPU-friendly in practice, but not truly ASIC-resistant by design. Today, that changes.

civiclight v2 is a memory-hard upgrade to the algorithm — same name, same mining command, but a fundamentally stronger core that makes specialized mining hardware impractical to build.

⏰ Hard fork activates: July 23, 2026, 09:00 UTC

What you need to do:

• Download the v2 release: Node/CLI/Miner (Linux & Windows) or Windows Miner
  
• Replace your current binaries with the new ones
• Restart before the fork time — mining command stays

Code:

-a civiclight

, nothing else changes

Miners who don't update in time will fall out of sync with the network after the fork activates, so don't wait until the last hour.

Full details, technical specs, and updated getting-started guide are in the main post above.

Happy to answer any questions about the upgrade below — testing feedback and bug reports welcome as always.

[fibonacciopstan]

It is a good sign that the team openly admits civiclight v1 did not provide the level of ASIC resistance originally intended and is replacing it with v2 through a public hard fork.

At the same time, this is exactly the kind of project history that should remain independently verifiable. Miners joining later may want to confirm what v1 originally promised, when the weakness was acknowledged, what rules changed at the fork, whether the 1% developer allocation stayed the same, and how the planned transition to hybrid PoW + PoS evolved.

The current announcement is being updated with new releases, infrastructure changes and roadmap progress. That is convenient, but updating one post can also blur the distinction between what was stated before the fork and what was added afterward. GitHub tags preserve code, yet they do not necessarily preserve every official explanation, commitment or warning shown to users at that time.

Does CivicNet publish these announcements into an append-only, timestamped record where earlier statements remain visible and cannot be rewritten after a protocol change? I would like to review it, so could you point me to the relevant page or channel?

[CivicLight]

Another update since we last spoke.

We just completed a hard fork to civiclight v2, a memory-hard algorithm — this directly addresses the ASIC-resistance concern raised early on in this thread, which was fair criticism at the time. Real network hashrate dropped from ~7 GH/s to ~44 kH/s immediately after activation, which we take as confirmation that most of the pre-fork hashrate wasn't coming from CPUs. The algorithm is now doing what we said it eventually would.

We also hit and fixed a difficulty-adjustment bug in the hours after the fork (inherited difficulty from the old algorithm didn't reset fast enough for yespower's cost) — caught it, patched it, tested on testnet, deployed the fix same day. Not claiming a flawless launch, just that we're actively maintaining this, not just shipping and disappearing.

Also worth mentioning: our whitepaper is now published on the site (civiclight.xyz/whitepaper.html), covering the full technical design — including a finalized (not yet implemented) direction for a Hybrid PoW+PoS model we're planning next, alongside consensus-level specs for the algorithm and tokenomics.

It is a good sign that the team openly admits civiclight v1 did not provide the level of ASIC resistance originally intended and is replacing it with v2 through a public hard fork.

At the same time, this is exactly the kind of project history that should remain independently verifiable. Miners joining later may want to confirm what v1 originally promised, when the weakness was acknowledged, what rules changed at the fork, whether the 1% developer allocation stayed the same, and how the planned transition to hybrid PoW + PoS evolved.

The current announcement is being updated with new releases, infrastructure changes and roadmap progress. That is convenient, but updating one post can also blur the distinction between what was stated before the fork and what was added afterward. GitHub tags preserve code, yet they do not necessarily preserve every official explanation, commitment or warning shown to users at that time.

Does CivicNet publish these announcements into an append-only, timestamped record where earlier statements remain visible and cannot be rewritten after a protocol change? I would like to review it, so could you point me to the relevant page or channel?

to your question directly: this is a sharp ask, and honestly, no — we don't currently have a dedicated append-only, timestamped record beyond what's implicitly available:

1. Individual reply posts in this thread (as opposed to the top post, which we do edit for the [UPDATES] index) are timestamped by Bitcointalk itself and remain in sequence unless edited — the forum flags edited posts, so unedited replies are a reasonably reliable trail. But that's a property of the forum, not something we built or guarantee.

2. Our Telegram channel/group has the same limitation — messages can technically be deleted or edited, so it's not a reliable append-only source either.

3. GitHub commit history preserves code changes with verifiable timestamps, but as you correctly point out, it doesn't capture the surrounding commitments, warnings, or explanations we gave alongside those changes.

So to directly answer: no, we don't have that system yet, and you're right to ask before taking anything we say — here, Telegram, or anywhere else — at face value.

What we can do, and will: publish a dated CHANGELOG/ANNOUNCEMENTS file directly in the GitHub repo, git-committed rather than edited in place. Git history is append-only in practice once pushed and pulled by others, and commit timestamps are independently verifiable — that gets much closer to what you're describing than a forum thread or chat channel does. We'll get that started and link it here once it's up.

Appreciate the scrutiny — this is exactly the kind of question a project should have a good answer to.

[fibonacciopstan]

Another update since we last spoke.

We just completed a hard fork to civiclight v2, a memory-hard algorithm — this directly addresses the ASIC-resistance concern raised early on in this thread, which was fair criticism at the time. Real network hashrate dropped from ~7 GH/s to ~44 kH/s immediately after activation, which we take as confirmation that most of the pre-fork hashrate wasn't coming from CPUs. The algorithm is now doing what we said it eventually would.

We also hit and fixed a difficulty-adjustment bug in the hours after the fork (inherited difficulty from the old algorithm didn't reset fast enough for yespower's cost) — caught it, patched it, tested on testnet, deployed the fix same day. Not claiming a flawless launch, just that we're actively maintaining this, not just shipping and disappearing.

Also worth mentioning: our whitepaper is now published on the site (civiclight.xyz/whitepaper.html), covering the full technical design — including a finalized (not yet implemented) direction for a Hybrid PoW+PoS model we're planning next, alongside consensus-level specs for the algorithm and tokenomics.

It is a good sign that the team openly admits civiclight v1 did not provide the level of ASIC resistance originally intended and is replacing it with v2 through a public hard fork.

At the same time, this is exactly the kind of project history that should remain independently verifiable. Miners joining later may want to confirm what v1 originally promised, when the weakness was acknowledged, what rules changed at the fork, whether the 1% developer allocation stayed the same, and how the planned transition to hybrid PoW + PoS evolved.

The current announcement is being updated with new releases, infrastructure changes and roadmap progress. That is convenient, but updating one post can also blur the distinction between what was stated before the fork and what was added afterward. GitHub tags preserve code, yet they do not necessarily preserve every official explanation, commitment or warning shown to users at that time.

Does CivicNet publish these announcements into an append-only, timestamped record where earlier statements remain visible and cannot be rewritten after a protocol change? I would like to review it, so could you point me to the relevant page or channel?

to your question directly: this is a sharp ask, and honestly, no — we don't currently have a dedicated append-only, timestamped record beyond what's implicitly available:

1. Individual reply posts in this thread (as opposed to the top post, which we do edit for the [UPDATES] index) are timestamped by Bitcointalk itself and remain in sequence unless edited — the forum flags edited posts, so unedited replies are a reasonably reliable trail. But that's a property of the forum, not something we built or guarantee.

2. Our Telegram channel/group has the same limitation — messages can technically be deleted or edited, so it's not a reliable append-only source either.

3. GitHub commit history preserves code changes with verifiable timestamps, but as you correctly point out, it doesn't capture the surrounding commitments, warnings, or explanations we gave alongside those changes.

So to directly answer: no, we don't have that system yet, and you're right to ask before taking anything we say — here, Telegram, or anywhere else — at face value.

What we can do, and will: publish a dated CHANGELOG/ANNOUNCEMENTS file directly in the GitHub repo, git-committed rather than edited in place. Git history is append-only in practice once pushed and pulled by others, and commit timestamps are independently verifiable — that gets much closer to what you're describing than a forum thread or chat channel does. We'll get that started and link it here once it's up.

Appreciate the scrutiny — this is exactly the kind of question a project should have a good answer to.

Thank you for the honest and detailed response. CivicNet is exactly the kind of serious project we would like to feature on Opstan.

Opstan is a decentralized social network where publications are stored permanently in a Proof-of-Work blockchain and cannot later be edited or deleted. We would like to create a CivicNet channel, describe the project, and publish its important news, technical updates, milestones and development history.

This would help more people discover CivicNet and give the project an additional layer of reputation. Anyone could review the original publications and see how the team handled upgrades, problems and roadmap commitments without relying only on editable websites or social networks.

It would also allow people from different parts of the world, including regions where access to certain platforms is limited, to follow information about CivicNet through the Opstan network.

Would you be comfortable with CivicNet appearing on Opstan through a dedicated channel containing information and news about the project?

[CivicLight]

Another update since we last spoke.

We just completed a hard fork to civiclight v2, a memory-hard algorithm — this directly addresses the ASIC-resistance concern raised early on in this thread, which was fair criticism at the time. Real network hashrate dropped from ~7 GH/s to ~44 kH/s immediately after activation, which we take as confirmation that most of the pre-fork hashrate wasn't coming from CPUs. The algorithm is now doing what we said it eventually would.

We also hit and fixed a difficulty-adjustment bug in the hours after the fork (inherited difficulty from the old algorithm didn't reset fast enough for yespower's cost) — caught it, patched it, tested on testnet, deployed the fix same day. Not claiming a flawless launch, just that we're actively maintaining this, not just shipping and disappearing.

Also worth mentioning: our whitepaper is now published on the site (civiclight.xyz/whitepaper.html), covering the full technical design — including a finalized (not yet implemented) direction for a Hybrid PoW+PoS model we're planning next, alongside consensus-level specs for the algorithm and tokenomics.

It is a good sign that the team openly admits civiclight v1 did not provide the level of ASIC resistance originally intended and is replacing it with v2 through a public hard fork.

At the same time, this is exactly the kind of project history that should remain independently verifiable. Miners joining later may want to confirm what v1 originally promised, when the weakness was acknowledged, what rules changed at the fork, whether the 1% developer allocation stayed the same, and how the planned transition to hybrid PoW + PoS evolved.

The current announcement is being updated with new releases, infrastructure changes and roadmap progress. That is convenient, but updating one post can also blur the distinction between what was stated before the fork and what was added afterward. GitHub tags preserve code, yet they do not necessarily preserve every official explanation, commitment or warning shown to users at that time.

Does CivicNet publish these announcements into an append-only, timestamped record where earlier statements remain visible and cannot be rewritten after a protocol change? I would like to review it, so could you point me to the relevant page or channel?

to your question directly: this is a sharp ask, and honestly, no — we don't currently have a dedicated append-only, timestamped record beyond what's implicitly available:

1. Individual reply posts in this thread (as opposed to the top post, which we do edit for the [UPDATES] index) are timestamped by Bitcointalk itself and remain in sequence unless edited — the forum flags edited posts, so unedited replies are a reasonably reliable trail. But that's a property of the forum, not something we built or guarantee.

2. Our Telegram channel/group has the same limitation — messages can technically be deleted or edited, so it's not a reliable append-only source either.

3. GitHub commit history preserves code changes with verifiable timestamps, but as you correctly point out, it doesn't capture the surrounding commitments, warnings, or explanations we gave alongside those changes.

So to directly answer: no, we don't have that system yet, and you're right to ask before taking anything we say — here, Telegram, or anywhere else — at face value.

What we can do, and will: publish a dated CHANGELOG/ANNOUNCEMENTS file directly in the GitHub repo, git-committed rather than edited in place. Git history is append-only in practice once pushed and pulled by others, and commit timestamps are independently verifiable — that gets much closer to what you're describing than a forum thread or chat channel does. We'll get that started and link it here once it's up.

Appreciate the scrutiny — this is exactly the kind of question a project should have a good answer to.

Thank you for the honest and detailed response. CivicNet is exactly the kind of serious project we would like to feature on Opstan.

Opstan is a decentralized social network where publications are stored permanently in a Proof-of-Work blockchain and cannot later be edited or deleted. We would like to create a CivicNet channel, describe the project, and publish its important news, technical updates, milestones and development history.

This would help more people discover CivicNet and give the project an additional layer of reputation. Anyone could review the original publications and see how the team handled upgrades, problems and roadmap commitments without relying only on editable websites or social networks.

It would also allow people from different parts of the world, including regions where access to certain platforms is limited, to follow information about CivicNet through the Opstan network.

Would you be comfortable with CivicNet appearing on Opstan through a dedicated channel containing information and news about the project?

Thank you for the offer. Since it was your question earlier in this thread that made us realize we don't have an append-only record system of our own, it's a good coincidence that you're now offering exactly that from Opstan.

Yes, we'd be comfortable with CivicNet appearing on Opstan through a dedicated channel. Feel free to set it up and let us know once it's live — happy to help keep it updated with genuine project news, technical updates, and milestones as they happen (fork completions, bug fixes, roadmap progress, etc.), the same way we've been doing here.

Appreciate you reaching out.

[fibonacciopstan]

Another update since we last spoke.

We just completed a hard fork to civiclight v2, a memory-hard algorithm — this directly addresses the ASIC-resistance concern raised early on in this thread, which was fair criticism at the time. Real network hashrate dropped from ~7 GH/s to ~44 kH/s immediately after activation, which we take as confirmation that most of the pre-fork hashrate wasn't coming from CPUs. The algorithm is now doing what we said it eventually would.

We also hit and fixed a difficulty-adjustment bug in the hours after the fork (inherited difficulty from the old algorithm didn't reset fast enough for yespower's cost) — caught it, patched it, tested on testnet, deployed the fix same day. Not claiming a flawless launch, just that we're actively maintaining this, not just shipping and disappearing.

Also worth mentioning: our whitepaper is now published on the site (civiclight.xyz/whitepaper.html), covering the full technical design — including a finalized (not yet implemented) direction for a Hybrid PoW+PoS model we're planning next, alongside consensus-level specs for the algorithm and tokenomics.

It is a good sign that the team openly admits civiclight v1 did not provide the level of ASIC resistance originally intended and is replacing it with v2 through a public hard fork.

At the same time, this is exactly the kind of project history that should remain independently verifiable. Miners joining later may want to confirm what v1 originally promised, when the weakness was acknowledged, what rules changed at the fork, whether the 1% developer allocation stayed the same, and how the planned transition to hybrid PoW + PoS evolved.

The current announcement is being updated with new releases, infrastructure changes and roadmap progress. That is convenient, but updating one post can also blur the distinction between what was stated before the fork and what was added afterward. GitHub tags preserve code, yet they do not necessarily preserve every official explanation, commitment or warning shown to users at that time.

Does CivicNet publish these announcements into an append-only, timestamped record where earlier statements remain visible and cannot be rewritten after a protocol change? I would like to review it, so could you point me to the relevant page or channel?

to your question directly: this is a sharp ask, and honestly, no — we don't currently have a dedicated append-only, timestamped record beyond what's implicitly available:

1. Individual reply posts in this thread (as opposed to the top post, which we do edit for the [UPDATES] index) are timestamped by Bitcointalk itself and remain in sequence unless edited — the forum flags edited posts, so unedited replies are a reasonably reliable trail. But that's a property of the forum, not something we built or guarantee.

2. Our Telegram channel/group has the same limitation — messages can technically be deleted or edited, so it's not a reliable append-only source either.

3. GitHub commit history preserves code changes with verifiable timestamps, but as you correctly point out, it doesn't capture the surrounding commitments, warnings, or explanations we gave alongside those changes.

So to directly answer: no, we don't have that system yet, and you're right to ask before taking anything we say — here, Telegram, or anywhere else — at face value.

What we can do, and will: publish a dated CHANGELOG/ANNOUNCEMENTS file directly in the GitHub repo, git-committed rather than edited in place. Git history is append-only in practice once pushed and pulled by others, and commit timestamps are independently verifiable — that gets much closer to what you're describing than a forum thread or chat channel does. We'll get that started and link it here once it's up.

Appreciate the scrutiny — this is exactly the kind of question a project should have a good answer to.

Thank you for the honest and detailed response. CivicNet is exactly the kind of serious project we would like to feature on Opstan.

Opstan is a decentralized social network where publications are stored permanently in a Proof-of-Work blockchain and cannot later be edited or deleted. We would like to create a CivicNet channel, describe the project, and publish its important news, technical updates, milestones and development history.

This would help more people discover CivicNet and give the project an additional layer of reputation. Anyone could review the original publications and see how the team handled upgrades, problems and roadmap commitments without relying only on editable websites or social networks.

It would also allow people from different parts of the world, including regions where access to certain platforms is limited, to follow information about CivicNet through the Opstan network.

Would you be comfortable with CivicNet appearing on Opstan through a dedicated channel containing information and news about the project?

Thank you for the offer. Since it was your question earlier in this thread that made us realize we don't have an append-only record system of our own, it's a good coincidence that you're now offering exactly that from Opstan.

Yes, we'd be comfortable with CivicNet appearing on Opstan through a dedicated channel. Feel free to set it up and let us know once it's live — happy to help keep it updated with genuine project news, technical updates, and milestones as they happen (fork completions, bug fixes, roadmap progress, etc.), the same way we've been doing here.

Appreciate you reaching out.

Thank you — that is great to hear.

You can create the official CivicNet channel yourself in just a few minutes:

1. Open the online version: https://opstan.org/
2. Create a new wallet and securely save the seed phrase offline. It is the only way to restore access, so never share it with anyone.
3. After entering Opstan, press the “+” button to create a channel.
4. Name it “CivicNet” and publish the first message, for example:

“Hello, we are the CivicNet team. This is our official permanent channel for project news, technical updates, milestones and roadmap progress.”

Once confirmed, the publication will be stored permanently in the Opstan Proof-of-Work blockchain and cannot be edited or deleted.

You can then publish fork completions, bug fixes, releases, security notices and other important updates. The channel and individual post links are easy to copy and can be added to your website, GitHub repository and Bitcointalk ANN thread.

This gives users around the world a simple way to follow CivicNet and verify its original project history, including in places where access to ordinary social platforms may be limited.

Website: https://opstan.org 
Online version: https://app.opstan.org

Please send me the CivicNet channel link once it is created, and I will check that everything is displayed correctly. If you run into any difficulty, write here and I will help.

[CivicLight]

🖥️ New: CivicNet EasyMiner — One-Click CPU Mining

We just released CivicNet EasyMiner, a simple GUI app for Windows that removes the command-line barrier to mining CIVIC entirely.

How it works:

• Download and run — no installation required
• Paste your CIVIC wallet address
• Pick how many CPU threads to use
• Click Start

That's the whole setup. No config files, no editing batch scripts, no manually connecting to a pool address.

Download	github.com/CivicLight/civicnet-easyminer
Source code	Fully open source, same repo as above

If you've been holding off on mining CIVIC because setting up a CPU miner felt like a hassle, this is built for exactly that. Feedback and bug reports welcome, as always.

[13y85t]

1. Open File Explorer, type this in the address bar: %APPDATA%\CivicNet
2. Create a file there called civicnet.conf (if it doesn't already exist)
3. Open it in Notepad and add this line:

Code:

addnode=103.180.165.99

4. Save, close, and restart civicnet-qt.exe

it doesn't sync, even with this peer

[CivicLight]

1. Open File Explorer, type this in the address bar: %APPDATA%\CivicNet
2. Create a file there called civicnet.conf (if it doesn't already exist)
3. Open it in Notepad and add this line:

Code:

addnode=103.180.165.99

4. Save, close, and restart civicnet-qt.exe

it doesn't sync, even with this peer

Thanks for the report. Before troubleshooting further — could you confirm you're running the latest QT wallet build (post civiclight v2 fork, activated July 23)?

If you're still on a pre-fork version, that would explain the sync failure: the old client validates blocks under the old algorithm and will reject/fail to process anything mined after the fork, regardless of how many peers or addnodes you configure. This isn't a networking issue in that case — it's a version mismatch.

Latest wallet: https://github.com/CivicLight/CivicNet/releases/tag/v2.0.0

If you've already confirmed you're on the latest version and it's still not syncing, let us know and we'll dig into the networking side (addnode config, port 9333 reachability, etc.).

[sdnz]

Something is very wrong here after hardfork.
The seed node alone is able to mine and grabs all blocks and other nodes cannot sync.
Along with 3.15M premine, dev keeps hogging all 

Code:

ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 
3d15db567c33bebfdd52b6e03baa05047b3a94e9e961c4a22a3fa72ecd081b9a,
 bad-diffbits, incorrect proof of work