How can chess positions hold a 256-bit Bitcoin private key?

A single legal chess position with the standard 32-piece army (pawns on ranks 2-7, bishops on opposite-coloured squares) carries about 148 bits of combinatorial information. Two such positions together comfortably encode 256 bits — exactly the size of a secp256k1 private key. The mapping is a clean combinatorial bijection between integers and board placements.

secp256k1 is the elliptic curve used by Bitcoin. Its group order n is approximately 2^256 − 2^32 − 977. Any 256-bit integer between 1 and n−1 is a valid private key; the chance that a random board falls outside this range is about 1 in 2^224 — effectively never.

Can I paste my own FEN into the converter?

Yes. Each board has an editable FEN input. If your position matches the schema (full 32-piece standard army, pawns on ranks 2-7, bishops on opposite colours), the Bitcoin key updates immediately. If it does not match, the board still renders so you can see it, but the input is flagged red with an explanation of which constraint failed.

Can a chess position derive a Bitcoin address?

Yes. The board decodes to a private key k. We compute the public key P = k·G on secp256k1, then HASH160 = RIPEMD-160(SHA-256(P)). The result is encoded as Base58Check (legacy) or Bech32 (SegWit) to give the address. This step is one-way: nobody can recover k from the address.

Is a chessboard cold wallet a real idea?

It is a legitimate (but experimental) cold-storage technique. Humans are dramatically better at remembering visual patterns than 52 random base58 characters. A chess player can memorise a position effortlessly. Print the board, hide it inside a chess book, and the key is stored in plausible deniability.

What is the difference between Base58Check and Bech32 addresses?

Base58Check (legacy P2PKH, prefix 1) appends a 4-byte double-SHA-256 checksum and uses a 58-character alphabet. Bech32 (SegWit, prefix bc1) uses a 32-symbol alphabet with a 30-bit BCH polynomial checksum that detects any single-symbol error with probability 1. Bech32 is the modern default.

Is it safe to use the converter?

All cryptographic operations run in your browser using the audited noble-secp256k1 and noble-hashes libraries. Nothing is transmitted to any server. That said: never use a key generated by a public tool to store real Bitcoin. Use it strictly for art and education.

Bitcoin als Schachbrett: Wie 64 Felder einen 256-Bit Private Key codieren

Es liegt eine stille Perfektion darin, dass das beliebteste Brettspiel der Geschichte und die erfolgreichste Kryptowährung exakt dieselbe Informationskapazität teilen. Dieser Artikel erklärt warum — und zeigt dir, wie du zwischen beiden konvertieren kannst.

1. Warum 256 Bit auf 64 Felder passen

Bitcoin Private Keys sind ganze Zahlen auf der elliptischen Kurve secp256k1. Der gültige Bereich ist [1, n−1] mit n ≈ 2²⁵⁶ − 2³² − 977. In der Praxis ist fast jede 256-Bit-Zeichenkette ein gültiger Schlüssel — die Wahrscheinlichkeit, in der verbotenen Zone zu landen, beträgt etwa 1 zu 2²²⁴.

Ein Schachbrett hat 8 × 8 = 64 Felder, doch nicht jede Anordnung ist eine legale Stellung. Die Standard-Armee hat genau 32 Figuren (2 Könige, 2 Damen, 4 Türme, 4 Läufer — je einer pro Feldfarbe — 4 Springer, 16 Bauern). Zählt man die Anordnungen auf 64 Feldern mit Bauern nur auf den Reihen 2–7, erhält man etwa 2¹⁴⁸ Stellungen. Ein Brett trägt also 148 Bit; zwei Bretter rund 296 Bit — mehr als genügend für 256 Bit.

                log₂(positions per board) ≈ 148 bits   ·   2 boards ≈ 296 bits   ≥   256 bits = 1 Bitcoin private key ✓
            

2. Das 32-Figuren-Standard-Armee-Schema

Statt neue Figuren zu erfinden bleibt der Visualiser bei der Standard-Armee aus 32 Figuren, die jeder Schachspieler kennt. Jede kodierte Stellung enthält genau: 1 weißen und 1 schwarzen König, 1 weiße und 1 schwarze Dame, 2 Türme pro Farbe, 2 Läufer pro Farbe (einer auf hellem, einer auf dunklem Feld), 2 Springer pro Farbe und 8 Bauern pro Farbe. Die Einschränkungen:

Alle 32 Figuren sind vorhanden (keine Schläge, keine Umwandlungen).
Bauern stehen auf beliebigen Feldern der Reihen 2 bis 7 (nie auf den Grundreihen).
Die zwei Läufer jeder Seite stehen auf Feldern unterschiedlicher Farbe (einer hell, einer dunkel) — wie in jeder Standardstellung.

