Esta página describe el protocolo de red de Bitcoin utilizado por los nodos que ejecutan el cliente de nodo de BitcoinSV para comunicar transacciones y bloquear información en la red de BitcoinSV. Este es un medio estándar actual para que los nodos comuniquen información sobre el libro mayor entre ellos, incluidas transacciones válidas, mensajes de descubrimiento de bloques y más.

Para el protocolo utilizado en minería, vea la interfaz GetBlockTemplate .

Estructura del mensaje

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	magia	uint32_t	Valor mágico que indica la red de origen del mensaje, y se utiliza para buscar el siguiente mensaje cuando se desconoce el estado del flujo
12	mando	char [12]	Cadena ASCII que identifica el contenido del paquete, relleno NULL (el relleno no NULL da como resultado un paquete rechazado)
4 4	longitud	uint32_t	Longitud de la carga útil en número de bytes
4 4	suma de comprobación	uint32_t	Primeros 4 bytes de sha256 (sha256 (carga útil))
?	carga útil	uchar []	Los datos reales

Valores mágicos conocidos:

Red	Valor mágico	Enviado por cable como
mainnet	0xE8F3E1E3	E3 E1 F3 E8
Testnet 3	0xF4F3E5F4	F4 E5 F3 F4
testnet de escala	0xF9C4CEFB	FB CE C4 F9
regtest	0xFABFB5DA	DA B5 BF FA

Entero de longitud variable

El entero se puede codificar según el valor representado para ahorrar espacio. Los enteros de longitud variable siempre preceden a una matriz / vector de un tipo de datos que puede variar en longitud. Los números más largos están codificados en little endian.

Valor	Longitud de almacenamiento	Formato
<0xFD	1	uint8_t
<= 0xFFFF	3	0xFD seguido de la longitud como uint16_t
<= 0xFFFF FFFF	5 5	0xFE seguido de la longitud como uint32_t
–	9 9	0xFF seguido de la longitud como uint64_t

Si está leyendo el código del cliente Satoshi (BitcoinQT), se refiere a esta codificación como «CompactSize». El BitcoinQT moderno también tiene la clase CVarInt que implementa un número entero aún más compacto para el almacenamiento local (que es incompatible con «CompactSize» descrito aquí). CVarInt no es parte del protocolo.

Cadena de longitud variable

La cadena de longitud variable se puede almacenar usando un entero de longitud variable seguido de la cadena misma.

Tamaño del campo	Descripción	Tipo de datos	Comentarios
1+	longitud	var_int	Longitud de la cuerda
?	cuerda	carbonizarse[]	La cadena en sí (puede estar vacía)

Dirección de red

Cuando se necesita una dirección de red en alguna parte, se utiliza esta estructura. Las direcciones de red no tienen como prefijo una marca de tiempo en el mensaje de versión.

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	hora	uint32	El tiempo (versión> = 31402). No presente en el mensaje de versión.
8	servicios	uint64_t	los mismos servicios enumerados en la versión
dieciséis	IPv6 / 4	char [16]	Dirección IPv6 Orden de bytes de red. El cliente original solo admitía IPv4 y solo leía los últimos 4 bytes para obtener la dirección IPv4. Sin embargo, la dirección IPv4 se escribe en el mensaje como una dirección IPv6 mapeada por IPv4 de 16 bytes(12 bytes 00 00 00 00 00 00 00 00 00 00 FF FF , seguido de los 4 bytes de la dirección IPv4).
2	Puerto	uint16_t	número de puerto, orden de bytes de red

Ejemplo Hexdump de estructura de direcciones de red

  0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0010 00 00 FF FF 0A 00 00 01 20 8D .........

 Dirección de red:
  01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: ver los servicios enumerados bajo el comando de versión)
  00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: :: ffff: a00: 1 o IPv4: 10.0.0.1
  20 8D - Puerto 8333

Vectores de inventario

Los vectores de inventario se utilizan para notificar a otros nodos sobre los objetos que tienen o los datos que se solicitan.

Los vectores de inventario constan del siguiente formato de datos:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	tipo	uint32_t	Identifica el tipo de objeto vinculado a este inventario.
32	picadillo	char [32]	Hash del objeto

El tipo de objeto se define actualmente como una de las siguientes posibilidades:

Valor	Nombre	Descripción
0 0	ERROR	Cualquier dato de con este número puede ser ignorado
1	MSG_TX	Hash está relacionado con una transacción
2	MSG_BLOCK	El hash está relacionado con un bloque de datos
3	MSG_FILSTEM_BLOCK	Hash de un encabezado de bloque; idéntico a MSG_BLOCK. Solo para ser utilizado en mensajes getdata. Indica que la respuesta debe ser un mensaje merkleblock en lugar de un mensaje bloqueado; esto solo funciona si se ha establecido un filtro de floración.
4 4	MSG_CMPCT_BLOCK	Hash de un encabezado de bloque; idéntico a MSG_BLOCK. Solo para ser utilizado en mensajes getdata. Indica que la respuesta debe ser un mensaje de cmpctblock. Ver BIP 152 para más información.

Otros valores de tipo de datos se consideran reservados para futuras implementaciones.

Encabezados de bloque

