Estoy desarrollando un constructor de transacciones, pero enfrenté varios problemas. A algunas de las cuales encontré respuesta en ¿Cómo firmar una transacción con múltiples entradas? , por lo demás intentaré explicar:
'version': 1, 'inputs': (2) { 'output_tx_hash': 'aaaa', 'output_position': 0, 'script': the original script, like: '76a914' + hash + '88ac', 'sequence': ffffffff, }, { 'output_tx_hash': 'bbbb', 'output_position': 1, 'script': '', # Nothing 'sequence': ffffffff, } 'outputs': (2) 'value' : 100000 'script' : '76a914' + hash of btc pub key + '88ac' 'value' : 50000 'script' : '76a914' + hash of btc pub key + '88ac' 'locktime': 0
Cuando se trata de transacciones, creo que una representación hexadecimal puede explicar de forma más clara que las palabras.
Es por eso que mi respuesta usa hexadecimal en cada paso de la firma.
Dada su transacción P2PKH con dos entradas, aquí está la transacción sin procesar que debe firmarse con la clave privada correspondiente al primer punto de salida:
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
19
76a914<your-first-pkhash(160bit)>88ac
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
00
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000
01000000
Aquí está la transacción sin procesar que debe firmarse con la clave privada correspondiente al segundo punto de salida:
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
00
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
19
76a914<your-second-pkhash(160bit)>88ac
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000
01000000
Y aquí está la transacción firmada resultante:
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
6a
47
304<...rest-of-signature>
01
21
<your-first-pk(264bit)>
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
6a
47
304<...rest-of-signature>
01
21
<your-second-pk(264bit)>
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000
Suposiciones: (1) Está utilizando claves públicas comprimidas. (2) el tipo es SIG_ALL
Nota: La longitud de las firmas puede variar y, como resultado, los bytes que indican la longitud del script pueden diferir del ejemplo anterior.
Respondiendo a su tercera pregunta, hay una descripción aquí
Cuando tenemos múltiples entradas y múltiples salidas y tratamos de firmar cada entrada, ¿qué llenamos en la sección de valor de salida para cada una de ellas? La suma total de las entradas de la transacción o la cantidad correspondiente que tiene cada entrada que firmamos y distribuimos. entre las salidas?
Para las entradas que no son de segwit, el mensaje que se codifica para que lo firme es casi toda la transacción en sí. Debe tener todas las salidas en el orden en que estarán en la transacción final. No pones una salida ni las agregas, las pones todas como si fuera la transacción final.
Para las entradas de segwit, en lugar de poner todas las salidas en el mensaje, primero las mezcla todas juntas. Se serializan como si fueran a estar en una transacción, luego se codifican todos a la vez. El hash SHA256 resultante es lo que usa en el mensaje. Lea BIP 143 para obtener más información al respecto. El valuecampo en ese mensaje es el valor de solo la salida que gasta esa entrada en particular.
En la secuencia de comandos de la sección en las entradas, hay "Nada", pero ¿cuál es el recuento exacto de bytes: 1 byte, 4 bytes o algo más?
"Nada" significa que hay una secuencia de comandos de longitud 0, por lo que significa el byte único 00. Sin embargo, en ningún momento de la firma de la transacción firmará un script vacío. Si es así, algo anda mal.
dimitar vasilev
andres chow