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 como tablero de ajedrez: cómo 64 casillas codifican una clave privada de 256 bits

Hay algo silenciosamente perfecto en el hecho de que el juego de mesa más popular de la historia y la criptomoneda más exitosa compartan exactamente la misma capacidad de información. Este artículo explica por qué — y te muestra cómo convertir entre ambos.

1. Por qué 256 bits caben en 64 casillas

Las claves privadas de Bitcoin son enteros sobre la curva elíptica secp256k1. El rango válido es [1, n−1], donde n ≈ 2²⁵⁶ − 2³² − 977. En la práctica, casi cualquier cadena de 256 bits es una clave válida — la probabilidad de caer en la zona prohibida es aproximadamente 1 entre 2²²⁴.

Un tablero de ajedrez tiene 8 × 8 = 64 casillas, pero no toda disposición es una posición legal. El ejército estándar tiene 32 piezas (2 reyes, 2 damas, 4 torres, 4 alfiles — uno de cada color por bando — 4 caballos, 16 peones). Contando las formas de colocarlos en 64 casillas con los peones restringidos a las filas 2–7 obtenemos aproximadamente 2¹⁴⁸ posiciones distintas. Un tablero guarda 148 bits; dos tableros aproximadamente 296 bits, que absorben cómodamente los 256 bits de una clave.

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

2. El esquema de 32 piezas estándar

En lugar de inventar piezas nuevas, el visualizador se atiene al ejército estándar de 32 piezas que todo ajedrecista conoce. Cada tablero codificado contiene exactamente: 1 rey blanco, 1 rey negro, 1 dama blanca, 1 dama negra, 2 torres de cada color, 2 alfiles de cada color (uno en casilla clara y otro en oscura), 2 caballos de cada color y 8 peones de cada color. Las restricciones son:

Las 32 piezas están presentes (sin capturas ni promociones).
Los peones pueden estar en cualquier casilla de las filas 2 a 7 (nunca en las filas finales).
Los dos alfiles de cada bando ocupan casillas de colores opuestos (uno en clara, otro en oscura) — como en toda apertura estándar.

Estas tres restricciones definen el conjunto exacto de posiciones sobre el que se construye la biyección. El orden numérico de colocación es fijo (reyes, damas, torres, alfiles, caballos, peones) para que codificador y decodificador coincidan en los pesos.

3. Anatomía de una clave privada Bitcoin

Una clave privada en crudo son sólo 32 bytes aleatorios. Para transportarla entre monederos, Bitcoin define el 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 — confusión común. La clave privada de 32 bytes es sólo un número; es idéntica en toda red Bitcoin. La única diferencia es la codificación visible: WIF usa prefijo 0x80 en mainnet y 0xEF en testnet, las direcciones usan bc1… / 1… frente a tb1… / m… / n…. El tablero codifica la clave, no la red — las mismas dos posiciones generan ambas direcciones, depende sólo de cómo decidas imprimirlas. Nuestro conversor muestra mainnet porque es lo reconocible.

Para nuestro propósito, sólo importan los 32 bytes centrales — eso es lo que pintamos en el tablero. Prefijo, flag y checksum se añaden automáticamente al mostrar el WIF.

4. De clave a dirección: ECDSA → HASH160

Dada la clave privada k, la clave pública es el punto de la curva elíptica P = k · G, donde G es el punto generador fijo de secp256k1. Este paso es unidireccional: recuperar k a partir de P es el problema del logaritmo discreto, computacionalmente infactible.

La dirección se calcula como:

                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. Sumas de verificación: Base58Check vs Bech32

Base58Check (direcciones legacy y claves WIF) añade 4 bytes de doble-SHA-256 truncado al payload y lo codifica en un alfabeto de 58 caracteres (sin 0, O, I, l). Cualquier error de tipeo tiene una probabilidad de aproximadamente 1 entre 2³² de producir una cadena "válida".

Bech32 (BIP-173, SegWit) es mucho más inteligente: usa un código BCH de 30 bits sobre GF(32). Detecta cualquier error de un símbolo con probabilidad 1, y cualquier par de errores con probabilidad ≥ 1 − 2⁻³⁰. Su alfabeto de 32 símbolos también encaja perfectamente con las 32 casillas claras del tablero — una coincidencia que aprovechamos abajo.

6. La biyección en código

