28. März 2026

SplitSig: Non-Custodial Schlüsselableitung aus Lightning Wallets

Jede Web-Anwendung, die mit Bitcoin arbeitet, steht vor demselben Dilemma: Der Nutzer braucht einen Signaturschlüssel — aber wo liegt dieser? Generiert der Server ihn, ist der Dienst custodial. Generiert der Browser ihn, verliert der Nutzer ihn beim Löschen des Caches. Leitet man ihn aus der Wallet ab, sieht der Server das Ableitungsmaterial.

Wir haben ein Verfahren entwickelt, das dieses Problem löst. Ich nenne es SplitSig.

Die Formel

privkey = SHA256( ecdsa_signatur + nonce )
                 ────────────────   ─────
                 Server sieht das   nur im Browser

Zwei Teile. Der Server hat eines. Der Browser hat das andere. Keines allein ergibt den privaten Schlüssel.

So funktioniert es

Wenn sich ein Nutzer mit seiner Lightning Wallet über LNURL-auth authentifiziert, signiert die Wallet eine Challenge mit ECDSA. Diese Signatur geht an den Server — so funktioniert LNURL-auth, das ist dem Protokoll inhärent.

Die meisten signaturbasierten Schlüsselsysteme (zkSync, Umbra, StarkWare) würden diese Signatur einfach hashen und als privaten Schlüssel verwenden. Aber der Server hat die Signatur gesehen — er könnte denselben Hash berechnen und hätte den Schlüssel. Das ist custodial.

SplitSig fügt eine zweite Zutat hinzu: einen zufälligen 256-Bit-Nonce, der im Browser über crypto.getRandomValues() erzeugt wird. Der Nonce verlässt den Browser nie. Der Server sieht ihn nie.

Wiederherstellung

Der Nonce wird in einem Recovery Kit gespeichert, das der Nutzer herunterlädt. Um den Schlüssel auf einem neuen Gerät abzuleiten:

• Recovery Kit laden (enthält den Nonce)
• LNURL-auth QR-Code mit derselben Wallet scannen
• Gleiche Wallet = gleicher Seed = gleiche Signatur (RFC 6979, deterministisch)
• SHA256(gleiche Signatur + gleicher Nonce) = gleicher privater Schlüssel

Der LNURL-auth Linking Key wird aus dem BIP-32-Seed der Wallet am Pfad m/138'/... abgeleitet (LUD-04). Er ist stabil über App-Updates, Betriebssystem-Upgrades und Gerätewechsel hinweg. Solange der Wallet-Seed derselbe ist, kann der Schlüssel reproduziert werden.

Was ist neu

Schlüssel aus Signaturen abzuleiten ist nicht neu. Diese Systeme tun es bereits produktiv:

Nach unserem Kenntnisstand ist SplitSig das erste Verfahren, das signaturbasierte Schlüssel mit einem clientseitigen Nonce-Split kombiniert. Der Grund, warum es bisher nicht aufgetaucht ist, liegt vermutlich darin, dass LNURL-auth eine Bitcoin/Lightning-Nische ist, während die meiste Arbeit an signaturbasierten Schlüsseln im Ethereum-Ökosystem stattfand — wo die Wallet lokal signiert und der Server die Signatur nie sieht.

Bedrohungsmodell

Kompromittierter Server: Hat die Signatur, aber nicht den Nonce. Kann den Schlüssel nicht ableiten. Selbst wenn alle Signaturen dauerhaft gespeichert werden, ist das Brute-Forcen eines 256-Bit-Nonce nicht durchführbar.

Kompromittierter Browser: Hat beide Teile. Kann den Schlüssel ableiten. Das ist das „Trusted Code Delivery Problem" — eine inhärente Einschränkung aller Web-Anwendungen. Blockstream hat festgestellt: „Ein Browser muss immer als kompromittiert betrachtet werden." Native Apps mit reproduzierbaren Builds sind die einzige vollständige Absicherung.

Gestohlenes Recovery Kit: Hat den Nonce, aber nicht die Signatur. Kann den Schlüssel nicht ableiten, ohne den BIP-32-Seed der Wallet zu besitzen.

Verlorener Wallet-Seed: Anderer Seed = andere Signatur = anderer Schlüssel. Dasselbe Risiko wie bei jedem Seed-basierten System.

Anwendungen

SplitSig funktioniert für jede Web-Anwendung, die LNURL-auth nutzt und non-custodial Signaturschlüssel benötigt:

• Nostr-Clients — Signaturschlüssel aus Lightning-Wallet-Login ableiten, kein nsec in ein Webformular einfügen
• Ecash-Wallets (Cashu, Fedimint) — Spending Keys in browserbasierten Wallets schützen
• Swap-Dienste — Claim Keys für Submarine Swaps ableiten
• Escrow-Dienste — Käufer/Verkäufer-Schlüssel für Multisig-Verträge ableiten
• Jede Web-Wallet — Non-custodial Key Management mit bestehender Lightning-Infrastruktur

Ausprobieren

Die interaktive Demo zeigt jeden Schritt des Protokolls und macht sichtbar, was der Server sieht und was im Browser bleibt.