Circle of Competence Nutze nur, was du verifizieren kannst

Warren Buffett und Charlie Munger prägten das Konzept des Circle of Competence: Du musst nicht alles verstehen. Du musst nur deinen Bereich kennen – und, entscheidend, die Grenzen dieses Bereichs.

Übertragen auf Bitcoin bedeutet das: Sobald du Tools, Protokolle oder „Magic Features“ nutzt, die du nicht erklären und zumindest grob auditieren kannst, verlässt du deinen Kompetenzkreis. Jenseits dieser Grenze ersetzt du Verifizierung durch Autoritätsglauben. Du bist dann kein Souverän mehr – du bist Benutzer.

Diese Schnittmenge ist dein Kompetenzkreis. Alles außerhalb dieser Zone ist Delegation – und Delegation bedeutet Vertrauen. Die Frage ist nicht, ob du vertraust. Die Frage ist, ob du weißt, dass du vertraust.

Die meisten Menschen unterschätzen die Grenze. Sie glauben, ein Produkt zu „verstehen“, weil sie seine Oberfläche bedienen können. Aber die Oberfläche ist nicht das System. Das System ist die Logik darunter – der Code, die Kryptografie, die Firmware, die Abhängigkeiten. Epistemische Demut bedeutet: die Grenze dort zu ziehen, wo dein tatsächliches Verständnis endet.

„Don’t Trust, Verify“ ist kein Marketing-Slogan. Es ist eine physische Operation. Wenn du verifizierst, lädt deine Hardware Bits, berechnet Signaturen und Hashes, prüft Regeln. CPU-Zeit wird verbraucht, Energie wird aufgewendet. Verifizierung hat einen Preis – und deshalb ist sie wertvoll.

Social Verification bedeutet: „Ich glaube dem Explorer, der Börse, dem Experten.“ Keine eigene Arbeit, volle Abhängigkeit. Du delegierst deine Wahrheit an eine Autorität, die du nicht kontrollierst.

Computational Verification bedeutet: Deine Node validiert jeden Block, jede Signatur. Du akzeptierst nur Zustände, die deine Maschine nach festen, öffentlichen Regeln durchgerechnet hat. Die Wahrheit ist dann nicht mehr eine Meinung, sondern ein Rechenergebnis deiner eigenen Hardware.

Je komplexer ein System (Codebase, Features, Abhängigkeiten), desto kleiner ist der Teil, den ein Individuum real überblicken kann. Das ist keine Einschränkung deiner Intelligenz – es ist eine mathematische Realität.

Jedes Feature – Swap, Buy, Staking, NFT-Support, Cloud-Backup – erhöht Codeumfang, Abhängigkeiten und Angriffsoberfläche. Damit steigen auch die Verifizierungskosten C_v. Wenn C_v über deine kognitive und zeitliche Kapazität steigt, schrumpft dein effektiver Kompetenzkreis.

Du kannst dann nur noch hoffen, dass niemand einen Fehler oder eine Hintertür eingebaut hat. Das ist keine Verifizierung – das ist Gebet. Feature-Creep in Wallets führt dazu, dass aus einem „Schlüssel-Werkzeug“ ein Mini-Bankensystem wird – für den Souveränen genau falsch herum.

Einfachheit (klare, begrenzte Funktionalität, minimaler Code, FOSS) maximiert V: Du kannst mehr vom Verhalten des Systems mit endlichen Ressourcen nachvollziehen.

Closed-Source-Software und proprietäre Hardware sind physische Black Boxes: Du kannst ihre inneren Zustände nicht inspizieren, nur ihre Outputs beobachten. Ohne Offenlegung von Code und Design bleibt dir nur zu glauben, dass die Box tut, was sie verspricht. Verifikation degeneriert zu „Vertrauen in Marke/Regulator“.

Fallstudie: Ledger Recover

Ledger Recover teilt einen verschlüsselten Schlüssel in Shamir-Shards und verteilt sie auf Drittparteien. Selbst wenn der Anbieter verspricht, dass alles sicher und optional sei, kannst du als Nutzer nicht unabhängig prüfen, ob Firmware oder Backend jemals unerwartet zusätzliche Kopien erzeugt – oder auf Behördenanfrage erweitert wird.

Die Nutzung eines solchen Features liegt fast zwangsläufig außerhalb eines realistischen Kompetenzkreises. Du musst der Institution vertrauen, nicht deiner eigenen Verifikation. Das ist per Definition keine souveräne Infrastruktur – weil ihre Sicherheit nicht durch individuell reproduzierbare Checks begründet werden kann.

Die Unterscheidung ist nicht moralisch, sondern epistemisch. Ein User wählt maximale Bequemlichkeit: Mobile-Only-Apps, Custody-Services, Black Boxes. Er outsourct Verifikation und bleibt im Grunde ein Subjekt – abhängig von den Entscheidungen anderer.

Ein Souverän betreibt eigene Infrastruktur, nutzt FOSS-Wallets mit minimal notwendiger Funktionalität, vermeidet obligatorische Backups und Recover-Services. Er akzeptiert begrenzten UX-Komfort zugunsten maximaler Verifizierbarkeit.

Der Souverän skaliert seine Exposure – Betrag und Komplexität – nur innerhalb des Bereichs, den er nachvollziehen kann. Alles andere bleibt experimentell und klein. Je enger du dein Toolset an deinen realen Verifizierungsfähigkeiten ausrichtest, desto größer ist deine tatsächliche Souveränität.

Vor jeder Tool-Wahl solltest du fünf Fragen stellen. Wenn du eine davon nicht befriedigend beantworten kannst, liegt das Tool möglicherweise außerhalb deines Kompetenzkreises – und damit außerhalb souveräner Nutzung.

Verstehe ich die Kernfunktion? Kann ich in drei bis vier Sätzen erklären, was dieses Tool auf Protokoll-Ebene tut – Signieren, Validieren, Indexieren, Mixen?

Kann ich das Ergebnis unabhängig prüfen? Kann ich Balance und Transaktionen gegen eine eigene Node verifizieren, Firmware-Hashes prüfen, Binaries reproduzieren?

Ist der Code/Standard offen? Existiert FOSS-Code oder zumindest ein offener, überprüfter Standard (BIP, RFC), an den sich mehrere Implementierungen halten?

Was passiert, wenn die Firma verschwindet? Kann ich mit offenen Tools und meinem Seed/Descriptor alles wiederherstellen, ohne proprietäre Server?

Wie viel Komplexität muss ich wirklich nutzen? Kann ich Features selektiv abschalten – kein Recover, kein Cloud-Backup, kein integrierter Brokerage?