Los encabezados de bloque se envían en un paquete de encabezados en respuesta a un mensaje getheaders.

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	versión	int32_t	Información de versión de bloque (nota, esto está firmado)
32	prev_block	char [32]	El valor hash del bloque anterior al que hace referencia este bloque en particular
32	raíz de merkle	char [32]	La referencia a una colección de árbol de Merkle que es un hash de todas las transacciones relacionadas con este bloque
4 4	marca de tiempo	uint32_t	Una grabación de marca de tiempo cuando se creó este bloque (se desbordará en 2106 <ref> https://en.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time </ref>)
4 4	pedacitos	uint32_t	El objetivo de dificultad calculado que se usa para este bloque
4 4	mientras tanto	uint32_t	El nonce utilizado para generar este bloque … para permitir variaciones del encabezado y calcular diferentes hashes
1+	txn_count	var_int	Número de entradas de transacción, este valor siempre es 0

cf. Algoritmo de hash de bloque

Codificación diferencial

Varios usos de CompactSize a continuación están «codificados diferencialmente». Para estos, en lugar de usar índices sin procesar, el número codificado es la diferencia entre el índice actual y el índice anterior, menos uno. Por ejemplo, un primer índice de 0 implica un índice real de 0, un segundo índice de 0 en adelante se refiere a un índice real de 1, etc.

Transacción prellenada

Se usa una estructura PrefilledTransaction en HeaderAndShortIDs para proporcionar una lista de algunas transacciones explícitamente.

Nombre del campo	Tipo	Talla	Codificación	Propósito
índice	Tamaño compacto	1, 3 bytes	Tamaño compacto, codificado diferencialmente desde la última transacción prellenada en una lista	El índice en el bloque en el que se encuentra esta transacción
tx	Transacción	variable	Como codificado en mensajes tx	La transacción que está en el bloque en el índice índice.

Ver BIP 152 para más información.

HeaderAndShortIDs

Se utiliza una estructura HeaderAndShortIDs para retransmitir un encabezado de bloque, las ID de transacciones cortas que se utilizan para hacer coincidir las transacciones ya disponibles y algunas selectas transacciones que esperamos que falte un par.

Nombre del campo	Tipo	Talla	Codificación	Propósito
encabezamiento	Encabezado de bloque	80 bytes	Los primeros 80 bytes del bloque, según lo definido por la codificación utilizada por los mensajes de «bloque»	El encabezado del bloque que se proporciona
mientras tanto	uint64_t	8 bytes	Little Endian	Un nonce para usar en cálculos de ID de transacciones cortas
shortids_length	Tamaño compacto	1 o 3 bytes	Como se usa para codificar longitudes de matriz en otros lugares	El número de ID de transacciones cortas en shortids (es decir, bloque tx count – prefilledtxn_length)
shortids	Lista de enteros de 6 bytes	6 * bytes shortids_length	Little Endian	Las ID de transacciones cortas calculadas a partir de las transacciones que no se proporcionaron explícitamente en prefilledtxn
prellenadotxn_length	Tamaño compacto	1 o 3 bytes	Como se usa para codificar longitudes de matriz en otros lugares	El número de transacciones prellenadas en prellenadotxn (es decir, conteo de tx de bloque – shortids_length)
prellenadotxn	Lista de transacciones prellenadas	tamaño variable * prellenadotxn_length	Según lo definido por la definición de PrefilledTransaction , arriba	Se usa para proporcionar la transacción de coinbase y algunos selectos que esperamos que falte un par

Ver BIP 152 para más información.

BlockTransactionsRequest

Se utiliza una estructura BlockTransactionsRequest para enumerar los índices de transacción en un bloque que se solicita.

Nombre del campo	Tipo	Talla	Codificación	Propósito
blockhash	Gota binaria	32 bytes	La salida de un SHA256 doble del encabezado del bloque, como se usa en otro lugar	El blockhash del bloque en el que se encuentran las transacciones solicitadas
longitud_índices	Tamaño compacto	1 o 3 bytes	Como se usa para codificar longitudes de matriz en otros lugares	El número de transacciones que se solicitan.
índices	Lista de tamaños compactos	1 o 3 bytes * longitud_índice	Codificado diferencialmente	Los índices de las transacciones que se solicitan en el bloque.

Ver BIP 152 para más información.

BlockTransactions

Una estructura BlockTransactions se utiliza para proporcionar algunas de las transacciones en un bloque, según lo solicitado.

Nombre del campo	Tipo	Talla	Codificación	Propósito
blockhash	Gota binaria	32 bytes	La salida de un SHA256 doble del encabezado del bloque, como se usa en otro lugar	El blockhash del bloque en el que se encuentran las transacciones que se proporcionan
longitud_de_transacciones	Tamaño compacto	1 o 3 bytes	Como se usa para codificar longitudes de matriz en otros lugares	El número de transacciones proporcionadas
actas	Listado de transacciones	variable	Como codificado en mensajes tx	Las transacciones proporcionadas

Ver BIP 152 para más información.

ID de transacción corta

Las ID de transacciones cortas se utilizan para representar una transacción sin enviar un hash completo de 256 bits. Se calculan por:

1. Single-SHA256 hashing el encabezado del bloque con el nonce agregado (en little-endian)
2. Ejecutando SipHash-2-4 con la entrada que es la ID de transacción y las claves (k0 / k1) establecidas en los primeros dos enteros little-endian de 64 bits del hash anterior, respectivamente.
3. Descartar los 2 bytes más significativos de la salida SipHash para que sea de 6 bytes.

Ver BIP 152 para más información.

Tipos de mensajes

versión

Cuando un nodo crea una conexión saliente, anunciará inmediatamente su versión. El nodo remoto responderá con su versión. No es posible más comunicación hasta que ambos pares hayan intercambiado su versión.

Carga útil:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	versión	int32_t	Identifica la versión del protocolo que utiliza el nodo
8	servicios	uint64_t	campo de bits de características que se habilitarán para esta conexión
8	marca de tiempo	int64_t	marca de tiempo estándar de UNIX en segundos
26	addr_recv	net_addr	La dirección de red del nodo que recibe este mensaje
Los campos a continuación requieren la versión ≥ 106
26	addr_from	net_addr	La dirección de red del nodo que emite este mensaje.
8	mientras tanto	uint64_t	Nodo aleatorio nonce, generado aleatoriamente cada vez que se envía un paquete de versión. Este nonce se utiliza para detectar conexiones a uno mismo.
?	agente de usuario	var_str	Agente de usuario (0x00 si la cadena tiene 0 bytes de longitud)
4 4	altura_inicial	int32_t	El último bloque recibido por el nodo emisor
Los siguientes campos requieren la versión ≥ 70001
1	relé	bool	Si el par remoto debe anunciar transacciones retransmitidas o no, consulte BIP 0037

Se enviará un paquete «verack» si se aceptó el paquete de versión.

Actualmente se asignan los siguientes servicios:

Valor	Nombre	Descripción
1	NODE_NETWORK	Este nodo puede solicitar bloques completos en lugar de solo encabezados.
2	NODE_GETUTXO	Ver BIP 0064
4 4	NODE_BLOOM	Ver BIP 0111.
1024	NODE_NETWORK_LIMITED	Ver BIP 0159.

Ejemplo de mensaje de versión de Hexdump (EJEMPLO OBSOLETO: Este ejemplo carece de suma de comprobación y agente de usuario):

  0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 .... versión .....
 0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U .... | ..........
 0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ... M ............
 0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
 0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ...,
 0060 3A B4 57 13 00 55 81 01 00: .W..U ...

 Encabezado del mensaje:
  F9 BE B4 D9: bytes mágicos de la red principal
  76 65 72 73 69 6F 6E 00 00 00 00 00 - comando "versión"
  55 00 00 00 - La carga útil tiene una longitud de 85 bytes
                                                                                - No hay suma de verificación en el mensaje de versión hasta el 20 de febrero de 2012. Ver https://bitcointalk.org/index.php?topic=55852.0
 Mensaje de versión:
  9C 7C 00 00 - 31900 (versión 0.3.19)
  01 00 00 00 00 00 00 00 - 1 (servicios NODE_NETWORK)
  E6 15 10 4D 00 00 00 00 - Lun 20 Dic 21:50:14 EST 2010
  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Información de la dirección del destinatario - ver Dirección de red
  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Información de la dirección del remitente - ver Dirección de red
  DD 9D 20 2C 3A B4 57 13 - ID único aleatorio de nodo
  00 - cadena de subversión "" (la cadena tiene una longitud de 0 bytes)
  55 81 01 00 - El último nodo de envío de bloque tiene el bloque # 98645

Y aquí hay un cliente de versión de protocolo moderno (60002) que se anuncia a un par local …

El protocolo más nuevo incluye la suma de comprobación ahora, esto es de un cliente de línea principal (satoshi) durante una conexión saliente a otro cliente local, tenga en cuenta que no completa la información de la dirección cuando el origen o el destino es «no enrutable».

 0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 .... versión .....
 0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d ... 5.I2b .......
 0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 ....... P ........
 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
 0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68; ..] ... e./Satosh
 0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i: 0.7.2 /.> ..

 Encabezado de mensaje:
  F9 BE B4 D9: bytes mágicos de la red principal
  76 65 72 73 69 6F 6E 00 00 00 00 00 - comando "versión"
  64 00 00 00 - La carga útil tiene una longitud de 100 bytes
  35 8d 49 32 - suma de comprobación de la carga útil (little endian)

 Mensaje de versión:
  62 EA 00 00 - 60002 (versión del protocolo 60002)
  01 00 00 00 00 00 00 00 - 1 (servicios NODE_NETWORK)
  11 B2 D0 50 00 00 00 00 - Martes 18 de diciembre 10:12:33 PST 2012
  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Información de la dirección del destinatario - ver Dirección de red
  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Información de la dirección del remitente - ver Dirección de red
  3B 2E B3 5D 8C E6 17 65 - ID de nodo
  0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - Cadena de subversión "/Satoshi:0.7.2/" (la cadena tiene 15 bytes de longitud)
  C0 3E 03 00 - El último nodo de envío de bloque tiene es el bloque # 212672

