Gap Limit

Anna utiliza una cartera, una aplicación o un dispositivo para recibir y enviar bitcoin. Generó por adelantado muchas direcciones de recepción, los datos necesarios para enviarle un pago, pero nunca utilizó algunas. Tras restaurar la cartera, le faltan pagos. Imaginemos una búsqueda con límite 20: la dirección de índice 0 tiene historial, los índices siguientes 1–20 no, y el índice 21 recibió un pago. El índice es simplemente la posición de la dirección en la secuencia; la numeración empieza en cero. El escaneo se detiene tras la serie vacía, antes del índice 21, y no encuentra ese pago. Si apareciera una dirección usada dentro de la serie examinada, el contador del intervalo volvería a empezar. Por tanto, el límite no significa que toda la cartera pueda tener como máximo veinte direcciones. [1] [6]

¿Qué significa sin uso en este caso? No significa que la dirección no tenga dinero ahora. Anna pudo recibir un pago y gastarlo entero después. El saldo queda en cero, pero el historial permanece y la dirección sigue contando como usada. Por eso BIP 44 trabaja con el historial, no solo con el saldo actual. Considerar nunca usada cualquier dirección vacía podría detener la recuperación demasiado pronto. Incluso un ingreso gastado hace mucho sirve para comprobar una cartera restaurada. [1]

BIP 44 es un estándar que describe la organización de cuentas y direcciones en una cartera jerárquica, que organiza claves y direcciones en un árbol con distintas ramas. Su regla Address gap limit fija una frontera de 20 para buscar en la rama externa de recepción, la secuencia de direcciones destinada a recibir pagos. El programa debe advertir al generar una dirección más allá. Es una convención de recuperación, no una regla de consenso que determine si la red acepta una transacción. Otras carteras pueden usar ajustes o procedimientos distintos. Tampoco recomienda reutilizar indefinidamente la misma dirección de recepción. [1]

La cartera original puede conocer direcciones generadas muy adelante en la secuencia. Al restaurar solo una copia de las claves, el nuevo programa quizá no sepa hasta dónde llegaste. Electrum lo advierte expresamente: las direcciones más allá de Gap Limit pueden no encontrarse automáticamente en una recuperación normal. Su documentación propone aumentar el límite o derivar más direcciones hasta alcanzar la posición usada. Los ajustes adecuados dependen del programa y del tipo de cartera. El valor predeterminado de 20 en la FAQ se refiere a Electrum 2.0; no es universal para todas las carteras actuales. [2]

Podemos imaginar la cartera como un árbol ordenado. Las cuentas separan grupos de fondos y cada cuenta puede contener distintas ramas de direcciones. En BIP 44, change=0 identifica la rama de recepción y change=1 la de cambio propio, la cantidad que queda para quien envía después de pagar. La búsqueda de cuentas empieza por la cuenta 0 y examina su rama externa. Si encuentra historial, pasa a la siguiente; la primera cuenta sin historial detiene el proceso. Por eso el estándar indica que no se cree una cuenta nueva si la anterior carece de historial. Un intervalo vacío en una rama y una cuenta vacía saltada son problemas distintos. Aumentar un límite no determina por sí solo qué otras cuentas examinará el programa. [1]

BIP 32 describe la derivación determinista de claves: los mismos datos iniciales y la misma ruta producen las mismas claves. Una Derivation Path es el recorrido por ese árbol; junto con el tipo de script, es decir, las reglas de gasto, determina qué direcciones sigue la cartera. La Seed Phrase correcta, las palabras de respaldo, es por tanto solo parte de la información necesaria. En BIP 39, una passphrase opcional también interviene en el cálculo de la semilla, el secreto inicial para derivar claves. La passphrase es un texto secreto adicional, distinto de la contraseña de la aplicación. Otra passphrase conduce a otra cartera; aumentar Gap Limit no la corrige. Una clave privada es un valor numérico secreto que la cartera utiliza para crear una firma digital que autoriza el gasto. Para profundizar, un xpub es una clave pública extendida que permite derivar otras claves públicas. Ayuda a seguir direcciones y pagos, pero por sí sola no autoriza el gasto. Por sí sola no puede atravesar un paso de derivación hardened, que requiere la clave privada del nivel superior. Buscar más lejos no aporta esa capacidad ausente. [4] [5] [6]

Bitcoin Core 29.0 ofrece importdescriptors mediante RPC, la interfaz de programación del nodo. Un descriptor describe cómo las claves forman condiciones de gasto y las direcciones que hay que vigilar. range define el rango de índices que se derivarán; no es una regla de parada ante un intervalo vacío. En un descriptor activo, next_index fija el siguiente índice para generar direcciones. timestamp determina desde cuándo buscar transacciones. El valor now está pensado para salidas que sabemos que nunca se han usado; no sustituye la recuperación de pagos antiguos. La documentación incluye también bloques hasta dos horas antes del timestamp más antiguo entre los descriptores importados y el Mempool, el conjunto local de transacciones sin confirmar. Así, incluso una dirección derivada correctamente puede faltar en el resumen si no se examinó el periodo correspondiente. [3]

Volvamos a Anna. Si conserva una dirección de recepción conocida o un registro de pago de la cartera original, puede comprobar si la nueva los encontró. Conviene comparar también los ingresos ya gastados, no solo el saldo final. Un escaneo más largo puede descubrir historial omitido, pero necesita tiempo y más consultas; si usa un servidor remoto, puede revelar a ese servidor más direcciones relacionadas. Buscar no transfiere fondos ni modifica la blockchain. Si el historial sigue sin coincidir, hay que verificar la copia de seguridad, la cuenta, la ruta, el tipo de dirección y la disponibilidad de datos históricos, en vez de limitarse a ampliar el límite. Encontrar una dirección no demuestra que toda la recuperación esté completa. [1] [2] [4]