[ANN] Sharecoin [SHC] - GPU Mining that doubles as Verifiable Randomness

[lightbit]

Hey — I run Chainquiry, a searchable crypto project directory, and I’d like to invite your team to submit a free listing.  

It includes your official links, network, launch date and project information after editorial review:

https://chainquiry.com/list-your-project/

Thank you, I have submitted a request.

Sharecoin (SHC) is now listed on Chainquiry

Sharecoin has been added to the Chainquiry cryptocurrency project directory.

View the Sharecoin profile:
https://chainquiry.com/projects/sharecoin/

If the Sharecoin team or community notices any missing or outdated information, please contact Chainquiry so the profile can be reviewed and updated.

Chainquiry helps users discover, research and verify cryptocurrency projects. A directory listing does not constitute an endorsement.

[Cryptomake]

Getting the following error with kawpowminer:

i 13:04:33 <unknown> Worker xxx.xxx not authorized : code:-32603 message:internal server error
i 13:04:33 <unknown> Disconnected from sharecoin.duckdns.org

[Share_Coin]

Getting the following error with kawpowminer:

i 13:04:33 <unknown> Worker xxx.xxx not authorized : code:-32603 message:internal server error
i 13:04:33 <unknown> Disconnected from sharecoin.duckdns.org

Can you post me your command line please?

[Cryptomake]

kawpowminer 1.2.4+commit.0707bca0
Build: windows/release/msvc

No OpenCL platforms found
 i 13:18:40 main      Configured pool sharecoin.duckdns.org:10000
 i 13:18:40 <unknown> Selected pool sharecoin.duckdns.org:10000
 i 13:18:40 <unknown> Stratum mode : Stratum
 i 13:18:40 <unknown> Established connection to sharecoin.duckdns.org [86.133.190.141:10000]
 i 13:18:40 <unknown> Spinning up miners...
cu 13:18:40 cuda-0    Using Pci Id : 05:00.0 NVIDIA GeForce RTX 4070 (Compute 8.9) Memory : 11.99 GB
 i 13:18:40 <unknown> Extranonce set to 0020
 i 13:18:40 <unknown> Worker xxx.rig1 not authorized : code:-32603 message:internal server error
 i 13:18:40 <unknown> Disconnected from sharecoin.duckdns.org [86.133.190.141:10000]
 i 13:18:40 <unknown> No connection. Suspend mining ...
 i 13:18:40 <unknown> No more connections to try. Exiting...
 i 13:18:40 <unknown> Shutting down miners...
 i 13:18:40 main      Got interrupt ...
 i 13:18:40 main      Terminated!

[Share_Coin]

kawpowminer 1.2.4+commit.0707bca0
Build: windows/release/msvc

No OpenCL platforms found
 i 13:18:40 main      Configured pool sharecoin.duckdns.org:10000
 i 13:18:40 <unknown> Selected pool sharecoin.duckdns.org:10000
 i 13:18:40 <unknown> Stratum mode : Stratum
 i 13:18:40 <unknown> Established connection to sharecoin.duckdns.org [86.133.190.141:10000]
 i 13:18:40 <unknown> Spinning up miners...
cu 13:18:40 cuda-0    Using Pci Id : 05:00.0 NVIDIA GeForce RTX 4070 (Compute 8.9) Memory : 11.99 GB
 i 13:18:40 <unknown> Extranonce set to 0020
 i 13:18:40 <unknown> Worker xxx.rig1 not authorized : code:-32603 message:internal server error
 i 13:18:40 <unknown> Disconnected from sharecoin.duckdns.org [86.133.190.141:10000]
 i 13:18:40 <unknown> No connection. Suspend mining ...
 i 13:18:40 <unknown> No more connections to try. Exiting...
 i 13:18:40 <unknown> Shutting down miners...
 i 13:18:40 main      Got interrupt ...
 i 13:18:40 main      Terminated!

