Sigbash

Moving Bitcoin Signing from HTTP to HTTPS

Current Signing Options

✗ Clear Signing

  • Server sees everything: transaction details, amounts, destinations, policy conditions
  • Total privacy flaw - custodian has complete visibility into user's financial activity

✗ Blind Signing

  • Server sees nothing - signs without validation
  • Billions of dollars lost to catastrophic hacks and social engineering attacks

Current Best Option: Predicate Blind Signing

~ Fuchsbauer-Wolf Protocol (2022)

  • Server validates policy without seeing full transaction
  • ✗ Predicates still leaks privacy (transaction structure)
  • ✗ Doesn't account for state, makes most predicates useless on their own
  • ✗ Unacceptable performance for all but the simplest predicates
  • Paper here: eprint.iacr.org/2022/1676.pdf

Sigbash v1: The First Attempt

"Blinded Xpubs" + GPG Attestation Approach

  • Off-chain attestation model: GPG-signed predicates for spending conditions
  • Blinded xpubs: stop server from seeing users balance + entire transaction historyby giving them their own 'blast-radius' key
  • "Fake it till you make it" predicate blind signing - build the UX first and gather real world feedback from users before trying to build the hard parts

What We Got Right

  • ✓ Predicate signing policy concept validated
  • ✓ Give the user an xpub, accept a PSBT for signing, all in browser - meet the user where they are, let them use their own wallet + signing flow
  • ✓ "Sign after given date" policy by far most popular - users know Bitcoin supports timelocks, no one wants to switch to a new wallet

What We Got Wrong: Technical Limitations

Fundamental Design Flaws

  • ✗ Privacy degrades as soon as signing request is submitted
  • ✗ Most predicates were external conditions, e.g. asset prices (focused on traders)
    • - lots of feature requests for conditions, little real world usage
  • ✗ ECDSA only (Taproot and MuSig2 offer the potential for greatly improved privacy)

What We Got Wrong

Complete Server Visibility At Signing Time

  • ✗ Server sees predicate, transaction, and signing key (complete visibility)
  • ✗ GPG attestations never checked → security theater

Privacy Gaps Still Remain

  • We fixed the biggest problem with multisignature privacy (xpub leaks balance + history)
    • Bad actors (ChainAnalysis / Lazarus Group) can still track/denanonymize users
    • Threat model was academic instead of real-world

    What We've Built with v2

    • Entire stack transitioned to WebAssembly - pushing as much logic away from the server as possible
    • Client-side MuSig2 generation - server never sees the signing key
    • New data structure + DSL for describing complex signing policies and reducing to a single privacy-preserving hash
    • Server only ever sees a single policy hash and zero knowledge proofs showing a transaction matches the predefined policy - total end to end privacy

    Inside a POET: Policy Operand Expression Trees

    POET data structure animation

    Complex signing policies encoded as a single 32-byte hash — all logic, zero leakage

    How It Works

    At Key Registration

    • Client defines policy, we encode it into a policy operand expression tree
    • Client requests key from server, derives child key, aggregates with own key
    • Server only sees: POET 32 byte hash + hash of child key (not the signing key)

    At Signing Time

    • Client submits transaction
    • WebAssembly generates proofs:
      • Transaction matches policy clause
      • Merkle proof clause is in policy tree
      • Schnorr proof of knowledge binding proofs to transaction
    • If proofs check out - server provides signature share, client combines signatures and signs transaction

    The Future of Bitcoin Signing

    • ✓ Arbitrarily complex signing policies with zero-knowledge proofs - POETs support all boolean logic operators as well as all transaction properties
    • ✓ Outstanding performance, near infinite flexibility, demonstrably superior privacy
    • ✓ Keep your existing wallet and signing flows
    • ✓ No software to download - works entirely in browser
    • ✓ Perfect privacy, end to end

    The HTTPS Moment for Bitcoin Signing

    • 1992: HTTP invented
    • 1995: HTTPS invented - secure HTTP making eavesdropping impossible
    • 1995-2015: HTTPS climbs a decades long wall of worry from "nobody really needs this" to "absolutely essential for every website"

    Oblivious Signing is HTTPS for Bitcoin

    We now know how to sign transactions withoutl leaking any privacy. Climbing the wall of worry starts now.

    Be early to the inevitable future.

    Let's talk.