Avec Bitcoin, le code, c'est la doc

// Drop the signature, since there's no way for a signature to sign itself
scriptCode.FindAndDelete(CScript(vchSig));

• Mastering Bitcoin, de Andreas M. Antonopoulos, publié chez O'Reilly en 2014 ;
• Programming Bitcoin, de Jimmy Song, publié chez O'Reilly en 2019.

Le code

Dissection du bloc Genesis

https://blockchain.info/rawblock/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f?format=hex

0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

• Tout d'abord, il est largement fait usage du little endian. En fait, tout est en little endian, sauf les scripts.
• Ensuite, tout est fait pour économiser des octets. Ainsi, le bloc contient plusiers entiers stockés sous forme de séries d'octets à taille variable (1, 3, 5 ou 9 octets) par application de l'algorithme suivant :

  def variantToBytes (n):
  	data = bytearray ()
  	if n < 0xfd:				# N < 0xfd : N sur 1 octet
  		size = 1
  	elif n < 0xffff:			# 0xfd <= N < 0xffff : 0xfd puis N sur 2 octets
  		size = 2
  		data.append (0xfd)
  	elif n < 0xffffffff:		# 0xffff <= N < 0xffffffff : 0xfe puis N sur 4 octets
  		size = 4
  		data.append (0xfe)
  	else:						# 0xffffffff <= N : 0xff puis N sur 8 octets
  		size = 8
  		data.append (0xff)
  	data.extend (n.to_bytes (size, byteorder='little'))
  	return data, len (data)
  

  Pour l'anedocte, la taille des données est devenue un enjeu crucial pour la communauté Bitcoin, au point qu'il a pu radicalement la diviser. Ainsi, l'introduction de SegWit pour notamment réduire le nombre d'octets pris en compte dans le calcul du hash d'une transaction a conduit certains mineurs à faire bande à part en créant Bitcoin Cash. Cette histoire savoureuse est notamment narrée dans un article de The Verge.

PUSH 4 bytes: ffff001d (rappel de "bits")
			  ....
PUSH 1 bytes: 04 (visiblement "extra nonce")
			  .
PUSH 69 bytes: 5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
			   The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

PUSH 3 bytes: 47d40a
			  G..
PUSH 27 bytes: 4d696e656420627920416e74506f6f6c3733363b015f004307c52d
			   Mined by AntPool736;._.C..-