Cada tablero representa una mitad de 128 bits de la clave (mitad baja en el tablero 1, mitad alta en el tablero 2). Como el esquema admite sólo un conjunto fijo de posiciones legales, la biyección no es una simple búsqueda por casilla \u2014 es una unranking combinatoria. Coloca las piezas en orden fijo (reyes, damas, torres, alfiles, caballos, peones); en cada paso, elige k casillas entre las n vacías restantes; el índice de la elección es un dígito en un sistema mixto cuya base en cada paso es C(n, k).

                // 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;

                }

Los alfiles tienen un paso ligeramente distinto: cada bando elige un alfil de casilla clara entre las claras disponibles y uno oscuro entre las oscuras, así la base es nL × nD. Los peones se restringen a las filas 2\u20137 filtrando las casillas vacías restantes antes del binomio. El algoritmo completo cabe en unas 40 líneas de JavaScript puro con BigInt; puedes leerlo en el código fuente del conversor.

7. El visualizador: dos tableros, FEN editables

El conversor renderiza ambas mitades como diagramas reales con chessboard.js y el set Wikipedia \u2014 la misma librería y gráficos que usa la sala de Vote Chess de la liga. El tablero de la izquierda lleva los 128 bits bajos de la clave, el de la derecha los 128 bits altos. Bajo cada tablero aparece la posición en FEN dentro de un input editable.

Puedes pegar cualquier FEN. El tablero se redibuja al instante para que siempre veas la posición, y el borde del input se pone verde o rojo según si la posición encaja en el esquema:

Borde verde: la posición tiene las 32 piezas, peones en filas 2\u20137 y alfiles en colores opuestos \u2014 la clave Bitcoin se actualiza al instante.
Borde rojo: el FEN se interpreta pero la posición no puede codificar una clave (faltan piezas, un peón en fila 1 u 8, dos alfiles del mismo color, etc.). El tablero la muestra para inspeccionarla; sólo la clave queda igual.

Un pequeño botón de copiar junto a cada input copia la cadena FEN para compartir o guardar. El selector de "Posiciones famosas", el botón aleatorio y los botones PNG/compartir usan la misma tubería, así que todo lo que aparezca puede exportarse como FEN.

8. Aplicaciones

Cartera de papel ajedrecística. Imprime la posición y métela en un libro de aperturas. Negación plausible + cero electrónica + legible por humanos.
Arte generativo. Acuña tableros como NFTs que también sean claves Bitcoin válidas. Cada disposición es demostrablemente única.
Tableros vanity. Buscar tableros que decodifican a direcciones que empiezan con letras elegidas (bc1qchess…).
Educación. Un tablero es la forma más visceral de enseñar la magnitud de los espacios de claves.
Memorización. Los ajedrecistas memorizan cientos de posiciones sin esfuerzo. Un tablero es muchísimo más fácil de recordar que 52 caracteres WIF.

9. Consideraciones de seguridad

Nunca uses una clave generada en una herramienta pública para guardar fondos reales.
Recuerda que la clave privada es el mismo número en mainnet y testnet — sólo cambia la codificación visible. Un tablero que deriva una dirección válida en mainnet también deriva la correspondiente en testnet.
Usa crypto.getRandomValues() (o RNG hardware) — nunca Math.random() — para generar claves.
Toda la criptografía debe correr en el cliente. El servidor no debe ver la clave.

10. Preguntas frecuentes

¿Pueden dos claves distintas producir el mismo tablero?

No. La asignación es una biyección perfecta sobre 2²⁵⁶ elementos — cada tablero corresponde exactamente a un número de 256 bits, y viceversa. La única excepción es el pequeño conjunto fuera de [1, n−1], que no son claves Bitcoin válidas.

¿Podría la posición final de una partida famosa decodificar a una dirección Bitcoin real?

Matemáticamente sí — toda posición legal decodifica a algún número de 256 bits y por tanto a alguna clave privada. Si esa clave controla un saldo es un problema de búsqueda bruta. Con ~10⁹ direcciones activas entre 2¹⁶⁰ posibles, la probabilidad es astronómicamente pequeña (~10⁻³⁹).

¿Qué librerías usa el conversor?

El conversor carga @noble/secp256k1 y @noble/hashes — ambas son librerías JS puras, sin dependencias, auditadas, de Paul Miller. Base58Check y Bech32 están implementados en línea en ~80 líneas.

¿Listo para ver tu clave como una posición?

Abrir el conversor interactivo

Bitcoin como tablero de ajedrez

Ve tu clave Bitcoin como una posición de ajedrez