Ok I have checked the node logs, I will apply a fix shortly, it's not a big problem. I will reply here once done.


Edit:   Fix applied, please retry.I have put up a simple use case demo for the randomness selector.

This is what a raffle site could use to draw a truly random and trustworthy raffle system:

https://sharecoin-pi.tail0b8084.ts.net/raffle/

Moving beyond simple web raffles, a trustless public randomness beacon driven by physical GPU proof-of-work can solve complex, systemic real-world problems. Most digital architectures struggle with coordination when nobody is trusted, and using standard cryptographic functions can result in centralisation or vulnerabilities.

Four elaborate, production-grade applications can be built on top of the Sharecoin infrastructure:

1. ⏳ Time-Locked Cryptographic Vaults (Decentralised Dead-Man's Switches)
Encrypting data so it cannot be decrypted until a specific point in the future usually requires a trusted third party to hold the key. A randomness beacon can act as a decentralized clock that releases keys.
The Architecture: A user encrypts a sensitive payload (such as a legal will, whistleblower data, or emergency backup keys) using an algorithm where the decryption key is mathematically tied to the future outputs of getrandombeacon.
The Sharecoin Twist: Because your beacon uses a Linearly Weighted Moving Average (LWMA) to keep block times steady, the arrival of future blocks acts as an unalterable time anchor. An agent script can be set up to listen to your RPC endpoint and programmatically reconstruct the necessary decryption keys block-by-block, ensuring information is unlocked exactly when intended without human intervention.

2. 🏛️ Public Sortition for Algorithmic Governance & Auditing
Democracy and corporate compliance often suffer from corruption when humans choose who handles audits, jury duty, or regulatory reviews. Sortition uses pure random selection to assign these responsibilities.
The Architecture: Government agencies, DAOs, or corporate compliance departments register lists of qualified inspectors or jurors.
The Sharecoin Twist: When an inspection or judicial assignment is triggered, the selection algorithm pulls from your beacon. Because the GPU mix_hash cannot be predicted even seconds before the block is mined, it is mathematically impossible for an insider to bribe the system or manipulate the seed to ensure a specific auditor reviews a specific case. This provides a transparent, auditable trail for public trust.

3. 🛡️ Immunisation Against Backdoored PRNGs in Security Networks
Many critical enterprise firewalls, IoT meshes, and cryptographic servers rely on internal Pseudo-Random Number Generators (PRNGs). If a manufacturer builds a hidden flaw or backdoor into those generators, an attacker can predict their encryption keys.
The Architecture: An enterprise security gateway runs a background daemon that periodically queries your Sharecoin network data.
The Sharecoin Twist: The gateway feeds your getrandombeacon output directly into its local entropy pool, mixing it with its hardware random number generators. By injecting independent, external randomness from physical GPU mining work, the system eliminates local hardware bias or intentional manufacturer backdoors, protecting the network from prediction attacks.

4. 📊 Un-Riggable Multi-Provider Oracles (DeFi & Supply Chain)
Decentralised finance (DeFi) platforms and smart supply chains rely on "oracles" to bring real-world data (such as currency prices or weather conditions) onto the blockchain. However, if an attacker knows exactly which oracle node will be queried next, they can target it with a DDoS attack or compromise its data feed.
The Architecture: A network utilizes a pool of 500 independent data-providing nodes.
The Sharecoin Twist: For every incoming data request, the network calls your beacon to dynamically shuffle and select a random subset of 5 nodes to provide the data. Because the selection changes with every block and cannot be anticipated, attackers cannot predict which nodes to target, securing the data pipeline against manipulation.

[Share_Coin]

I have put up a simulation roulette game, to show how you can run a trusted gambling service:

https://sharecoin-pi.tail0b8084.ts.net/roulette

[fibonacciopstan]

Using confirmed block data as a public randomness beacon is a useful idea because anyone should be able to reproduce the result.

Will the same level of verifiability apply to changes in the beacon rules, confirmation window and intended applications? A later documentation update could otherwise replace the assumptions under which earlier users relied on it.

Where can I find the permanent history of Sharecoin’s randomness parameters and official protocol decisions?

[Share_Coin]

Using confirmed block data as a public randomness beacon is a useful idea because anyone should be able to reproduce the result.

Will the same level of verifiability apply to changes in the beacon rules, confirmation window and intended applications? A later documentation update could otherwise replace the assumptions under which earlier users relied on it.

Where can I find the permanent history of Sharecoin’s randomness parameters and official protocol decisions?

The beacon's underlying data (the block headers and mix hashes it's built from) was already permanently verifiable, that part doesn't depend on trusting me. But you're correct that the rules around it, window size, how many blocks to wait, what it's recommended for, weren't pinned down anywhere solid. They just lived in docs and demo code I could edit anytime, with no real trail if they changed.

