Referencia para desarrolladores
Esta es la capa de referencia: los tipos de mensaje P2P, los opcodes (códigos de operación) de script, los nombres de campo RPC y las estructuras del protocolo con los que se encuentra al leer código de bitcoin o al decodificar una transacción en bruto, y no al comprar nada.
Existe porque el glosario para desarrolladores de Bitcoin Core, que es donde todavía se consulta la mayoría de estos términos, apenas ha cambiado desde 2021, y varias de sus entradas ya no describen el software. El protocolo de pago BIP70 que documenta se eliminó de Bitcoin Core en la versión 0.20.0. Sus entradas sobre filtros de Bloom describen un mecanismo que Core dejó de servir por defecto en la 0.19.0. Cada una de esas entradas se reconstruye aquí conforme a lo que hace hoy el código, con la corrección señalada y no aplicada en silencio.
Los términos se dividen en grupos. Los tipos de mensaje como inv, getdata y MSG_FILTERED_WITNESS_BLOCK pertenecen al protocolo entre pares. Los opcodes como OP_RETURN y OP_CHECKSIG pertenecen a Script. Los indicadores de hash de firma, los números de secuencia y el locktime rigen lo que una firma cubre en realidad. Las entradas sobre X509 y sobre solicitudes de pago son históricas, y así lo indican.
La mayoría de los lectores nunca necesitará esta sección, y no pasa nada. Está aquí para que una búsqueda de un nombre de campo exacto lleve a una página que lo explique con precisión y no a una entrada de una sola línea.
47 términos. Última revisión: 24 de septiembre de 2026.
Términos de la sección Referencia para desarrolladores
- Cadena de certificadosUna cadena de certificados es la lista ordenada de certificados que conecta el que presenta un servidor con un certificado raíz en el que su dispositivo ya confía, con cada eslabón firmado por el siguiente.
- Certificado de hojaEl certificado de hoja es el certificado de entidad final que presenta el servidor al que usted realmente se conectó, y demuestra el control de un nombre de dominio, nada sobre las personas que hay detrás.
- Certificado intermedioEl certificado intermedio se sitúa entre un certificado raíz, que lo firma, y un certificado de hoja, que él firma, para que la clave privada del certificado raíz pueda permanecer fuera de línea y sin usarse.
- Certificado raízUn certificado raíz es el ancla de confianza autofirmada que encabeza una cadena de certificados, y solo se confía en él porque el proveedor de su sistema operativo o navegador lo puso ahí.
- Certificado X.509también Certificados X509Un certificado X.509 es un archivo firmado que asocia una clave pública a un nombre y un período de validez, y es el formato que sustenta cada conexión HTTPS que usted establece con un exchange.
- Código QR de URIUn código QR de URI es el patrón cuadrado en blanco y negro que codifica un URI bitcoin:, para que una cámara lea la dirección y el monto que de otro modo se teclearían.
- CompactSizetambién Entero de longitud variable o VarIntCompactSize es el entero de longitud variable con el que bitcoin antepone recuentos y longitudes en los datos serializados, y cuesta un byte para valores inferiores a 253 y hasta nueve para el resto.
- EtiquetaLa etiqueta de un URI de Bitcoin nombra a la persona o al negocio que recibe el pago, y en una billetera es la nota privada que usted añade a una dirección o a una transacción.
- Firma SSLFirma SSL (SSL signature) es el nombre que BIP70 dio a los bytes que firman un mensaje PaymentRequest con la clave del certificado de un servidor web, y la denominación ya era impropia al escribirse.
- Función de puntoLa función de punto convierte una clave privada en una clave pública multiplicando el punto generador de secp256k1 por ese número, y es el paso unidireccional sobre el que se construye toda dirección de bitcoin.
- MSG_BLOCKMSG_BLOCK es el tipo de inventario 2, el código que un nodo pone en un mensaje getdata para solicitar a un par un bloque completo por su hash.
- MSG_CMPCT_BLOCKMSG_CMPCT_BLOCK, el tipo de inventario 4, es un código exclusivo de solicitudes: nunca aparece en un anuncio y solo es válido dentro de un mensaje getdata enviado a un par que lo aceptó antes.
- MSG_FILTERED_WITNESS_BLOCKEl tipo de bloque filtrado con testigo figura en la lista de tipos reservados de BIP144 y en el enum del código fuente de Bitcoin Core, sin ninguna implementación detrás en ninguno de los dos sitios.
- MSG_TXMSG_TX marca un elemento de inventario como transacción, con el código de tipo 1, y es la forma en que su pago sin confirmar se anuncia a los pares antes de que ninguno de ellos haya visto su contenido.
- MSG_WITNESS_BLOCKEl tipo de inventario de bloque con testigo es la forma en que un nodo compatible con SegWit solicita un bloque en la serialización extendida, con todas las firmas adjuntas en lugar de quitadas.
- MSG_WITNESS_TXUna solicitud de transacción con testigo, enviada como mensaje getdata, indica a un par que devuelva la transacción nombrada con sus datos de firma todavía incluidos en lugar de quitados.
- OP_CHECKMULTISIGOP_CHECKMULTISIG verifica un grupo de firmas frente a una lista de claves públicas en un solo paso, y los gastos Taproot no pueden usarlo en absoluto porque impide la verificación por lotes.
- OP_CHECKSIGOP_CHECKSIG desapila una clave pública y una firma, y verifica que la firma cubre esta transacción: es la verificación que realmente demuestra la propiedad de las monedas.
- OP_DUPOP_DUP copia el elemento de la cima de la pila para poder usarlo dos veces, y por eso el script estándar pay-to-public-key-hash puede tanto calcular el hash de su clave pública como usarla en la verificación.
- OP_EQUALOP_EQUAL compara byte a byte los dos elementos de la cima de la pila y apila un resultado verdadero o falso, y es el último opcode (código de operación) de toda salida pay-to-script-hash.
- OP_EQUALVERIFYOP_EQUALVERIFY compara los dos elementos de la cima de la pila y aborta el script al instante si difieren, y así es como un gasto heredado (legacy) demuestra que presentó la clave pública correcta.
- OP_HASH160OP_HASH160 aplica SHA-256 al elemento de la cima de la pila y luego RIPEMD-160 a ese resultado, y deja un hash de 20 bytes, la misma huella digital que lleva dentro toda dirección que empieza por 1 o por 3.
- OP_RETURNOP_RETURN es el opcode (código de operación) que hace que una salida de transacción sea demostrablemente imposible de gastar, lo que permite escribir en la blockchain una pequeña cantidad de datos arbitrarios sin inflar el conjunto de monedas vivas.
- OP_VERIFYOP_VERIFY desapila el elemento de la cima de la pila y aborta todo el script salvo que ese elemento sea verdadero, lo que convierte cualquier comprobación del Script de Bitcoin en un requisito ineludible.
- Opcodetambién Código de operación u Opcodes de BitcoinUn opcode (código de operación) es un único byte del Script de Bitcoin que indica a un nodo validador qué hacer a continuación, ya sea apilar datos o realizar una operación sobre lo que ya hay en la pila.
- Orden de bytes internoEl orden de bytes interno es la disposición que bitcoin usa dentro de las estructuras serializadas: los enteros se escriben con el byte menos significativo primero y los hash, en el orden en que SHA-256 los produjo.
- Orden de bytes RPCEl orden de bytes RPC es la forma invertida en que el software de bitcoin muestra los hash de 32 bytes, y la que tiene todo ID de transacción copiado de una billetera o un explorador de bloques.
- Parámetro rEl parámetro r es la adición de BIP72 a un URI de Bitcoin que reemplaza la dirección de pago por una URL de la que se espera que su billetera obtenga una solicitud firmada.
- PaymentDetailsPaymentDetails es el mensaje interno del BIP70 que describía realmente un pago: a qué salidas pagar, cuánto, cuándo expira la solicitud y adónde enviar la transacción firmada.
- PaymentRequestPaymentRequest es el sobre exterior del BIP70: envuelve una cadena de bytes con PaymentDetails serializado junto con una cadena de certificados y una firma, para que el pagador pudiera comprobar quién hacía la solicitud.
- PKItambién Infraestructura de clave públicaLa PKI, o infraestructura de clave pública, es el sistema de autoridades de certificación, certificados y almacenes de certificados que permite al software decidir si una clave pública pertenece realmente al nombre que lleva asociado.
- PP amountPP amount, el campo amount del protocolo de pago (BIP70), era el monto en satoshis de una salida y se dejaba en cero cuando el comerciante quería que el pagador eligiera cuánto enviar.
- PP expiresPP expires, el campo expires del protocolo de pago (BIP70), era una marca de tiempo Unix opcional del mensaje PaymentDetails que indicaba a la billetera que dejara de atender la solicitud una vez pasado ese momento.
- PP memoPP memo, el campo memo del protocolo de pago (BIP70), era una nota de texto libre en UTF-8 que un comerciante, un pagador o un servidor que acusaba recibo podían adjuntar a un pago para que la leyera una persona.
- PP merchant dataPP merchant data, el campo merchant_data del protocolo de pago (BIP70), era una cadena de bytes opaca que el comerciante incluía en una solicitud de pago y recuperaba intacta, para asociar las monedas entrantes a un pedido.
- PP pki dataPP pki data, el campo pki_data del protocolo de pago (BIP70), llevaba en una solicitud de pago los certificados del comerciante codificados en DER: el certificado de hoja primero, detrás los intermedios que hubiera y sin el certificado raíz.
- PP pki typePP pki type, el campo pki_type del protocolo de pago (BIP70), era la cadena de caracteres de una sola palabra que indicaba en una solicitud de pago cómo la había firmado el comerciante: none, x509 con SHA-256 o x509 con SHA-1.
- PP scriptPP script, el campo script del protocolo de pago (BIP70), era obligatorio en cada salida y contenía el script de bloqueo en bruto que el pagador debía reproducir, los mismos bytes que acaban en una salida de transacción.
- Protocolo de pago (BIP70)también Protocolo de pago o BIP70El protocolo de pago (BIP70) fue el intento de bitcoin de reemplazar las simples direcciones por solicitudes de pago firmadas y avaladas por certificados, y Bitcoin Core eliminó lo último que quedaba de su compatibilidad en la versión 0.20.0.
- ReciboUn recibo en bitcoin es cualquier prueba que usted conserve de que un pago se produjo: en BIP70 era un acuse de recibo firmado por el comerciante, y en la práctica es el ID de transacción.
- Script de Bitcointambién ScriptScript de Bitcoin es el pequeño lenguaje basado en pila que lleva cada salida de bitcoin y que establece las condiciones que alguien debe satisfacer antes de que esas monedas puedan volver a gastarse.
- Script de bloqueotambién scriptPubKey o Script de salidaEl script de bloqueo es el breve fragmento de Script de Bitcoin que acompaña a cada salida de transacción y establece las condiciones que deben cumplirse antes de que las monedas de esa salida puedan volver a moverse.
- Script de canjetambién redeemScriptUn script de canje es el contrato de gasto completo oculto tras una salida pay-to-script-hash, aportado por quien gasta al final del script de desbloqueo y cuyo hash se calcula para comprobar que coincide.
- Script de desbloqueotambién scriptSig o Script de entradaUn script de desbloqueo es el conjunto de datos de desbloqueo que lleva una entrada para satisfacer el script de bloqueo de la salida que gasta, y en las entradas SegWit modernas está vacío.
- Script de testigoEl script de testigo contiene las condiciones de gasto reales de una salida P2WSH y viaja en el testigo, donde sus bytes se cuentan a una cuarta parte del costo habitual.
- Suma de comprobación del descriptorLa suma de comprobación del descriptor es el código de ocho caracteres que sigue al signo # en un descriptor de salida, un código BCH que detecta errores de tecleo y de copia antes de que una billetera importe claves equivocadas.
- URI de Bitcointambién BIP21Un URI de Bitcoin reúne los datos de un pago en una cadena de caracteres sobre la que se puede hacer clic; empieza por bitcoin: y puede llevar una dirección, un monto y una etiqueta.
Las otras 13 secciones
- Conceptos básicosQué es bitcoin, qué es un satoshi y el puñado de ideas sobre las que se construye el resto del glosario.
- Direcciones y clavesAdónde se envían las monedas, qué controla realmente una clave privada y cómo una sola semilla produce miles de direcciones.
- Billeteras y custodiaBilleteras calientes, frías, con custodia y multisig, y qué cambia cada una en cuanto a quién puede mover sus monedas.
- Privacidad y seguridadLos ataques que le quitan el bitcoin a la gente, y los hábitos y las herramientas que los detienen.
- Transacciones y comisionesDe qué está hecha una transacción de bitcoin, por qué cuesta lo que cuesta y cómo desatascar una.
- Compra y exchangesTipos de orden, spreads y tablas de comisiones: el vocabulario que usa un exchange mientras le cobra.
- Mercados e inversiónCapitalización de mercado, volatilidad y ETF al contado. El lenguaje del precio, sin predicciones de precio.
- Minería y consensoCómo se crean los bloques nuevos, qué ajusta la dificultad y por qué las reglas se sostienen sin nadie al mando.
- Protocolo y actualizacionesSegWit, Taproot, bifurcaciones blandas (soft forks) y BIP: cómo cambia bitcoin y a quién le corresponde decidirlo.
- Lightning y capa 2Canales de pago, facturas y enrutamiento, para mover bitcoin sin pagar por espacio en un bloque.
- Regulación e impuestosKYC, la Travel Rule, MiCA y las ganancias de capital: las reglas que llegan hasta su cuenta y su declaración de impuestos.
- Cultura e historiaMt. Gox, el bloque génesis, HODL, y los acontecimientos y la jerga que moldearon la manera de hablar de bitcoin.
- Nodos y softwareBitcoin Core, nodos completos, poda y RPC: el software que hace cumplir las reglas.
Preguntas frecuentes
¿Para quién es esta sección?
Para cualquiera que lea el código fuente de bitcoin, decodifique una transacción en bruto o trabaje con el protocolo P2P y la interfaz RPC. Es la capa de referencia y no la de compra, y nada de ella hace falta para poseer o gastar bitcoin.
¿Qué es Script de Bitcoin?
El pequeño lenguaje basado en pila que decide si una moneda se puede gastar. No tiene bucles, a propósito, lo que hace predecible el costo de cada script antes de que se ejecute. La mayoría de las transacciones usan uno de un puñado de patrones estándar.
¿Por qué el orden de los bytes no deja de cambiar?
Porque bitcoin muestra los hash en el orden inverso a aquel en que los almacena. El orden de bytes interno es el que usa el protocolo, mientras que las respuestas RPC y los exploradores de bloques lo invierten. Mezclar los dos es el clásico primer error.
¿Dónde está la documentación de referencia?
En el código fuente y en los BIP, y no en un único sitio web. Las entradas de esta sección citan la especificación cuando la hay, y corrigen la documentación para desarrolladores más antigua allí donde se ha quedado desactualizada, en lugar de repetirla.