Bitcoin Forum
March 27, 2026, 06:06:49 PM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Selfcoin - finalized-state UTXO system with deterministic committee finality  (Read 58 times)
reikagi (OP)
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
March 26, 2026, 10:52:21 AM
 #1

Selfcoin is an experimental cryptocurrency designed around explicit finality rather than longest-chain selection.

Blocks are not considered valid until finalized by quorum. Once finalized, they do not revert.

Core properties:

-- UTXO-based ledger
-- deterministic committee selection from finalized state
-- quorum-based finality (≥ 2/3)
-- finalized-tip-only progression
-- no mempool-driven fork choice

Committee selection:

-- operators are derived from finalized state
-- weight uses sqrt(bond) scaling
-- a bounded proof-of-work ticket acts as a secondary modifier
-- work is limited per operator and does not accumulate globally

Proof-of-work is not used for chain security. It only affects committee ordering.

Finality:

-- blocks carry quorum certificates
-- finality is explicit and persistent
-- nodes serve finalized data only

This allows:

-- deterministic replay from finalized checkpoints
-- simple client behavior (no reorg handling)
-- consistent state across nodes

The implementation follows a single consensus path and avoids multiple runtime models.

Reference implementation (selfcoin-core):
https://github.com/reikagitakashi-bot/selfcoin-core

The project explores whether a system can be simplified by removing probabilistic settlement and relying only on finalized state.
reikagi (OP)
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
March 26, 2026, 01:30:03 PM
 #2

One detail to clarify:
the PoW component is bounded per operator and does not accumulate globally. It is only used as a secondary modifier in committee selection.
reikagi (OP)
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
March 26, 2026, 01:58:19 PM
 #3

One detail to clarify:
the PoW component is bounded per operator and does not accumulate globally. It is only used as a secondary modifier in committee selection.

Second clarification on the design:

Selfcoin does not attempt to compete on longest-chain security. There is no fork choice rule based on accumulated work or chain length.

The system advances only through finalized progression.
A block is accepted only after quorum finality (≥ 2/3), and nodes do not operate on competing tips or speculative states.

This removes probabilistic settlement entirely.
A transaction is either finalized or it is not. Once visible, it does not revert.

The design shifts complexity:

-- away from fork choice, mempool races, and reorg handling
-- toward validator assumptions and quorum honesty

The tradeoff is explicit:

-- no probabilistic confirmations
-- no rollback logic at the application level
deterministic validation from finalized checkpoints

in exchange for reliance on ≥ 2/3 honest participation in the active committee.

Committee selection is deterministic from finalized state at epoch boundaries. Operators are derived from finalized membership and weighted by bonded stake using sqrt scaling.

A bounded proof-of-work component is included, but its role is limited.
-- each operator performs a small, fixed search per epoch
-- only the best ticket per operator is considered
-- tickets act as a secondary modifier in deterministic ranking

Proof-of-work does not determine chain security, does not accumulate across the network, and does not influence finality.

Its purpose is to introduce a small, bounded source of unpredictability inside committee selection without creating an open-ended resource race.

Finality remains entirely quorum-based.

The implementation (selfcoin-core) reflects this model by:

-- processing only finalized blocks
-- deriving state strictly from finalized history
-- exposing finalized data only through its interfaces

The goal is to reduce ambiguity in both validation and settlement, even if that requires stronger assumptions about validator behavior.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!