Diese drei Einschränkungen definieren die exakte Menge der Stellungen, über der die Bijektion aufgebaut ist. Die numerische Platzierungsreihenfolge ist fix (Könige, Damen, Türme, Läufer, Springer, Bauern), damit Encoder und Decoder bei den Stellenwerten übereinstimmen.

3. Anatomie eines Bitcoin Private Keys

Ein roher Private Key sind nur 32 zufällige Bytes. Damit er zwischen Wallets transportierbar ist, definiert Bitcoin das WIF (Wallet Import Format):

                WIF = Base58Check(

                    0x80 (network byte — mainnet)

                    ‖ key (32 bytes)

                    ‖ 0x01 (compressed flag)

                    ‖ checksum (4 bytes = first 4 of double-SHA-256)

                )

Mainnet vs Testnet — ein häufiger Irrtum. Der 32-Byte-Private-Key selbst ist nur eine Zahl; er ist auf jedem Bitcoin-Netzwerk identisch. Unterschiedlich ist nur die sichtbare Kodierung: WIF nutzt Präfix 0x80 im Mainnet und 0xEF im Testnet, Adressen bc1… / 1… statt tb1… / m… / n…. Das Brett kodiert den Schlüssel, nicht das Netzwerk — dieselben zwei Stellungen ergeben beide Adressen, je nachdem wie man sie ausdruckt. Unser Konverter zeigt Mainnet, weil das jeder kennt.

Für unsere Zwecke zählen nur die mittleren 32 Byte — das ist, was wir aufs Brett malen. Präfix, Flag und Prüfsumme werden bei der WIF-Anzeige automatisch ergänzt.

4. Vom Schlüssel zur Adresse: ECDSA → HASH160

Bei einem Private Key k ist der Public Key der Kurvenpunkt P = k · G, wobei G der feste Erzeugerpunkt von secp256k1 ist. Dieser Schritt ist eine Einbahnstraße: die Rückgewinnung von k aus P ist das diskrete-Logarithmus-Problem und praktisch nicht lösbar.

Die Adresse wird berechnet als:

                pubkey = compress(k · G)           # 33 bytes

                hash160 = RIPEMD-160(SHA-256(pubkey))  # 20 bytes

                legacy_address  = Base58Check(0x00 ‖ hash160)

                segwit_address  = Bech32('bc', 0, hash160)

5. Prüfsummen: Base58Check vs Bech32

Base58Check (Legacy-Adressen und WIF-Keys) hängt 4 Byte gekürztes Doppel-SHA-256 an die Nutzlast und kodiert alles in einem 58-Zeichen-Alphabet (ohne 0, O, I, l). Jeder Tippfehler hat etwa 1 zu 2³² Wahrscheinlichkeit, einen gültigen String zu erzeugen.

Bech32 (BIP-173, SegWit) ist deutlich raffinierter: ein 30-Bit-BCH-Polynomcode über GF(32). Es erkennt jeden Einzel-Symbolfehler mit Wahrscheinlichkeit 1 und jeden Zwei-Symbol-Fehler mit Wahrscheinlichkeit ≥ 1 − 2⁻³⁰. Sein 32-Symbol-Alphabet passt perfekt zu den 32 hellen Feldern des Schachbretts — ein Zufall, den wir unten nutzen.

6. Die Bijektion im Code

Jedes Brett kodiert eine 128-Bit-Hälfte des Schlüssels (untere Hälfte auf Brett 1, obere auf Brett 2). Da das Schema nur eine feste Menge legaler Stellungen zulässt, ist die Bijektion keine einfache Feld-Lookup-Tabelle \u2014 sondern ein kombinatorisches Unranking. Platziere die Figuren in fester Reihenfolge (Könige, Damen, Türme, Läufer, Springer, Bauern); in jedem Schritt wählst du k Felder aus den verbleibenden n leeren; der Auswahlindex ist eine Ziffer in einem gemischtradixen System mit Basis C(n, k) pro Schritt.

                // encode 128-bit BigInt x into a board

                let rem = x;

                for (const step of placementOrder) {           // WK, BK, WQ, BQ, WR, BR, …

                  const base   = C(step.n, step.k);

                  const digit  = rem % base;

                  rem          = rem / base;

                  placeOnSquares(unrankCombo(digit, step.n, step.k), step.piece);

                }

                // decode \u2014 Horner with the same bases in reverse

                let x = 0n;

                for (let i = steps.length - 1; i >= 0; i--) {

                  x = steps[i].digit + steps[i].base * x;

                }

Läufer haben einen leicht anderen Schritt: jede Seite wählt einen Läufer auf einem hellen Feld aus den verfügbaren hellen und einen auf einem dunklen aus den dunklen, also Basis nL × nD. Bauern werden auf Reihen 2\u20137 beschränkt, indem die verbleibenden leeren Felder vor der Binomialwahl gefiltert werden. Der gesamte Algorithmus liegt in ca. 40 Zeilen reinem JavaScript mit BigInt; im Quelltext des Konverters direkt nachlesbar.

