Single-Signer-Multisig: wie SSP zwei Geräte wie eine Wallet anfühlen lässt

Wenn du diese Serie seit Was ist Multisig verfolgst, kennst du das Protokoll: mehr als ein privater Schlüssel muss signieren, bevor Geld sich bewegt. Du hast den m-of-n-Picker, die BIP48-Verdrahtung, den Schnorr-Aggregations-Horizont und den Social-Recovery-Vergleich gesehen. Das alles ist die Maschinerie. Dieser Artikel handelt von der Erfahrung.

Die ehrliche historische Kritik an Multisig: er war benutzerfeindlich. Mehrere Wallets, manuelles PSBT-Hin und -Her, Coordinator-Software, Signier-Parties — das Protokoll war solide, aber die UX war eine Strafe. Single-Signer-Multisig ist die Produktidee, die das behebt: eine Wallet, die on-chain eine vollständige Multisig-Ausgaberegel verwendet, sich aber — aus Sicht der Person, die sie nutzt — wie eine einzige Wallet mit einem Knopf anfühlt. SSP ist um diese Idee gebaut.

TL;DR

• „Single-Signer" bedeutet nicht ein Schlüssel. Es bedeutet, dass das Protokoll weiterhin m von n Schlüsseln hat, aber die Signier-UX in einen einzigen Ablauf kollabiert ist. Der Nutzer signiert an einer Stelle; die Wallet kümmert sich um die Geräte-zu-Geräte-Koordination.
• Die konkrete SSP-Form: eine Browser-Erweiterung, eine mobile App (SSP Key), eine Wallet-Identität. Du klickst Send, bestätigst auf dem Handy, die Transaktion wird broadcastet. Zwei Signaturen passieren; du erlebst eine.
• Der Gewinn ist, dass der Schwellen-Vorteil (Diebstahlschutz, kein Single-Point-of-Failure) erhalten bleibt, während die Koordinations-Kosten fast auf Single-Sig-UX-Niveau sinken.
• Der Preis ist, dass es nur funktioniert, solange beide Geräte erreichbar sind. Sobald die UX die Multi-Natur offenlegen muss — Recovery, Geräteersatz, Wiederherstellung bei Dritten — bricht die Abstraktion, by Design.
• Dieses Muster ist die nächste Annäherung an eine kompromisslose Antwort für Solo-Self-Custody auf Retail-Niveau. Es ist die SSP-Wette und zunehmend die Wette jedes modernen Multisig-Produkts (Coinbase Wallet, Phantoms sich entwickelnde Custody-Story, Safes Smart-Account-Flow auf Ethereum).

Das Single-Signer-Ideal: was Nutzer wirklich wollen

Fragt man einen Self-Custody-Nutzer, was er will, bekommt man widersprüchliche Antworten:

• „Ich will meine Coins sicher." — Impliziert Multisig, Hardware, Redundanz.
• „Ich will in fünf Sekunden eine Transaktion signieren." — Impliziert ein einziges Gerät, einen Tap.
• „Ich will wiederherstellen können, wenn ich etwas verliere." — Impliziert Seed-Backups, Redundanz.
• „Ich will nie wieder eine Seed aufschreiben." — Impliziert plattform-verwaltete Schlüssel-Custody.
• „Es soll günstig sein." — Impliziert einen minimalen On-Chain-Footprint.

Diese Ziele passen nicht alle zusammen. Die Geschichte des Self-Custody-Wallet-Designs ist die Geschichte, welche Ziele man ehrt und welche man höflich ablehnt. Hardware-Wallets ehren Sicherheit und Recovery zum Preis der UX. Smart-Contract-Wallets ehren UX und Recovery zum Preis von Cross-Chain-Reichweite. Reine Hot Wallets ehren UX und Günstigkeit zum Preis der Sicherheit.

Single-Signer-Multisig ist ein Versuch, alle fünf zu ehren — teilweise — indem Protokoll-Semantik von Interface-Semantik getrennt wird. Die Wallet macht weiterhin den vollen Multisig-Tanz on-chain; der Nutzer muss nur nicht mehr als einmal pro Transaktion an diesem Tanz teilnehmen.

Wie SSP es liefert

SSPs konkrete Umsetzung, im Klartext:

