s-coin

KO | EN

gitlite — search

#hacktoberfest #react #typescript #llm #golang #go #android #rust #deep-learning #macos #kubernetes #awesome-list #ios #mcp

(★ 24)

Sovereign Handcrafted Imitation Tender (SHIT) coin is a full cryptocurrency protocol/client/standard from-scratch. built for linux systems currently.

s-coin Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

"go make some money"

okay

c++20 and g++

built for learning computer networking. socket programming linux project with handmade net protocol and p2p client. resources I used:
- Beej's guide to network programming
- learncpp.com
- tcp/ip illustrated vol 1.

> this is a personal project made for fun to learn C++ and computer networking and to see how far I can get in a language/concept that is new to me, and is not for legitimate use as any tender/currency. if you decide to install and use this project, be aware that it was not designed by a security expert.

no LLMs were used for writing code (no surprise to anyone if you skim through it). only for asking questions / requesting generalised examples.

now, onto the serious things:

[Network Protocol](#network-protocol) • [VM](#virtual-machine)

# Network Protocol 
> as of 3rd of July, 26

the client is peer2peer and every node acts both as a client and a server. our "application" layer is:
- A TCP connection is established with a peer directly via hostname/port.
- a signal, expected message length, and sender address is sent in-advance. [[THE HEADER]]
- the listener will then ingest the incoming packet with knowledge of what it is and respond if need be.

there are obvious tradeoffs with this approach, such that there is a packet-esque network on TCP and that multiple signals are sent over the wire in a seemingly atomic transaction, however this is to ensure reliability. also, since stream connections are reliable, they will be read in-order and not waste memory ingesting bigger/smaller packets than expected.

the packet dispatch is mutually exclusive from the listener so every piece of traffic is mostly(?) not policed (this client was built to be as secure as possible, but im no expert). incoming connections will be checked for legitimacy based on their structure, and transactions (contracts) over the network are built to be public and transparent so they are not encrypted (subject to change based on if i feel it is needed or not).

the client's virtual machine is built to judge the legitimacy of contracts on the network (it doesnt really matter where it originates from - if it is signed by both parties and legitimate, all bets are off). contracts are checked for legitimacy over the entire network and illegitimate ones will be unilaterally rejected and are thus pointless to make. the client will only be built to send legitimate contracts only based on the state of the network.

## Packet Images
Peer Packet
<img width="1299" height="757" alt="peer_pkt" src="https://github.com/user-attachments/assets/3808e18b-853e-4def-90a3-25dc7b356600" />

Header Packet:
<img width="1297" height="858" alt="header_pkt" src="https://github.com/user-attachments/assets/1fe10148-fefc-441c-a0d9-23115bb1159b" />

the top 0-7 represents byte fields, assume row overflows means that there is contiguous data going across them. The padding sucks and isnt really clean which can hinder performance, this will be fixed,
but currently more conscious of moving forward (spent days refactoring the p2p system and need to draw the line somewhere)

# Virtual Machine
> as of 3rd of July, 26

Name inspired by my favourite lecturer and some subtle Chinese meaning.

## Why do we need an interpreter?

There are pros and cons of being decentralised. some pros are that you are not controlled by some central good/bad actor, but a very annoying con is that we lose all the benefits of having that middle man (freezing money,
putting up unbreakable wagers for bets, etc). We want a middleman, and since we ARE the middleman, we need to be able to write scripts that allow these cool features rather than just person A sends to person B. the fix? a simple interpreted language.

This is a simple stack machine ran from bytecode (I am brand-new to interpreter theory so its all freestyle) that is NOT turing complete since we do not want the network to suffer from halting problem issues and crash. at the moment a "contract" is just
two crypto-address fields and a "code" segment that can be written to. instructions are capped to uint8_t "instructions" where expressions are made from (the members in the transaction are 256b addresses and thus are
referenced as `ADDR_A` and `ADDR_B` instructions which are 8 bits - efficient!

the current intention is to implement unbreakable wagers (placing bets that cannot be taken back), freezing money based on an epoch clock, and of course, sending money. currently the signature/cryptography element isnt really done yet so that is currently omitted, but will also be a very important element of contracts.

this will be added to as the project continues, at the moment this is mostly a journal to log design decisions so I have something to come back to.

s-coin

s-coin Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

s-coin

s-coin Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README