verack

El mensaje verack se envía en respuesta a la versión . Este mensaje consiste solo en un encabezado de mensaje con la cadena de comando «verack».

Hexdump del mensaje verack:

  0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 .... verack ......
 0010 00 00 00 00 5D F6 E0 E2 ........

 Encabezado del mensaje:
  F9 BE B4 D9: bytes mágicos de la red principal
  76 65 72 61 63 6B 00 00 00 00 00 00 - comando "verack"
  00 00 00 00 - La carga útil tiene una longitud de 0 bytes
  5D F6 E0 E2 - Suma de comprobación (little endian)

addr

Proporcionar información sobre nodos conocidos de la red. Los nodos no anunciados deben olvidarse después de típicamente 3 horas

Carga útil:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
1+	contar	var_int	Número de entradas de dirección (máx .: 1000)
30x?	addr_list	(uint32_t + net_addr ) []	Dirección de otros nodos en la red. la versión <209 solo leerá la primera. El uint32_t es una marca de tiempo (vea la nota a continuación).

Nota : a partir de la versión 31402, las direcciones tienen como prefijo una marca de tiempo. Si no hay una marca de tiempo presente, las direcciones no deben transmitirse a otros pares, a menos que se confirme que están activas.

Ejemplo hexdump de mensaje addr :

  0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 .... addr ........
 0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 ..... R9 ..... M ...
 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
 0030 FF 0A 00 00 01 20 8D ......

 Encabezado de mensaje:
  F9 BE B4 D9: bytes mágicos de la red principal
  61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
  1F 00 00 00 - la carga útil tiene 31 bytes de longitud
  ED 52 39 9B - suma de comprobación de carga útil (little endian)

 Carga útil:
  01 - 1 dirección en este mensaje

 Habla a:
  E2 15 10 4D - Lun 20 dic 21:50:10 EST 2010 (solo cuando la versión es> = 31402)
  01 00 00 00 00 00 00 00 - 1 (servicio NODE_NETWORK - ver mensaje de versión)
  00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: :: ffff: 10.0.0.1 (dirección IPv6 asignada a IPv4)
  20 8D - puerto 8333

