Interesting concept.
Adderss-less transfers using 1 time cryptographic commitments while keeping a fully auditable ledger on POW is theoretically a strong direction if implemented correctly. But how this differs from existing CT / Mimblewimble-style systems ? how inflation bugs and double-spends proofs will be enforced ? how ownership is recognized by the wallet without scanning the entire chain ?
Have a good day

Thank you for the insightful feedback. You’ve touched on the core technical trade-offs of the No ID protocol. Here is how we address those points
Philosophy: Visible Ledger, Invisible PeopleNo ID follows a unique design path in the privacy space. While systems like Mimblewimble or Confidential Transactions (CT) focus on concealing transaction amounts, they introduce the risk of "hidden inflation", if the underlying cryptographic math is ever compromised, an attacker could mint infinite supply undetected. No ID keeps amounts transparent to ensure the 21M supply remains 100% auditable by anyone at all times. Instead, we focus strictly on Identity-Decoupling via Stealth-UTXOs. The network sees the value moving, but can never link it to a persistent identity or a static address.
The Core Mechanism: Stealth Commitments & SaltsIn a transparent blockchain like Bitcoin, every transaction links a sender's address to a recipient's. In No ID, Public Keys are never recorded on the ledger.
The Formula:(Commitment = SHA256(Recipient_PublicKey + Random_Salt)
The Impact: Because the salt is randomized for every output, every commitment on the ledger appears as a unique, unrelated string. To an outside observer, the ledger appears as a stream of random data. Only the holder of the private key can "solve" the hash to claim the funds.
Safety & AuditabilityInflation Protection: Because amounts are plaintext, every node verifies that the sum of the outputs equals the value of the spent inputs. This ensures no hidden inflation can occur outside of the hardcoded coinbase rewards.
Double-Spend Prevention: This is enforced by the Node maintaining a global set of 'spent nullifiers' (the specific commitments used as inputs). Any block containing a transaction that tries to spend a commitment already marked as spent is rejected by consensus rules.
The Transaction Flow (Step-by-Step)Step A: Discovery (Stealth Scanning)The wallet software identifies assets by iterating through the ledger and computing a local hash using the user's Public Key and the salt attached to each on-chain output. If
SHA256(User_PubKey + salt) = On_Chain_Commitment, the wallet recognizes the funds.
Note: In a production environment, this is optimized using Compact Block Filters (BIP-157/158) to ensure instant scanning without downloading the full chain.
Step B: Creating a TransactionUTXO Aggregation: The wallet identifies a list of unspent commitments that, when combined, meet the required balance.
Stealth Generation: The wallet generates unique random salts for the recipient and a new "Change" output for the sender.
Commitment Calculation: It derives the new on-chain commitments using the destination Public Key and the new salts.
Step C: Signing & VerificationThe wallet signs the transaction data using the user's Private Key. This provides mathematical proof of ownership over the input commitments without ever revealing the underlying identity. The signed transaction is then broadcast to the network mempool.
Step D: Mining (Finality via PoW)Network miners collect transactions and perform Proof of Work. Once a block is found, the transaction is committed, and all used "Input Commitments" are globally marked as spent.
https://imgur.com/a/HjD9Tbm