Cash-Like Privacy on BCH - Phase 2 Beaconless Bind

Close observed

2026-01-02

Earlier archive date

2025-11-09 · superseded by the confirmed close transaction.

Amount basis

Pledges reported by the source; this is not a current contract balance.

Earlier archive classification

success · superseded by the latest source evidence

FundMe listing state

stopped

Creator completion statement

Not marked complete.

Delivery evidence

Not independently established

This is a continuation of Phase 1 work hereWhy Private “Cash-Like” Payments MatterIn the real world, paying with cash doesn’t broadcast who paid whom or how much. Online, most payments do. Phase-2 aims to bring cash-like privacy to Bitcoin Cash—so people can transact without leaving an obvious trail, while every rule still verifies on-chain.What’s a “note,” in plain English? A note is a private claim on value. On-chain, it looks like an ordinary output; off-chain, only the intended recipient gets the information needed to spend it. No public beacons, no global scanning.Objective (Phase-2)Deliver a spend flow that provides:Shielded identities at both funding and spend.Shielded amounts (no plaintext values on-chain).Beaconless transactions (no OP_RETURN scanning; proofs bind to the actual outputs).On-chain verifiability (no oracles; standard network validation).Tight size budget (target ≤ ~100 KB for one-off spends).Standard-looking deposits/spends with private, end-to-end note delivery.Flexibility ClauseI’ll stay technology-agnostic (hash-centric, PQ-friendly preferred). If research reveals a better approach, I’ll adopt it and publish a short design note, an updated threat model, and a byte/CPU budget comparison.This Campaign Funds M2 — Beaconless Output BindingObjective (what this solves):Prove a transaction is paying the actual outputs—without revealing data in a public beacon like OP_RETURN. This keeps transactions standard-looking.What I’ll build:A contract routine that recomputes a compact fingerprint of the transaction’s own outputs (values, token fields if present, and a hash of each locking script).The prover supplies the same fingerprint off-chain.The contract compares them: match → spend succeeds; mismatch → fail.Why this matters for cash-like privacy:Removes visible metadata “tells”.Enables private note delivery off-chain while still binding proofs to the real on-chain outputs.Acceptance (done when):Fingerprint parity passes end-to-end tests.A tiny reference tool can recompute the fingerprint for any TX locally.Size budget respected (leaves room for later ZK).Overall Project Plan (Phase-2)M2 — Beaconless Output Binding (this campaign) Contract checks the real outputs (no public beacon) by matching on-chain and off-chain fingerprints.M3 — Shielded Note State (no global scanning) Minimal state UTXO + ordinary-looking note UTXOs; enforce membership & no-double-spend on-chain, within byte budget.M4 — Succinct Proof Integration (tech-agnostic) Add an on-chain-verifiable, succinct proof that attests ownership, correct outputs, and conservation—without revealing identities/amounts—under a strict size budget.M5 — Privacy Polish & Wallet UX Reduce surfaced key material, provide wallet hygiene guidance, and ship a public test harness with runnable examples.(Each future milestone will have its own FundMe page. Overflow from a campaign rolls forward into the next milestone or audits.)Claim PolicyBackers control their pledge until I claim. I’ll claim when I’m ready to start M2 so you retain full control before work begins.Use of FundsContract implementation & tests for output fingerprint parityMinimal reference tool to recompute fingerprintsHardening for size/CPU budget discipline and future ZK integrationOverflow goes to the next milestone or independent review.Risks & MitigationsSize/VM limits: I design to a strict budget; if a technique risks the budget, I switch per the Flexibility Clause.Integration risk: I provide a tiny local tool + runnable examples to make verification easy.R&D uncertainty: I favor well-understood, hash-centric approaches and publish trade-offs.Backer Guidance (optional but helpful)For privacy, consider using CashFusion before pledging, avoid reusing fused UTXOs until the campaign is claimed, and consider splitting larger pledges.About Me & Prior WorkNostr Multi-Chain Tipping NIP — secp256k1 chains tipping on Nostrhttps://github.com/bastiancarmy/nostr-multi-chain-tipping-nipNostr Key Demo — derive BCH keys from nsec/npub identitieshttps://github.com/bastiancarmy/nostr-key-demoBitcoin Cash Node Bootstrap — BCH + Fulcrum via Ansiblehttps://github.com/bastiancarmy/bitcoin-cash-node-bootstrapnos2bch — Chrome extension wallet funding + Nostr npub tippinghttps://github.com/bastiancarmy/nos2bchTelegram: @bastiancarmichaelGitHub: https://github.com/bastiancarmy