7. Der Visualiser: zwei Bretter, editierbare FENs

Der Konverter zeichnet beide Hälften als echte Schachdiagramme mit chessboard.js und dem Wikipedia-Figurensatz \u2014 derselben Bibliothek und Grafik wie der Vote-Chess-Raum der Liga. Das linke Brett trägt die unteren 128 Bit, das rechte die oberen 128 Bit. Unter jedem Brett steht die Stellung als FEN in einem editierbaren Eingabefeld.

Du kannst jeden beliebigen FEN einfügen. Das Brett zeichnet sich sofort neu, damit du die Stellung immer siehst, und der Rand des Eingabefelds wird grün oder rot, je nachdem ob die Stellung ins Bijektions-Schema passt:

Grüner Rand: die Stellung enthält alle 32 Figuren, Bauern auf Reihen 2\u20137 und Läufer auf verschiedenen Feldfarben \u2014 der Bitcoin-Schlüssel aktualisiert sich sofort.
Roter Rand: der FEN wird geparst, doch die Stellung kann keinen Schlüssel kodieren (fehlende Figuren, Bauer auf Reihe 1 oder 8, zwei Läufer auf gleicher Feldfarbe usw.). Das Brett zeigt sie zur Begutachtung; nur der Schlüssel bleibt unverändert.

Ein kleiner Kopier-Button neben jedem FEN-Input kopiert die Stellungs-Zeichenkette zum Teilen oder Speichern. Der "Berühmte Stellungen"-Picker, der Zufalls-Button und die PNG/Teilen-Buttons nutzen dieselbe Render-Pipeline \u2014 alles, was auf einem Brett erscheint, lässt sich jederzeit als FEN exportieren.

8. Anwendungen

Schach-Paper-Wallet. Stellung ausdrucken und in ein Eröffnungsbuch legen. Glaubhafte Abstreitbarkeit + null Elektronik + lesbar.
Generative Kunst. Schachbretter als NFTs prägen, die zugleich gültige Bitcoin-Schlüssel sind. Jede Stellung ist nachweislich einmalig.
Vanity-Bretter. Bretter brute-forcen, deren Adressen mit gewünschten Buchstaben beginnen (bc1qchess…).
Bildung. Ein Schachbrett ist die anschaulichste Methode, die Größe kryptografischer Schlüsselräume zu vermitteln.
Memorisierung. Schachspieler merken sich Hunderte Stellungen mühelos. Ein Brett ist viel leichter zu merken als ein 52-Zeichen-WIF.

9. Sicherheitsüberlegungen

Verwende niemals einen in einem öffentlichen Tool generierten Schlüssel für echte Bitcoin.
Denk daran, dass der Private Key auf Mainnet und Testnet dieselbe Zahl ist — nur die sichtbare Kodierung ändert sich. Ein Brett, das eine gültige Mainnet-Adresse erzeugt, erzeugt auch die entsprechende Testnet-Adresse.
Verwende crypto.getRandomValues() (oder Hardware-RNG) — nie Math.random() — zur Schlüsselerzeugung.
Die gesamte Kryptografie muss client-seitig laufen. Der Server darf den Schlüssel nie sehen.

10. Häufig gestellte Fragen

Können zwei verschiedene Schlüssel je dasselbe Brett ergeben?

Nein. Die Abbildung ist eine perfekte Bijektion über 2²⁵⁶ Elemente — jedes Brett entspricht genau einer 256-Bit-Zahl und umgekehrt. Einzige Ausnahme ist die winzige Menge außerhalb [1, n−1], das sind keine gültigen Bitcoin-Schlüssel.

Könnte die Endstellung einer berühmten Partie zu einer realen Bitcoin-Adresse dekodieren?

Mathematisch ja — jede legale Stellung dekodiert zu irgendeiner 256-Bit-Zahl und damit zu irgendeinem Private Key. Ob dieser ein Guthaben kontrolliert, ist eine Brute-Force-Frage. Mit ~10⁹ aktiven Adressen aus 2¹⁶⁰ ist die Wahrscheinlichkeit astronomisch klein (~10⁻³⁹).

Welche Bibliotheken nutzt der Konverter?

Der Konverter lädt @noble/secp256k1 und @noble/hashes — beide sind reine JS-Bibliotheken ohne Abhängigkeiten, auditiert, von Paul Miller. Base58Check und Bech32 sind inline in ~80 Zeilen implementiert.

Bereit, deinen Schlüssel als Stellung zu sehen?

Interaktiven Konverter öffnen

Bitcoin als Schachbrett

Sieh deinen Bitcoin-Schlüssel als Schachstellung