bitcoin core : explique les champs de sortie et l'interprétation de decoderawtransaction

Votre message est un peu long, en échange de pile, nous préférons shotrt, des questions faciles à répondre – voir ici : https://bitcoin.stackexchange.com/help/how-to-ask

Vous avez probablement un exemple d’interprétation JSON comme référence. D’où l’avez-vous ? Comme tout le monde peut interpréter une transaction brute, je pense qu’il est préférable de référencer la transaction brute d’origine de bitcoin.org. C’est ambigu. Cela ressemblerait à ceci (non-segwit, pour rester facile. Segwit uniquement sur demande 🙂

VERSION
TX_IN COUNT (combien d’entrées ce tx a)
TX_IN[0…n]
Hash OutPoint (le tx précédent d’où proviennent les fonds)
Indice OutPoint (le nième TX_IN)
Longueur du script (la longueur de la signature de script suivante)
Signature de script (signature)
Séquence (un champ de séquence, initialement destiné à désactiver le temps de verrouillage)
TX_OUT COUNT (combien de sorties ce tx a)
TX_OUT[0…n]
Valeur (la valeur en Satoshis)
PK_Script Length (longueur du script suivant)
pk_script (le script, qui définit la condition, sous laquelle les fonds peuvent être dépensés)
LOCKTIME (heure au plus tôt ou bloc le plus tôt auquel cette transaction peut être ajoutée à la chaîne de blocs)

Le montage d’un tx avant d’être envoyé a été assez bien expliqué par la réponse de @amaclin ici.

Comment la quantité de chaque entrée dans le sous-ensemble vin peut-elle être déterminée ?

Le logiciel de portefeuille aurait besoin de rechercher les valeurs lorsqu’il souhaite dépenser un nouveau tx. Par conséquent, une référence à un tx précédent est requise, où v_in est trouvé. S’il est insuffisant pour le courant dépensé, alors un autre v_in ou même un autre tx avec son v_in sera utilisé (le nombre de TX_IN serait augmenté).

Comment le scriptSig peut-il être validé, comme : est l’entrée CLTV ou CSV
fermé à clé?

Je ne comprends pas ce que vous entendez par là. Scriptsig et CLTV/CSV ne sont pas directement liés à scriptsig. CLTV et CSV sont tous deux entrés dans le jeu par BIP-68 et BIP-112. CLTV (ainsi que locktime) sont tous deux des timelocks absolus, avec CSV, nous parlons de timelocks relatifs. Ils définissent donc quand la sortie d’une transaction peut être dépensée. Cela vaut peut-être la peine de rechercher dans les BIP. Il y en a aussi beaucoup dans le forum ici et dans bitcointalk.

Scriptsig (en général) est validé avec le hachage et la clé publique. Le blog de Ken Shirrif (lien en bas) explique très bien. Scriptsig prouve que vous aviez la clé privée (« vous êtes le propriétaire légitime ») pour passer cette transaction. La clé privée signe un hachage du tx, qui est suivi de la clé publique. Il peut y avoir plus, mais je veux rester général. Voici un exemple de la façon dont vous pouvez vérifier une signature sur le shell des systèmes unixoide avec openssl (bitcoin utilise toujours des données codées en hexadécimal pour effectuer des hachages, et openssl a besoin d’une clé au format PEM) :

sig=30450221009a29101094b283ae62a6fed68603c554ca3a624b9a78d83e8065edcf97ae231b02202cbed6e796ee6f4caf30edef8f5597a08a6be265d6601ad92283990b55c038fa
pk=03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4
hachage=4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3
printf $( echo $hash | sed ‘s/[[:xdigit:]]{2}/\x&/g’ ) > tmp_utx_dsha256.hex
echo « MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ= » > chat pubkey.pem
printf $( echo $sig | sed ‘s/[[:xdigit:]]{2}/\x&/g’ ) > tmp_sig.hex
openssl pkeyutl