Bitcoin Forum
April 05, 2026, 09:39:49 PM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [ANN][DSM] Deterministic State Machine — Sovereign, trustless, Offline, DeTfi  (Read 48 times)
cryptskii (OP)
Newbie
*
Offline Offline

Activity: 21
Merit: 3


View Profile
April 04, 2026, 01:44:34 PM
Last edit: Today at 04:06:27 PM by cryptskii
 #1

    ◆ DSM — DETERMINISTIC STATE MACHINE ◆
    Sovereign Bitcoin transactions without a global ledger, without intermediaries, without waiting.

    Website | GitHub | X / Updates | Irrefutable Labs



    What is DSM?

    DSM is a deterministic state machine: a cryptographic framework that lets you move your Bitcoin into a sovereign environment where you can transact instantly, offline, with no fees, no intermediaries, and no global ledger then move it back to Bitcoin whenever you choose.

    Bitcoin inside DSM is called dBTC. It is not a wrapped token. It is not custodied by a federation, a validator set, or trusted hardware. Moving your Bitcoin into DSM is a unilateral action secured by cryptography on the DSM side and proof-of-work on the Bitcoin side. The conservation law that evry satoshi of dBTC is backed 1:1 by confirmed Bitcoin in the vault grid is formally verified at three levels: TLC model checking, Lean 4 mechanized proof, and TLAPS proof scaffolding.

    Beta is live now on Bitcoin Signet. Anyone with an Android device and some Signet BTC from a faucet can try it today.



    What DSM lets you do with Bitcoin

    Transact instantly and offline.
    Two people in a room, on a plane, in a dead zone it doesn't matter. A valid dBTC transfer between two devices is final the moment the state advance happens. No confirmations. No later settlement step. No mesh network hoping to reconcile later. The bilateral state transition is the settlement.

    Pay no transaction fees inside DSM.
    There are no DSM side fees. You pay normal Bitcoin network fees when value enters or exits Bitcoin custody. Everything in between is feeless.

    Maintain sovereign custody at all times.
    Your Bitcoin is never handed to a bridge operator, a multisig committee, a federation, sequencer, or any form of trusted third party. The trust model inside DSM is reduced to cryptography. At the Bitcoin boundary, it reduces to Bitcoin proof-of-work. That's it.

    Scale without bottlenecks.
    Unrelated parties never serialize through a shared global state. Your transactions with Alice do not wait for, depend on, or even observe Bob's transactions with Carol. Throughput is additive: every new relationship is independent capacity.

    Operate post-quantum from day one.
    All DSM signatures use SPHINCS+. Key derivation uses BLAKE3 with domain separation. Key encapsulation uses ML-KEM (Kyber). There are no ECDSA keys to harvest now and crack later.



    How it works (short version)

    DSM has no blocks, no miners, no validators, no timestamps, and no global ordering layer.

    State is local to each bilateral relationship. If you and I transact, we each maintain a hash chain for our shared relationship. Every new state commits to its predecessor by hash adjacency that's where ordering comes from. Not from clocks. Not from block heights. From cryptographic structure.

    The Tripwire theorem provides fork exclusion: under standard cryptographic assumptions (EUF-CMA signatures, collision-resistant hashing), producing two accepted successors for the same parent state is negligible. This replaces consensus.

    The C-DBRW (Chaotic Dual-Binding Random Walk) mechanism binds state to both the device hardware and the execution environment. Cloning a device doesn't give you the ability to extend state you'd need the exact hardware and environment to derive the binding key. This is not a PUF in the traditional sense. Traditional PUFs fight environmental drift as a liability. C-DBRW is designed in the opposite direction: durable physical chaos is part of the security model, not a weakness to be compensated for.



    dBTC: Bitcoin inside DSM

    WhatDetail
    Backing1:1 with confirmed Bitcoin in the vault grid
    Conservationspendable + in-flight = grid backing (formally verified)
    EntryUnilateral deposit via Bitcoin HTLC; dBTC minted after d_min confirmations
    ExitCommit withdrawal → vault selection → Bitcoin spend → final burn
    Withdrawal resolutionCommitted withdrawals either settle or refund — no value is ever stranded
    Trust boundaryDSM-side: cryptography. Bitcoin-side: SPV inclusion + PoW header chain + confirmation depth
    Supply capCannot exceed 21M BTC by construction (BoundedSupply invariant, machine-checked)



    Architecture overview

    • Hash chains, not blocks. Each relationship is a forward only chain. Every state embeds the hash of its predecessor. Reversing or editing requires a hash collision.
    • Per-Device Sparse Merkle Trees. Each device maintains an SMT mapping its bilateral relationships to chain tips. Inclusion proofs are logarithmic.
    • Device Tree. Devices attach to a user's cryptographic genesis. Identity is not an account row it's a position in an authenticated tree.
    • Stitched receipts. Every state transition produces a receipt carrying inclusion proofs, Device Tree membership, and dual SPHINCS+ signatures. Invalid proofs mean the receipt is rejected no network call needed.
    • Storage nodes. Dumb by design. They replicate bytes and serve Merkle proofs. They never validate acceptance predicates. Censorship resistance follows from client-side verification and deterministic replica placement.
    • Deterministic Limbo Vaults (DLV). Trustless escrow, deferred payments, no oracle, no contract VM.



    Formal verification

    DSM's core safety properties are not just argued they are machine-checked:

    • TLA+ / TLC: Bounded model checking across 142,491 distinct states, 0 errors. 8 safety invariants and 3 liveness properties verified. Refinement mapping from concrete vault model to abstract conservation law verified.
    • Lean 4: Mechanized proofs of dBTC conservation, bounded supply, settled monotonicity, and transfer zero-sum unbounded, not just bounded.
    • TLAPS: Proof scaffolding for the safety/refinement core.
    • Trust reduction model: A separate TLA+ module makes the Bitcoin side trust boundary explicit and machine checkable: final burn requires observed Bitcoin spend + SPV inclusion + PoW validity + checkpoint-rooted header chain + confirmation depth ≥ d_min.



    What DSM is not

    • Not a blockchain. There is no chain of blocks, no block production, no miners.
    • Not a sidechain. There is no separate consensus mechanism.
    • Not a rollup. There is no sequencer, no data availability layer, no L1 posting off state diffs.
    • Not a payment channel network. There is no routing, no liquidity locks, no channel capacity limits, no watchtowers.
    • Not a federation or bridge with trusted operators. There is no multisig committee.




    Try it now (Signet beta)

      • Get an Android device.
      • Get some Signet BTC from a faucet.
      • Install the DSM beta from deterministicstatemachine.org.
      • Deposit Signet BTC. Transact with another user. Withdraw back to Bitcoin.



      Source and documentation




      Background

      DSM was built mostly under wraps. Solo dev, no marketing cycle, no community-building campaign, no public hype phase. Some of the early seed ideas were posted here, but DSM is where those ideas actually led.

      With the beta now open, I'm also open to hearing from technically strong contributors and from serious parties interested in supporting the project.

      Contact: info@irrefutablelabs.org



      A note on critiquing DSM

      If your critique assumes a global ledger, an intermediary, a witness set, delayed finality, timestamps, or waiting on unrelated parties you are critiquing a different system. DSM is clockless. Ordering comes from hash adjacency and relationship local state progression. Read the spec before assuming the usual architecture applies.


      DSM is experimental software. This is not financial advice. Do your own research.[/list][/list]
      cryptskii (OP)
      Newbie
      *
      Offline Offline

      Activity: 21
      Merit: 3


      View Profile
      Today at 03:47:49 PM
       #2

      On why DSM has its own token instead of just using dBTC for everything.

      DSM is arguably more decentralized than Bitcoin. Bitcoin still depends on global consensus, miners, and a shared ordering layer. DSM doesn't. Everything resolves through math, not through waiting for a network of unrelated parties to agree. If you denominate DSM's internal economics in dBTC, you're taking a system that runs on deterministic verification and making it depend on consensus again. That defeats the point.

      Sovereignty means not coupling to someone elses monetary policy. If DSM infrastructure runs on dBTC, then Bitcoin's fee market, halving schedule, and price volatility dictate your storage economics, your spend gate cost, and your network entry. Thats a dependency. DSM is designed to have no dependencies on unrelated systems. Denominating in your own unit is the same principle applied to economics that we already applied to state. Keep unrelated concerns seperate.

      There's also the blast radius argument. Bitcoin was not built post quantum. It will have to retrofit. If that retrofit goes wrong, or goes late, or introduces new attack surface during migration, and your entire infrastructure layer is denominated in BTC, then a Bitcoin layer failure cascades directly into DSM's ability to function. DSM was built post quantum from genesis. SPHINCS+, BLAKE3, ML-KEM. None of that is patched on top. Keeping the economic layer on a separate token means a quantum failure in Bitcoin's signature scheme doesn't take down DSM's internal operations. The BTC Tap is an interface, not a dependency. If Bitcoin has a bad day, your dBTC Tap might pause, but DSM's storage nodes still get paid, spend gates still function, and the internal economy keeps running.

      Nobody forced the BTC Tap to exist either. It's there because it's useful. If you want feeless offline Bitcoin transactions, it's there. If you don't, DSM still works without it.
      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!