1. Beim Setup installierst du die Browser-Erweiterung und die mobile App (SSP Key). Jede generiert ihre eigene Seed, die du separat sicherst (das ist der Schritt aus der Erste-1000-Checkliste). Die beiden Geräte tauschen öffentliche Schlüssel; ab da teilen sie auf Protokoll-Ebene eine Wallet-Identität.
2. Beim Alltagssignieren klickst du Send in der Browser-Erweiterung, prüfst die Transaktion und genehmigst. Die Erweiterung baut eine teil-signierte Transaktion und schickt eine Push-Benachrichtigung an dein Handy. Die mobile App zeigt die Transaktions-Details, du tippst Genehmigen, und die App erzeugt die zweite Signatur. Die Erweiterung kombiniert beide Signaturen und broadcastet. Gesamtdauer: rund 8 Sekunden, wenn beide Geräte vor dir liegen.
3. Beim Empfang ist die angezeigte Adresse die BIP48-abgeleitete Multisig-Adresse aus beiden xpubs. Du scannst oder kopierst sie; der Absender sieht nichts Ungewöhnliches. Aus seiner Sicht sieht es wie jede andere Krypto-Adresse aus.
4. Beim Abgleich zeigt dir die Wallet Salden, Verlauf, Gebühren usw. identisch zu einer Single-Sig-Wallet. Es gibt keine separate „Multisig-Ansicht". Die Protokoll-Gestalt ist im Alltagsgebrauch unsichtbar.

Die zentrale Design-Entscheidung ist, dass die zweite Signatur die einzige Multi-Natur ist, an die der Nutzer je denken muss. Setup sind zwei Geräte, Signieren ein extra Tap, und das ist die gesamte Oberfläche des Multisig-Protokolls aus Nutzersicht.

Ein kleines, aber wichtiges Detail: die SSP-Browser-Erweiterung und SSP Key sind nicht ko-lokalisiert. Sie laufen auf verschiedenen OS, unterschiedlicher Hardware, mit unterschiedlichen Angriffsoberflächen. Das macht das Zwei-Signatur-Setup zu einer echten Diebstahl-Barriere und nicht nur zu einem UX-Bremshügel. (Wir entpacken das im Sieben-Ausfallmodi-Beitrag und in Was ist 2-of-2-Multisig.)

Was der Nutzer nie sieht

Viel Arbeit geht in das Vermeiden, dass der Nutzer je mit Multisig-Klempnerei zu tun hat. Konkret:

• PSBT (Partially Signed Bitcoin Transactions) sind die wuchtigen Datenstrukturen, die zwischen den mit-signierenden Geräten wandern. In einem traditionellen Multisig-Setup kopierst und fügst du sie manuell ein. SSP serialisiert und überträgt sie über seinen eigenen Koordinationskanal; der Nutzer sieht eine Benachrichtigung, keinen base64-String.
• Der Cosigner-xpub-Austausch ist ein einmaliges Setup-Ereignis. In traditionellem Multisig importierst du xpubs explizit von jedem Cosigner. SSP packt das in den Pairing-Flow beim Setup; du bestätigst einen QR-Code oder einen sechsstelligen Code und berührst das zugrundeliegende Material nie.
• Gebühren-Schätzung, Wechselgeld-Handling und Adress-Rotation werden von der Wallet genauso behandelt wie bei Single-Sig-Wallets, obwohl die Wallet selbst unter der Haube Multisig ist.
• Das Redeem-Script — das BIP48-kanonische Skript, das die Multisig-Regel beschreibt — baut die Wallet automatisch. Nutzer sehen es nicht, genehmigen es nicht zeilenweise, müssen nicht wissen, dass es existiert. (Sie können es im Block-Explorer sehen, wenn sie suchen — das ist die sauberste „zeig deine Arbeit"-Eigenschaft von Multisig-Wallets.)

All diese Abstraktion ist notwendige Arbeit, aber auch das Risiko — jedes Mal, wenn das Protokoll vor dem Nutzer verborgen wird, übernimmt die Wallet die Verantwortung, den verborgenen Teil richtig hinzubekommen. SSPs Audit-Arbeit (Halborn) dreht sich weitgehend genau um diese unsichtbaren Codepfade.

Wann es sich nicht mehr Single-Signer anfühlt

Die Abstraktion ist nicht perfekt, und es ist wichtig, zu wissen, wo sie bricht. Single-Signer-UX hält, solange beide Geräte verfügbar sind. Die Risse zeigen sich, wenn eines nicht verfügbar ist:

• Geräteersatz. Wenn du dein Handy tauschst, muss das neue Gerät neu gepairt werden. Das ist ein einmaliger sichtbarer Multisig-Koordinationsschritt — die Wallet führt dich durch das erneute Sich-Zeigen beider Geräte.
• Seed-Recovery. Wenn ein Gerät zerstört wird, stellst du es aus seiner Seed Phrase auf einem neuen Gerät wieder her und pairst neu. Die Tatsache, dass du zwei Seeds hast (eine pro Gerät), wird in diesem Moment auf eine Weise sichtbar, wie sie es im normalen Gebrauch nicht war.
• Cross-Software-Recovery. Wenn du je deine zwei SSP-Seeds in eine Drittanbieter-Multisig-Wallet (Sparrow, Electrum etc.) lädst, wird die gesamte Multisig-Klempnerei sichtbar — das ist ein Feature, kein Bug, denn es beweist, dass deine Wallet interoperabel ist, aber es ist nicht die SSP-UX.
• Ausgeben, wenn ein Gerät offline ist. Die Wallet kann ohne beide Geräte nicht mit-signieren; das ist das Protokoll. Du siehst einen „warte auf zweite Signatur"-Zustand, bis das andere Gerät online kommt.

Die ersten drei sind selten genug, um die durchschnittliche UX nicht wirklich zu schmälern. Der vierte ist der häufigste Reibungspunkt — und der richtige Reibungspunkt. Würde die Wallet dich ohne das zweite Gerät ausgeben lassen, wäre es keine 2-of-2-Wallet mehr. Diese Reibung ist die Sicherheit; man kann sie nicht weg-engineeren, ohne die Eigenschaft zu entfernen, für die man bezahlt hat.

Design rund um die Single-Signer-UX

Drei Design-Prinzipien, denen SSP — und andere moderne Multisig-Produkte — folgen, um diese Abstraktion eng zu halten:

1. Die beiden Cosigner müssen in unterschiedlichen Bedrohungsoberflächen leben. Eine Wallet, die beide Cosign-Schlüssel auf dasselbe OS packt, liefert nicht wirklich den Sicherheitsgewinn; sie spreizt nur eine einzige Angriffsoberfläche über zwei Schlösser. SSPs Trennung von Browser-Erweiterung und mobiler App erzwingt das natürlich.
2. Der Koordinationskanal muss unfälschbar sein. Das PSBT, das eine Browser-Erweiterung an die mobile App schickt, muss kryptographisch an die richtige Wallet und die richtige Transaktion gebunden sein; sonst wird die Abstraktion selbst zur Angriffsoberfläche. SSP signiert und validiert dieses Material auf Protokoll-Ebene.
3. Der Nutzer-Vertrag muss ehrlich sein, was verborgen ist. Wallets, die „völlig vertrauenslose Single-Signer-Erfahrung" werben, ohne zu erklären, was bei Recovery passiert, setzen Nutzer einer unschönen Überraschung aus. SSPs Onboarding läuft beide Seeds, beide Backups und beide Recovery-Szenarien ausdrücklich durch — die Abstraktion ist im Gebrauch verborgen, aber im Onboarding sichtbar, damit sie dich später nicht überfällt.

Account-Abstraction-Wallets auf Ethereum haben ein viertes Werkzeug: die Smart-Contract-Schicht. Mit ERC-4337 kann eine Wallet Gas-Gebühren absorbieren, Transaktionen bündeln und eine noch „Single-Signer-ähnlichere" UX bieten und Multisig unter der Haube umsetzen. SSP hat diese Schicht auf Bitcoin nicht (keine Smart Contracts), also stützt sich die Abstraktion mehr auf UX-Engineering als auf chain-seitige Absorption. Beide Wege sind valide; der Ethereum-Weg ist flexibler zum Preis der Chain-Spezifität, der SSP-Weg ist portabler zum Preis von mehr UI-Arbeit.

Was das für dich bedeutet

Drei Kernpunkte:

1. Die „fühlt sich wie eine Wallet an"-Erfahrung ist das Headline-Feature, nicht Multisig selbst. Wenn dein Freund fragt „ist SSP eine Multisig-Wallet?", lautet die technisch wahre Antwort ja, aber die nützliche Antwort ist „es ist eine 2-Geräte-Wallet, in der ein Tap auf dem Handy eine Ausgabe bestätigt". Das fängt ein, was Leute wirklich fühlen.
2. Die Reibung, die du siehst, leistet echte Arbeit. Jedes Mal, wenn SSP dich um Bestätigung auf dem Handy bittet, setzt es das Protokoll durch, das verhindert, dass ein kompromittierter Laptop deine Mittel leert. Diese Reibung ist der Hauptgrund, warum du überhaupt eine 2-of-2-Wallet statt einer Hot Wallet verwendest.
3. Behandle die Abstraktion als Vertrag, nicht als Magie. Der letzte Artikel dieser Serie, Multisig-Ausfallmodi und wie SSP sie abmildert, geht durch, was passiert, wenn jedes Stück der Abstraktion bricht — Geräteverlust, Schlüsselkompromittierung, Ausfall des Signing-Servers. Lies ihn einmal. Die Abstraktion ist gut gebaut, aber das Verständnis der Ausfallszenarien macht aus dir die Art von Self-Custody-Nutzer, für die diese ganze Serie gedacht ist.