That's now fixed with a dedicated spec file: docs/BEACON-SPEC.md in the repo. It documents exactly what the protocol actually enforces (the RPC won't return a beacon value until every block in the requested window is confirmed, and its own built-in default window is 100 blocks) versus what's just this project's own convention (an 8-block reference window used across the demos, with lead times that vary by use case, listed in the spec itself).

Going forward, any change to those numbers gets published as a new version (v2, v3, etc.), never a silent edit to an old one. Each version is:

- Committed to the repo's git history
- Tagged as its own release, so there's a permanent, unambiguous reference for exactly what a given version said
- Timestamped with OpenTimestamps, which anchors a hash of the file into the actual Bitcoin blockchain, not Sharecoin, real Bitcoin, which I don't control and can't rewrite. Anyone can independently verify the file existed unchanged at that point in time, without trusting me or GitHub at all.

To answer where to find it directly: the current version is tagged here: https://github.com/TVHeroes/sharecoin/releases/tag/beacon-spec-v1, with the spec and its timestamp proof both in that release.

[fibonacciopstan]

Using confirmed block data as a public randomness beacon is a useful idea because anyone should be able to reproduce the result.

Will the same level of verifiability apply to changes in the beacon rules, confirmation window and intended applications? A later documentation update could otherwise replace the assumptions under which earlier users relied on it.

Where can I find the permanent history of Sharecoin’s randomness parameters and official protocol decisions?

The beacon's underlying data (the block headers and mix hashes it's built from) was already permanently verifiable, that part doesn't depend on trusting me. But you're correct that the rules around it, window size, how many blocks to wait, what it's recommended for, weren't pinned down anywhere solid. They just lived in docs and demo code I could edit anytime, with no real trail if they changed.

That's now fixed with a dedicated spec file: docs/BEACON-SPEC.md in the repo. It documents exactly what the protocol actually enforces (the RPC won't return a beacon value until every block in the requested window is confirmed, and its own built-in default window is 100 blocks) versus what's just this project's own convention (an 8-block reference window used across the demos, with lead times that vary by use case, listed in the spec itself).

Going forward, any change to those numbers gets published as a new version (v2, v3, etc.), never a silent edit to an old one. Each version is:

- Committed to the repo's git history
- Tagged as its own release, so there's a permanent, unambiguous reference for exactly what a given version said
- Timestamped with OpenTimestamps, which anchors a hash of the file into the actual Bitcoin blockchain, not Sharecoin, real Bitcoin, which I don't control and can't rewrite. Anyone can independently verify the file existed unchanged at that point in time, without trusting me or GitHub at all.

To answer where to find it directly: the current version is tagged here: https://github.com/TVHeroes/sharecoin/releases/tag/beacon-spec-v1, with the spec and its timestamp proof both in that release.

That is a strong solution. Git tags, versioned releases and OpenTimestamps anchored to Bitcoin give the beacon specification a much clearer and independently verifiable history.

