Reconstruction du chemin de financement

Un graphe de financement d’apparence continue peut masquer une transaction manquante ou transformer une sortie en propriétaire allégué. Le dossier historique permet de reproduire le chemin réellement collecté et de voir où il s’arrête.

AVERTISSEMENT DE PROVENANCE HISTORICAL : il s’agit d’enregistrements Bitcoin de 2009, collectés le 2 octobre 2026 auprès d’un seul indexeur public. Le dossier n’établit ni solde actuel ni identité humaine. Commencez par docs/academy-2/datasets/p10/dataset.json et exécutez son vérificateur hors ligne. Les correspondances SHA256d brutes établissent les identifiants des transactions sérialisées ; les étiquettes indexées de hauteur/hash restent déclarées par le fournisseur, sans nœud complet indépendant ni preuve de Merkle dans ce dossier.

Un lien Bitcoin est défini par l’ID de transaction précédente et l’index de sortie, pas par une étiquette de portefeuille conviviale du fournisseur. Suivez la sortie exacte référencée, consignez ses satoshis entiers et examinez l’entrée suivante. Une division crée plusieurs sorties ; elle ne prouve ni laquelle rend la monnaie ni qui en bénéficie économiquement. Tracez chaque branche collectée indépendamment et marquez une branche non collectée comme lacune.

Le chemin sélectionné commence par une coinbase au bloc-9, donc sans entrée ordinaire de financement antérieure. Il continue via le bloc 170 jusqu’au bloc 181. Ne dessinez pas d’adresse inventée avant la coinbase et ne renommez pas la sortie suivie « monnaie rendue au même propriétaire ». La réponse outspend du dossier décrit l’état de l’indexeur lors de la collecte, pas l’état au moment de l’événement original.

Outpoint : ID de transaction et index de sortie commençant à zéro.

Coinbase : transaction spéciale de récompense de bloc, sans entrée UTXO ordinaire antérieure.

Sortie suivie : branche sélectionnée du chemin sans affirmer la propriété de la monnaie rendue.

Lacune de collecte : branche dont la transaction brute suivante ne figure pas dans le dossier.

Parent historique : 0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9, sortie 0 = 5,000,000,000 sats, bloc 9. Transfert : f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16, bloc 170, dépense cet outpoint et crée la sortie 0 = 1,000,000,000 et la sortie 1 = 4,000,000,000 sats. Enfant : a 16f3ce4dd5deb92d98ef5cf8afeaf0775ebca408f708b2146c4fb42b41e14be, bloc 181, dépense la sortie 1 du transfert et crée 1,000,000,000 et 3,000,000,000 sats. Les deux transactions sélectionnées hors coinbase conservent les entrées avec des frais nuls dans ces enregistrements.

La dépense de la sortie-0 du transfert est mentionnée par l’index outspend collecté, mais sa transaction brute n’a pas été collectée. Les descendants de l’enfant sont aussi hors périmètre. Les heures d’en-tête, hashes exacts et horodatages de collecte sont conservés dans le manifeste ; le chemin n’est pas attribué à des personnes nommées.

Diagramme du chemin de financement avec trois IDs de transaction complets et hauteurs indexées 9, 170 et 181. Étiquetez chaque outpoint et montant de satoshis. Dessinez la sortie-0 du transfert et les descendants de l’enfant comme lacunes de collecte non résolues ; aucun cluster de propriétaires humains ni adresse fictive avant coinbase.

Légende : Chemin UTXO historique collecté ; les branches manquantes et limites d’attribution restent visibles.

SPECIFICATION_ONLY — le visuel rendu n’a pas été produit ni examiné indépendamment.

OBSERVED dans les octets figés/lignes indexées : identifiants exacts de transactions, liens d’entrées/sorties sélectionnés et montants entiers. Les identifiants bruts reproduits localement concordent. Les hauteurs déclarées par le fournisseur ordonnent les transactions sélectionnées en 9 → 170 → 181.

Le contrôle humain, la classification de monnaie rendue, les chemins aval non collectés et les soldes actuels sont UNKNOWN. Les preuves disponibles sont INSUFFICIENT pour soutenir une allégation sur la propriété ou l’intention. L’inclusion canonique native n’est pas établie indépendamment par ce dossier.

Nommer la sortie suivie comme monnaie rendue prouvée ; inventer une adresse parent pour coinbase ; compléter de mémoire la branche sortie-0 ; utiliser les outspends de collecte comme instantané de 2009.

Dessinez les trois transactions collectées avec les outpoints complets. Réconciliez les deux divisions en satoshis. Étiquetez deux limites de collecte et reformulez « une personne a déplacé les mêmes coins via les trois portefeuilles ».

• Exécutez le vérificateur d’octets figés et d’IDs bruts.
• Utilisez l’ID de transaction et l’index de sortie.
• Conservez les satoshis entiers à chaque division collectée.
• Maintenez les réserves sur la confirmation du fournisseur et les branches non collectées.

Le chemin historique figé étaye des liens UTXO précis et la conservation des montants, tandis que ses lacunes de branches empêchent des affirmations plus larges de propriété et de flux complet.

• Un lien du chemin est une référence exacte d’outpoint.
• Les divisions ne prouvent pas la propriété de la monnaie rendue.
• Montrez les branches non collectées plutôt que d’inventer une continuité.

P10-L05

Utilisez l’outil BlockAssay nommé uniquement comme contexte de lecture des preuves. Cette leçon ne crée aucune sortie d’outil, session de compte ni droit d’accès. Exercice hors ligne ; ne signez, ne déployez, n’approuvez et ne financez rien.

• BTC: Guide développeur Bitcoin — transactions — Les références des entrées identifient les sorties de transactions antérieures ; les scripts n’identifient pas un humain. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.

• API: Spécification de l’API publique Esplora — Routes GET, satoshis entiers et champs indexés de confirmation et de dépense des sorties. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.

• CHAIN: Localisateur figé de chaîne historique — Enregistrement d’un seul indexeur ; les octets historiques sont figés, sans preuve indépendante d’inclusion native ni d’identité humaine.

HISTORICAL — les dates d’événement et de collecte sont distinctes. Voir le dossier figé et les lacunes de collecte.

2026-10-02 (date de collecte ; pas l’heure de l’événement)

1

null

needs_review