inv

Permite que un nodo anuncie su conocimiento de uno o más objetos. Se puede recibir no solicitado o en respuesta a getblocks .

Carga útil (máximo 50,000 entradas, que es un poco más de 1.8 megabytes):

Tamaño del campo	Descripción	Tipo de datos	Comentarios
1+	contar	var_int	Número de entradas de inventario
36x?	inventario	inv_vect []	Vectores de inventario

obtener datos

getdata se usa en respuesta a inv, para recuperar el contenido de un objeto específico, y generalmente se envía después de recibir un paquete de inv , después de filtrar elementos conocidos. Se puede usar para recuperar transacciones, pero solo si están en el grupo de memoria o en el conjunto de retransmisión: no se permite el acceso arbitrario a las transacciones en la cadena para evitar que los clientes comiencen a depender de nodos que tengan índices de transacción completos (que los nodos modernos no tienen )

Carga útil (máximo 50,000 entradas, que es un poco más de 1.8 megabytes):

Tamaño del campo	Descripción	Tipo de datos	Comentarios
1+	contar	var_int	Número de entradas de inventario
36x?	inventario	inv_vect []	Vectores de inventario

extraviado

notfound es una respuesta a un getdata, que se envía si alguno de los elementos de datos solicitados no se puede retransmitir, por ejemplo, porque la transacción solicitada no estaba en el grupo de memoria o en el conjunto de retransmisión.

Tamaño del campo	Descripción	Tipo de datos	Comentarios
1+	contar	var_int	Número de entradas de inventario
36x?	inventario	inv_vect []	Vectores de inventario

bloqueos

Devuelve un paquete de inv que contiene la lista de bloques que comienza justo después del último hash conocido en el objeto localizador de bloques, hasta hash_stop o 500 bloques, lo que ocurra primero.

Los hashes del localizador son procesados ​​por un nodo en el orden en que aparecen en el mensaje. Si se encuentra un hash de bloque en la cadena principal del nodo, la lista de sus hijos se devuelve a través del mensaje inv y los localizadores restantes se ignoran, sin importar si se alcanzó el límite solicitado o no.

Para recibir los siguientes hashes de bloques, uno debe emitir getblocks nuevamente con un nuevo objeto localizador de bloques. Tenga en cuenta que algunos clientes pueden proporcionar bloques que no son válidos si el objeto localizador de bloques contiene un hash en la rama no válida.

Carga útil:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	versión	uint32_t	la versión del protocolo
1+	cuenta de hash	var_int	Número de entradas hash del localizador de bloques
32+	hashes del localizador de bloques	char [32]	objeto localizador de bloques; el más nuevo de vuelta al bloque de génesis (denso para comenzar, pero luego escaso)
32	hash_stop	char [32]	hash del último bloque deseado; puesto a cero para obtener tantos bloques como sea posible (500)

Para crear los hash del localizador de bloques, siga presionando los hashes hasta que vuelva al bloque de génesis. Después de retroceder 10 hashes, el paso hacia atrás duplica cada ciclo:

 // Desde libbitcoin que está bajo AGPL std :: vector <size_t> block_locator_indexes (size_t top_height) {std :: vector <size_t> indexes;  // Modificar el paso en la iteración.  int64_t paso = 1;  // Comienza en la parte superior de la cadena y trabaja hacia atrás.  for (auto index = (int64_t) top_height; index> 0; index - = step) {// Empuje primero los 10 índices principales y luego retroceda exponencialmente.  if (indexes.size ()> = 10) paso * = 2;  indexes.push_back ((size_t) index);  } // Empuje el índice de bloque de génesis.  indexes.push_back (0);  índices de retorno;  }