*UNKNOWN*: fabe6d6dce946a3115c78ecf3fe707d9eb07e205f324a73cfbcb06dfbe49131caecc5b090200000000000000505c0000662c0200
		   ..mm..j1....?........$.<.....I....[.........P\..f,..

target = bits * 2 ** (8 * (0x1b - 3))

Dissection du bloc 170

• Une input, dont le scriptSig est :

  PUSH (la valeur de "bits" dans le header en little endian, soit 0xffff01d)
  PUSH ("extra nonce" sur un ou deux octets)
  

  Exception faite du bloc Genesis, qui donc rajoute à cela :

  PUSH "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
  

• Une ouput de 50 BTC, dont le scriptPubKey est :

  PUSH (65 octets)
  OP_CHECKSIG
  

• Une input qui fait référence à l'unique output 0 de 50 BTC de l'unique transaction 0 du bloc 9, dont le scriptSig est :

  PUSH (71 octets)
  

• Deux outputs, dont les scriptPubKey sont sur le modèles de ceux déjà vus dans les transactions :
  • une output de 10 BTC, dont le scriptPubKey est :

    PUSH (65 octets)
    OP_CHECKSIG
    

  • une output de 40 BTC, dont le scriptPubKey est :

    PUSH (65 octets)
    OP_CHECKSIG
    

Validation de la transaction 1 du bloc 170

---- Bloc 170 / Transaction 1 / Input 0 / scriptSig -----
PUSH 304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901
---- Séparateur -----
OP_CODESEPARATOR
---- Bloc 9 / Transaction 0 / Output 0 / scriptPubKey -----
PUSH 0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
OP_CHECKSIG

• (Bloc 9 / Transaction 0 / Output 0 / scriptPubKey) Une clé publique formée par la concaténation de deux nombres x et y de 32 octets en big endian :

  x = 11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c
  
  y = b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
  

• (Bloc 9 / Transaction 0 / Output 0 / scriptPubKey) Un octet indiquant si la clé est compressée ou non (en l'espèce, 0x04 indique qu'elle ne l'est pas) :

  04
  

• (Bloc 170 / Transaction 1 / Input 0 / scriptSig) Un octet indiquant le type du hash (en l'espèce, 0x01 correspond à SIGHASH_ALL) :

  01
  

• (Bloc 170 / Transaction 1 / Input 0 / scriptSig) Une signature :

  304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d09
  

  Il s'agit d'une représentation sous forme de texte des valeurs hexadécimales des octets résultant l'encodage en DER (Distinguished Encoding Rules) de la structure ASN.1 (Abstract Syntax Notation One) d'une signature ECDSA (Elliptic Curve Digital Signature Algorithm). La structure ASN.1 est décrite dans la RFC 3279 :

  Ecdsa-Sig-Value ::= SEQUENCE {
  	r	INTEGER,
  	s	INTEGER
  }
  

  L'encodage d'une structure ASN.1 au format DER est décrit dans le standard X.690 :

  Identifiant 30

  68 octets à suivre 44

  Type entier 02

  Longueur de l'entier (32 octets en big endian) 20

  Valeur de l'entier (r) 4e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd41

  Type entier 02

  Longueur de l'entier (32 octets en big endian) 20

  Valeur de l'entier (s) 181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d09

  Ces informations peuvent être récupérées en stockant les octets dans un fichier binaire, puis en utilisant OpenSSL :

  $ echo 304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d09 > signature.txt
  
  $ xxd -r -p signature.txt signature.der
  
  $ openssl asn1parse -in signature.der -inform der
  	 0:d=0  hl=2 l=  68 cons: SEQUENCE          
  	 2:d=1  hl=2 l=  32 prim: INTEGER           :4E45E16932B8AF514961A1D3A1A25FDF3F4F7732E9D624C6C61548AB5FB8CD41
  	36:d=1  hl=2 l=  32 prim: INTEGER           :181522EC8ECA07DE4860A4ACDD12909D831CC56CBBAC4622082221A8768D1D09
  

• Faire une copie temporaire de la transaction 0 du bloc 170.
• Modifier les inputs et ouputs de cette copie en fonction du type de hash :

  SIGHASH_ALL	Les inputs et les outputs ne sont pas modifiées
  SIGHASH_NONE	Exception faite de l'input utilisée, la séquence de chaque input est passée à 0 La liste des ouputs est vidée
  SIGHASH_SINGLE	Exception faite de l'input utilisée, la séquence de chaque input est passée à 0 Toutes les outputs dont l'indice est strictement supérieur à celui de l'input utilisée sont supprimées Exception faite de la dernière ouput, la valeur de toutes les outputs est passée à -1 Exception faite de la dernière output, le scriptPubKey de toutes les outputs est vidé

  Par ailleurs, tout type de hash précédent peut être combiné à SIGHASH_ANYONECANPAY. Dans ce cas, exception faite de l'input utilisée, toutes les inputs sont supprimées.
• Remplacer le scriptSig de l'input utilisée par le scriptPubKey de l'output qu'elle référence, c'est-à-dire l'output 0 de la transaction 0 du bloc 9.
• Ecraser toute occurence de la signature tirée de scriptSig dans scriptPubKey avec des 0.
  Cette opération est précédée d'un commentaire "Drop the signature, since there's no way for a signature to sign itself", qui ne l'éclaire en rien. En effet, comment le scriptPubKey de l'output 0 de la transaction 0 du bloc 9 pourrait-il contenir ne serait-ce qu'une occurence de la signature figurant dans le scriptSig de l'input 0 de la transaction 1 du bloc 170, ce bloc n'ayant été généré qu'après ? Faut-il lire l'opération comme un rappel d'ordre général : qui veut faire figurer la signature du hash d'un document dans ce document, ne peut le faire figurer qu'à un endroit qui doit être écarté ou neutralisé, en étant rempli de 0 par exemple, lors du hashing ?
  Quelques recherches permettent de constater que certains se sont posés la question, mais que personne n'a vraiment apporté de réponse, comme :
  • Sur ce forum : "It's legal to put a signature in the scriptPubKey -- Bitcoin just doesn't do so."
  • Dans les commentaires de cette implémentation de Bitcoin en Python : "Of course, this can only come up in very contrived cases now that scriptSig and scriptPubKey are processed separately."
  D'ailleurs cette étape n'est même plus mentionnée dans le schéma de la spécification.
  L'auteur de ces lignes a posé la question, et attend toujours une réponse...
• Sérialiser la transaction, et y rajouter le type de hash sous la forme d'un entier sur 4 octets en little endian. Etant donné que le type de hash peut conduire à vider un script ou une liste d'inputs ou d'outputs, il n'est pas inutile de rappeler que ces données se présentent comme de tableaux qui sont sérialisés en précédant la sérialisation de leurs éléments de celle du nombre d'éléments en question. Ainsi, la sérialisation d'un script ou une liste vide se résume à un octet 0.
• Calculer le double SHA-256 en big endian de l'ensemble.
• Disposant du hash ainsi calculé, de la signature tirée de scriptSign de l'input 0 de la transaction 0 du bloc 170, et de la clé publique reconstituée à partir des valeurs de x et y tirée de scriptPubKey de l'output 0 de la transaction 0 du bloc 9, vérifier la signature.

Signature: 304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d09
Public key (x): 11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c
Public key (y): b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
Hash: 7a05c6145f10101e9d6325494245adf1297d80f8f38d4d576d57cdba220bcb19

SubjectPublicKeyInfo ::= SEQUENCE {
	algorithm			AlgorithmIdentifier,
	subjectPublicKey	BIT STRING
}

AlgorithmIdentifier ::= SEQUENCE {
	algorithm	OBJECT IDENTIFIER,
	parameters	ANY DEFINED BY algorithm OPTIONAL
}

// SubjectPublicKeyInfo (0x56 octets)
30 56
	// AlgorithmIdentifier (0x10 octets)
	30 10
		// AlgorithmIdentifier.algorithm
		06 07 2a 86 48 ce 3d 02 01
		// AlgorithmIdentifier.parameters
		06 05 2b 81 04 00 0a
	// SubjectPublicKeyInfo.subjectPublicKey (0x42 octets)
	03 42 00
		// Clé non compressée
		04
		// x
		11 db 93 e1 dc db 8a 01 6b 49 84 0f 8c 53 bc 1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c
		// y
		b2 e0 ea dd fb 84 cc f9 74 44 64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3

$ openssl asn1parse -inform der -in public.der 
	0:d=0  hl=2 l=  86 cons: SEQUENCE          
	2:d=1  hl=2 l=  16 cons: SEQUENCE          
	4:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   13:d=2  hl=2 l=   5 prim: OBJECT            :secp256k1
   20:d=1  hl=2 l=  66 prim: BIT STRING

$ openssl ec -pubin -inform der -in public.der -text -noout
read EC key
Public-Key: (256 bit)
pub:
	04:11:db:93:e1:dc:db:8a:01:6b:49:84:0f:8c:53:
	bc:1e:b6:8a:38:2e:97:b1:48:2e:ca:d7:b1:48:a6:
	90:9a:5c:b2:e0:ea:dd:fb:84:cc:f9:74:44:64:f8:
	2e:16:0b:fa:9b:8b:64:f9:d4:c0:3f:99:9b:86:43:
	f6:56:b4:12:a3
ASN1 OID: secp256k1

$ openssl ec -inform der -in public.der -outform pem -out public.pem

-----BEGIN PUBLIC KEY-----
MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEEduT4dzbigFrSYQPjFO8HraKOC6XsUgu
ytexSKaQmlyy4Ord+4TM+XREZPguFgv6m4tk+dTAP5mbhkP2VrQSow==
-----END PUBLIC KEY-----

$ openssl pkeyutl -verify -pubin -inkey public.der -keyform der -sigfile signature.der -in hash.bin 
Signature Verified Succesfully

Vers l'infini, et au-delà