The remaining opportunity is making those changes easy for ordinary users to follow, not only developers checking GitHub releases. Sharecoin could publish every new specification version, rule change, security notice and important project update in an official Opstan channel.

Each message would be stored permanently in the Opstan Proof-of-Work blockchain and could not later be edited or deleted. This would give Sharecoin a simple public timeline showing exactly what changed, when it changed and why.

It would also make the project less dependent on GitHub or any single social network. Users from different countries, including places where some platforms are restricted, could still follow Sharecoin’s announcements through Opstan-compatible interfaces. The channel link could be added to the website, repository and ANN thread.

Using it is simple: publish directly through the online version without downloading the blockchain.

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

Your technical verification process is already strong. Adding a permanent public communication channel would make that transparency easier to see and could attract more users who value serious, verifiable development.
I think this will help develop your project

[Share_Coin]

That is a strong solution. Git tags, versioned releases and OpenTimestamps anchored to Bitcoin give the beacon specification a much clearer and independently verifiable history.

The remaining opportunity is making those changes easy for ordinary users to follow, not only developers checking GitHub releases. Sharecoin could publish every new specification version, rule change, security notice and important project update in an official Opstan channel.

Each message would be stored permanently in the Opstan Proof-of-Work blockchain and could not later be edited or deleted. This would give Sharecoin a simple public timeline showing exactly what changed, when it changed and why.

It would also make the project less dependent on GitHub or any single social network. Users from different countries, including places where some platforms are restricted, could still follow Sharecoin’s announcements through Opstan-compatible interfaces. The channel link could be added to the website, repository and ANN thread.

Using it is simple: publish directly through the online version without downloading the blockchain.

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

Your technical verification process is already strong. Adding a permanent public communication channel would make that transparency easier to see and could attract more users who value serious, verifiable development.
I think this will help develop your project

Thanks for your input.
Whilst I agree GitHub is a single point of failure for this, it's fine as a 'for now' solution.
I will however look into your recommendation and consider implementing it, alongside other options, so that the information can not only be retrieved, but cross referenced.

[fibonacciopstan]

That is a strong solution. Git tags, versioned releases and OpenTimestamps anchored to Bitcoin give the beacon specification a much clearer and independently verifiable history.

The remaining opportunity is making those changes easy for ordinary users to follow, not only developers checking GitHub releases. Sharecoin could publish every new specification version, rule change, security notice and important project update in an official Opstan channel.

Each message would be stored permanently in the Opstan Proof-of-Work blockchain and could not later be edited or deleted. This would give Sharecoin a simple public timeline showing exactly what changed, when it changed and why.

It would also make the project less dependent on GitHub or any single social network. Users from different countries, including places where some platforms are restricted, could still follow Sharecoin’s announcements through Opstan-compatible interfaces. The channel link could be added to the website, repository and ANN thread.

Using it is simple: publish directly through the online version without downloading the blockchain.

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

Your technical verification process is already strong. Adding a permanent public communication channel would make that transparency easier to see and could attract more users who value serious, verifiable development.
I think this will help develop your project

Thanks for your input.
Whilst I agree GitHub is a single point of failure for this, it's fine as a 'for now' solution.
I will however look into your recommendation and consider implementing it, alongside other options, so that the information can not only be retrieved, but cross referenced.

Of course, and thank you for considering it.

It is very simple: you create an official Sharecoin channel and publish updates there just like on a social network — for example, “Hello, we are the Sharecoin team, and today we completed this milestone.”

That message is then permanently recorded in the blockchain and cannot be edited or deleted. I believe this could help strengthen trust in Sharecoin and support the project’s growth.

Thank you for the reply.

[Share_Coin]

Update:

I have created a proof of concept for gaming sites, with a simple roulette game.
No money is earned/won/lost, this is just a simulation that runs on the actual live blockchain:

https://sharecoin-pi.tail0b8084.ts.net/roulette