Tenga en cuenta que está permitido enviar menos hashes conocidos a un mínimo de solo un hash. Sin embargo, el propósito del objeto localizador de bloques es detectar una rama incorrecta en la cadena principal del llamante. Si el par detecta que estás fuera de la cadena principal, enviará hashes de bloque que son anteriores a tu último bloque conocido. Entonces, si solo envía su último hash conocido y está fuera de la cadena principal, el par comienza de nuevo en el bloque # 1.

getheaders

Devuelve un paquete de encabezados que contiene los encabezados de los bloques que comienzan justo después del último hash conocido en el objeto localizador de bloques, hasta hash_stop o 2000 bloques, lo que ocurra primero. Para recibir los siguientes encabezados de bloque, es necesario emitir getheaders nuevamente con un nuevo objeto localizador de bloques. Tenga en cuenta que algunos clientes pueden proporcionar encabezados de bloques que no son válidos si el objeto localizador de bloques contiene un hash en la rama no válida.

Carga útil:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	versión	uint32_t	la versión del protocolo
1+	cuenta de hash	var_int	Número de entradas hash del localizador de bloques
32+	hashes del localizador de bloques	char [32]	objeto localizador de bloques; el más nuevo de vuelta al bloque de génesis (denso para comenzar, pero luego escaso)
32	hash_stop	char [32]	hash del último encabezado de bloque deseado; establecido en cero para obtener tantos bloques como sea posible (2000)

Para el objeto localizador de bloques en este paquete, se aplican las mismas reglas que para el paquete getblocks .

tx

tx describe una transacción de bitcoin, en respuesta a getdata . Cuando se aplica un filtro de floración, los objetos tx se envían automáticamente para las transacciones coincidentes que siguen al merkleblock .

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	versión	int32_t	Versión del formato de datos de la transacción (nota, esto está firmado)
1+	tx_in count	var_int	Número de entradas de transacción (nunca cero)
41+	tx_in	tx_in []	Una lista de 1 o más entradas de transacciones o fuentes para monedas
1+	tx_out count	var_int	Número de salidas de transacciones
9+	tx_out	tx_out []	Una lista de 1 o más salidas de transacciones o destinos para monedas
4 4	lock_time	uint32_t	El número de bloque o la marca de tiempo en la que se desbloquea esta transacción: Valor Descripción 0 0 No está bloqueado <500000000 Número de bloque en el que se desbloquea esta transacción > = 500000000 Marca de tiempo UNIX en la que se desbloquea esta transacción Si todas las entradas TxIn tienen números de secuencia finales (0xffffffff), entonces lock_time es irrelevante. De lo contrario, la transacción no se puede agregar a un bloque hasta después de lock_time (ver NLockTime ).

TxIn consta de los siguientes campos:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
36	salida_anterior	superar	La referencia de transacción de salida anterior, como una estructura OutPoint
1+	longitud del guión	var_int	La longitud del script de firma
?	script de firma	uchar []	Script computacional para confirmar la autorización de transacción
4 4	secuencia	uint32_t	Versión de transacción definida por el remitente. Destinado a «reemplazo» de transacciones cuando la información se actualiza antes de incluirla en un bloque.

La estructura OutPoint consta de los siguientes campos:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
32	picadillo	char [32]	El hash de la transacción referenciada.
4 4	índice	uint32_t	El índice de la salida específica en la transacción. La primera salida es 0, etc.

La estructura del script consta de una serie de piezas de información y operaciones relacionadas con el valor de la transacción.

(La estructura se ampliará en el futuro … ver script.h y script.cpp y Script para más información)

La estructura TxOut consta de los siguientes campos:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
8	valor	int64_t	Valor de la transacción
1+	longitud de pk_script	var_int	Longitud del pk_script
?	pk_script	uchar []	Contiene las condiciones de configuración de ScriptPubKey para reclamar esta salida.

Mensaje tx de ejemplo:

  000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 .... tx ..........
 000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB ............. m ..
 000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9. [... Q ........ f.
 000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00.; P ...... j.6) ...
 000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.! .. X..r ...
 000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%; .. R # ... h .:
 000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y #? EW .. Y .....
 000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .AzXz..XN ...
 000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5 ... 6 ..; ... A ....
 000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@.. ...
 0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *. + ..].} S ... ...
 0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F NS. = 7.o ... Q ...
 0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../ FaJLp..K .....
 0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
 0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB ..... Ez .......
 0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^ ........... v ..
 000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 .. [. Cj ..... H ^ ...
 000110 8B 4E CC 52 88 AC 00 00 00 00 .NR .....


 Encabezado del mensaje:
  F9 BE B4 D9 - bytes mágicos de la red principal
  74 78 00 00 00 00 00 00 00 00 00 00 - comando "tx"
  02 01 00 00 - la carga útil tiene una longitud de 258 bytes
  E2 93 CD BE - suma de comprobación de carga útil (little endian)

 Transacción:
  01 00 00 00 - versión

 Entradas:
  01 - número de entradas de transacciones

 Entrada 1:
  6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - salida anterior (punto de salida)
  12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
  00 00 00 00

  8B - el script tiene 139 bytes de longitud

  48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - script de firma (scriptSig)
  7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
  3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
  83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
  96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
  F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
  2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
  53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
  2F 46 61 4A 4C 70 C0 F1 4B EF F5

  FF FF FF FF - secuencia

 Salidas:
  02-2 Transacciones de salida

 Salida 1:
  40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
  19 - pk_script tiene 25 bytes de longitud

  76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
  A9 D9 EA 1A FB 22 5E 88 AC

 Salida 2:
  80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
  19 - pk_script tiene 25 bytes de longitud

  76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
  FD A0 B7 8B 4E CC 52 88 AC

 Tiempo de bloqueo:
  00 00 00 00 - tiempo de bloqueo

bloquear

El mensaje de bloque se envía en respuesta a un mensaje getdata que solicita información de transacción de un hash de bloque.

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	versión	int32_t	Información de versión de bloque (nota, esto está firmado)
32	prev_block	char [32]	El valor hash del bloque anterior al que hace referencia este bloque en particular
32	raíz de merkle	char [32]	La referencia a una colección de árbol de Merkle que es un hash de todas las transacciones relacionadas con este bloque
4 4	marca de tiempo	uint32_t	Una grabación de marca de tiempo de Unix cuando se creó este bloque (¡Actualmente limitado a fechas anteriores al año 2106!)
4 4	pedacitos	uint32_t	El objetivo de dificultad calculado que se usa para este bloque
4 4	mientras tanto	uint32_t	El nonce utilizado para generar este bloque … para permitir variaciones del encabezado y calcular diferentes hashes
1+	txn_count	var_int	Número de entradas de transacciones
?	txns	tx []	Bloquear transacciones, en formato de comando «tx»

El hash SHA256 que identifica cada bloque (y que debe tener una ejecución de 0 bits) se calcula a partir de los primeros 6 campos de esta estructura (versión, prev_block, merkle_root, timestamp, bits, nonce y el relleno SHA256 estándar, haciendo dos 64- trozos de bytes en total) y no del bloque completo. Para calcular el hash, el algoritmo SHA256 solo debe procesar dos fragmentos. Dado que el campo nonce está en el segundo fragmento, el primer fragmento permanece constante durante la extracción y, por lo tanto, solo debe procesarse el segundo fragmento. Sin embargo, un hash de Bitcoin es el hash del hash, por lo que se necesitan dos rondas SHA256 para cada iteración de minería. Consulte Algoritmo de hash de bloque para obtener detalles y un ejemplo.

encabezados

El paquete de encabezados devuelve encabezados de bloque en respuesta a un paquete getheaders .

Carga útil:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
1+	contar	var_int	Número de encabezados de bloque
81x?	encabezados	block_header []	Bloquear encabezados

Tenga en cuenta que los encabezados de bloque en este paquete incluyen un recuento de transacciones (un var_int, por lo que puede haber más de 81 bytes por encabezado) en lugar de los encabezados de bloque que los mineros hacen hash.

getaddr

El mensaje getaddr envía una solicitud a un nodo solicitando información sobre pares activos conocidos para ayudar a encontrar nodos potenciales en la red. La respuesta a la recepción de este mensaje es transmitir uno o más mensajes adicionales con uno o más pares desde una base de datos de pares activos conocidos. La presunción típica es que es probable que un nodo esté activo si ha estado enviando un mensaje en las últimas tres horas.

No se transmiten datos adicionales con este mensaje.

mempool

El mensaje mempool envía una solicitud a un nodo solicitando información sobre las transacciones que ha verificado pero que aún no ha confirmado. La respuesta a la recepción de este mensaje es un mensaje de invitación que contiene los hashes de transacción para todas las transacciones en el mempool del nodo.

No se transmiten datos adicionales con este mensaje.

Se especifica en BIP 35 . Desde BIP 37 , si se carga un filtro de floración , solo se responden las transacciones que coinciden con el filtro.

revisar orden

Este mensaje se usó para transacciones IP . Como las transacciones IP han quedado en desuso, ya no se utilizan.

orden de envio

Este mensaje se usó para transacciones IP . Como las transacciones IP han quedado en desuso, ya no se utilizan.

respuesta

Este mensaje se usó para transacciones IP . Como las transacciones IP han quedado en desuso, ya no se utilizan.

silbido

El mensaje de ping se envía principalmente para confirmar que la conexión TCP / IP sigue siendo válida. Se supone que un error en la transmisión es una conexión cerrada y la dirección se elimina como un par actual.

Carga útil:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
8	mientras tanto	uint64_t	nonce aleatorio

apestar

El mensaje pong se envía en respuesta a un mensaje ping . En las versiones de protocolo modernas, se genera una respuesta pong utilizando un nonce incluido en el ping.

Carga útil:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
8	mientras tanto	uint64_t	nonce de ping

rechazar

El mensaje de rechazo se envía cuando se rechazan los mensajes.

Carga útil:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
1+	mensaje	var_str	tipo de mensaje rechazado
1	ccode	carbonizarse	código relacionado con el mensaje rechazado
1+	razón	var_str	versión de texto del motivo del rechazo
0+	datos	carbonizarse	Datos adicionales opcionales proporcionados por algunos errores. Actualmente, todos los errores que proporcionan este campo lo llenan con el TXID o el hash de encabezado de bloque del objeto rechazado, por lo que el campo es de 32 bytes.

CCodes

Valor	Nombre	Descripción
0x01	RECHAZAR_MALFORMADO
0x10	RECHAZAR_INVÁLIDO
0x11	RECHAZAR_OBSOLETE
0x12	RECHAZAR_DUPLICAR
0x40	RECHAZAR_NO ESTÁNDAR
0x41	REJECT_DUST
0x42	REJECT_INSUFFICIENTFEE
0x43	REJECT_CHECKPOINT

filterload, filteradd, filterclear, merkleblock

Estos mensajes están relacionados con el filtrado de conexiones de Bloom y se definen en BIP 0037 .

El comando filterload se define de la siguiente manera:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
?	filtrar	uint8_t []	El filtro en sí mismo es simplemente un campo de bits de tamaño arbitrario alineado con bytes. El tamaño máximo es de 36,000 bytes.
4 4	nHashFuncs	uint32_t	El número de funciones hash para usar en este filtro. El valor máximo permitido en este campo es 50.
4 4	nDebil	uint32_t	Un valor aleatorio para agregar al valor semilla en la función hash utilizada por el filtro de floración.
1	nBanderas	uint8_t	Un conjunto de indicadores que controlan cómo se agregan los elementos coincidentes al filtro.

Consulte a continuación una descripción del algoritmo de filtro Bloom y cómo seleccionar nHashFuncs y el tamaño del filtro para obtener una tasa de falsos positivos deseada.

Al recibir un comando filterload , el par remoto restringirá inmediatamente las transacciones de difusión que anuncia (en paquetes inv) a transacciones que coincidan con el filtro, donde el algoritmo de coincidencia se especifica a continuación. Las banderas controlan el comportamiento de actualización del algoritmo de coincidencia.

El comando filteradd se define de la siguiente manera:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
?	datos	uint8_t []	El elemento de datos para agregar al filtro actual.

El campo de datos debe ser menor o igual a 520 bytes de tamaño (el tamaño máximo de cualquier objeto potencialmente coincidente).

El elemento de datos dado se agregará al filtro Bloom. Un filtro debe haber sido provisto previamente usando filterload . Este comando es útil si se agrega una nueva clave o script a la billetera de un cliente mientras tiene conexiones a la red abiertas, evita la necesidad de volver a calcular y enviar un filtro completamente nuevo a cada par (aunque hacerlo es generalmente recomendable mantener el anonimato).

El comando filterclear no tiene argumentos en absoluto.

Después de establecer un filtro, los nodos no solo dejan de anunciar transacciones que no coinciden, sino que también pueden servir bloques filtrados. Un bloque filtrado se define por el mensaje merkleblock y se define así:

Tamaño del campo	Descripción	Tipo de datos	Comentarios
4 4	versión	int32_t	Información de versión de bloque, basada en la versión de software que crea este bloque (nota, esto está firmado)
32	prev_block	char [32]	El valor hash del bloque anterior al que hace referencia este bloque en particular
32	raíz de merkle	char [32]	La referencia a una colección de árbol de Merkle que es un hash de todas las transacciones relacionadas con este bloque
4 4	marca de tiempo	uint32_t	Una grabación de marca de tiempo cuando se creó este bloque (¡Limitado a 2106!)
4 4	pedacitos	uint32_t	El objetivo de dificultad calculado que se usa para este bloque
4 4	mientras tanto	uint32_t	El nonce utilizado para generar este bloque … para permitir variaciones del encabezado y calcular diferentes hashes
4 4	transacciones_total	uint32_t	Número de transacciones en el bloque (incluidas las que no coinciden)
1+	hash_count	var_int	El número de hashes a seguir
32x?	hashes	char [32]	Hashes en profundidad de primer orden
1+	flag_bytes	var_int	El tamaño de las banderas (en bytes) a seguir
?	banderas	byte[]	Bits de bandera, empaquetados por 8 en un byte, el bit menos significativo primero. Se agregan 0 bits adicionales para alcanzar el tamaño de bytes completo.

Después de un merkleblock , las transacciones que coinciden con el filtro merkleblock se envían automáticamente en mensajes TX .

Puede encontrar una guía para crear un filtro de floración, cargar un bloque de merkle y analizar un árbol de bloque de merkle parcial en los Ejemplos de desarrollador .

sendheaders

Solicitud de anuncio de encabezados directos.

Al recibir este mensaje, el nodo puede, pero no es obligatorio, anunciar nuevos bloques mediante el comando de encabezado (en lugar del comando inv ).

Este mensaje es compatible con la versión del protocolo> = 70012 o la versión Core de Bitcoin> = 0.12.0.

Ver BIP 130 para más información.

No se transmiten datos adicionales con este mensaje.

filtro de tarifa

La carga útil siempre tiene 8 bytes de longitud y codifica un valor entero de 64 bits (LSB / little endian) de tarifa . El valor representa una tarifa mínima y se expresa en satoshis por 1000 bytes.

Al recibir un mensaje de «filtro de tarifa», el nodo podrá, pero no se requerirá, filtrar invitaciones de transacción para transacciones que caen por debajo de la tarifa proporcionada en el mensaje de filtro de tarifa interpretado como satoshis por kilobyte.

El filtro de tarifas es aditivo con un filtro de floración para transacciones, por lo que si un cliente SPV cargara un filtro de floración y enviara un mensaje de filtro de cuota, las transacciones solo se retransmitirían si pasaran ambos filtros.

Las invitaciones generadas a partir de un mensaje de mempool también están sujetas a un filtro de tarifa si existe.

El descubrimiento de características se habilita al verificar la versión del protocolo> = 70013

Ver BIP 133 para más información.

sendcmpct

1. El mensaje sendcmpct se define como un mensaje que contiene un número entero de 1 byte seguido de un número entero de 8 bytes donde pchCommand == «sendcmpct».
2. El primer entero DEBE interpretarse como un booleano (y DEBE tener un valor de 1 o 0)
3. El segundo entero DEBERÁ interpretarse como un número de versión little-endian. Los nodos que envían un mensaje sendcmpct DEBEN actualmente establecer este valor en 1.
4. Al recibir un mensaje «sendcmpct» con el primer y segundo número entero establecidos en 1, el nodo DEBE anunciar nuevos bloques enviando un mensaje cmpctblock.
5. Al recibir un mensaje «sendcmpct» con el primer número entero establecido en 0, el nodo NO DEBE anunciar nuevos bloques enviando un mensaje cmpctblock, pero DEBE anunciar nuevos bloques enviando invs o encabezados, según lo definido por BIP130.
6. Al recibir un mensaje «sendcmpct» con el segundo entero establecido en algo diferente a 1, los nodos DEBEN tratar al par como si no hubieran recibido el mensaje (ya que indica que el par proporcionará una codificación inesperada en
7. cmpctblock y / u otros mensajes). Esto permite que las versiones futuras envíen mensajes sendcmpct duplicados con diferentes versiones como parte del protocolo de enlace de versiones para versiones futuras.
8. Los nodos DEBEN verificar una versión de protocolo de> = 70014 antes de enviar mensajes sendcmpct.
9. Los nodos NO DEBEN enviar una solicitud de un objeto MSG_CMPCT_BLOCK a un igual antes de haber recibido un mensaje sendcmpct de ese igual.

Este mensaje solo es compatible con la versión de protocolo> = 70014

Ver BIP 152 para más información.

cmpctblock

1. El mensaje cmpctblock se define como un mensaje que contiene un mensaje serializado HeaderAndShortIDs y pchCommand == «cmpctblock».
2. Al recibir un mensaje cmpctblock después de enviar un mensaje sendcmpct, los nodos DEBERÍAN calcular la ID de transacción corta para cada transacción no confirmada que tengan disponible (es decir, en su mempool) y comparar cada una con cada ID de transacción corta en el mensaje de cmpctblock.
3. Después de encontrar transacciones ya disponibles, los nodos que no tienen todas las transacciones disponibles para reconstruir el bloque completo DEBERÍAN solicitar las transacciones faltantes utilizando un mensaje getblocktxn.
4. Un nodo NO DEBE enviar un mensaje cmpctblock a menos que pueda responder a un mensaje getblocktxn que solicite cada transacción en el bloque.
5. Un nodo NO DEBE enviar un mensaje de cmpctblock sin haber validado que el encabezado se confirma correctamente para cada transacción en el bloque, y se construye correctamente en la parte superior de la cadena existente con una prueba de trabajo válida. Un nodo PUEDE enviar un bloque cmpct antes de validar que cada transacción en el bloque gasta válidamente las entradas del conjunto UTXO existentes.

Este mensaje solo es compatible con la versión de protocolo> = 70014

Ver BIP 152 para más información.

getblocktxn

1. El mensaje getblocktxn se define como un mensaje que contiene un mensaje serializado BlockTransactionsRequest y pchCommand == «getblocktxn».
2. Al recibir un mensaje getblocktxn formateado correctamente, los nodos que recientemente proporcionaron al remitente de dicho mensaje un cmpctblock para el hash de bloque identificado en este mensaje DEBEN responder con un mensaje blocktxn apropiado. Tal mensaje blocktxn DEBE contener exactamente y solo cada transacción que esté presente en el bloque apropiado en el índice especificado en la lista de índices getblocktxn, en el orden solicitado.

Este mensaje solo es compatible con la versión de protocolo> = 70014

Ver BIP 152 para más información.

blocktxn

1. El mensaje blocktxn se define como un mensaje que contiene un mensaje serializado de BlockTransactions y pchCommand == «blocktxn».
2. Al recibir un mensaje blocktxn solicitado con el formato correcto, los nodos DEBERÍAN intentar reconstruir el bloque completo:
3. Tomando las transacciones prellenadas del cmpctblock original y colocándolas en las posiciones marcadas.
4. Para cada ID de transacción corta del bloque cmpct original, en orden, busque la transacción correspondiente ya sea desde el mensaje blocktxn o desde otras fuentes y colóquela en la primera posición disponible en el bloque.
5. Una vez que el bloque ha sido reconstruido, se procesará de manera normal, teniendo en cuenta que se espera que las ID de transacciones cortas choquen ocasionalmente, y que los nodos NO DEBEN ser penalizados por tales colisiones, donde sea que aparezcan.

Este mensaje solo es compatible con la versión de protocolo> = 70014

Ver BIP 152 para más información.

Scripting

Ver Scripting avanzado de Bitcoin .

Ver también

• Red

Atribución

Este contenido se basa en el contenido de https://en.bitcoin.it/wiki/Protocol_documentation bajo Creative Commons Attribution 3.0 . Aunque puede haber sido ampliamente revisado y actualizado, reconocemos a los autores originales.