On-chain Analysis

Alice lit qu’un important montant de bitcoins vient de bouger. Quelqu’un a peut-être payé un achat, déplacé des fonds vers un autre de ses portefeuilles ou effectué un dépôt auprès d’un service. Le Bitcoin Developer Guide explique le contenu d’une transaction ordinaire : les entrées renvoient à des montants reçus auparavant, les sorties définissent de nouveaux montants et leurs conditions de dépense. Ces liens sont vérifiables, mais ne révèlent pas à eux seuls lequel de ces cas s’est produit. L’identifiant désigne la transaction, pas l’identité civile d’une personne. [1]

Pensons à un paiement en espèces dont on récupère la monnaie. De même, une transaction Bitcoin peut utiliser entièrement un montant reçu auparavant, créer une sortie pour le destinataire et une autre rendant le reste au payeur. Le Bitcoin Developer Guide décrit ce rendu comme une sortie ordinaire, pas une catégorie d’argent distincte. En additionnant toutes les sorties, Alice compte aussi ce reste. Le transfert entier pourrait même relier des adresses du même détenteur. Déterminer combien passe sous le contrôle d’autrui exige d’autres preuves ou une hypothèse annoncée comme telle. [1]

Une adresse sert à recevoir des bitcoins ; ce n’est pas une pièce d’identité. Une personne peut utiliser de nombreuses adresses, tandis qu’un dépositaire garde les fonds de plusieurs clients. Glassnode utilise donc aussi des entités : des groupes d’adresses estimées sous contrôle commun. Il applique des heuristiques, des règles pour déduire des relations dans les données, et non un registre de noms vérifiés. Le fournisseur reconnaît que ces estimations statistiques peuvent évoluer. Alice ne peut donc pas présenter directement le nombre d’adresses actives ou de groupes comme celui des utilisateurs de Bitcoin. [3]

Lightning Network permet des paiements au moyen de canaux : les participants mettent à jour la répartition des fonds sans inscrire chaque paiement séparément dans la blockchain. Un aperçu on-chain ne recense donc pas tous les paiements en bitcoin. De même, un service peut déplacer les soldes de clients dans sa propre comptabilité. Ce n’est pas le même événement qu’un transfert enregistré sur le réseau Bitcoin. L’absence de transaction distincte ne permet pas à Alice de conclure à l’absence d’activité économique. [6]

Attribuer une adresse à une plateforme d’échange demande des informations supplémentaires, pas seulement un montant. Glassnode signale des étiquettes incomplètes, ajoutées après coup et des mouvements internes pouvant perturber l’interprétation. Ses indicateurs on-chain d’échanges suivent mouvements et soldes, pas les achats et ventes réalisés sur les actifs eux-mêmes ou sur des contrats dont la valeur en dépend. Alice peut constater une arrivée sur une adresse étiquetée, sans savoir si quelqu’un a vendu. Le solde visible ne prouve pas non plus que la plateforme peut honorer ses engagements : il ne montre ni toutes ses dettes ni nécessairement tous ses actifs. [4]

L’horodatage d’un point de graphique peut désigner la période mesurée plutôt que la publication de l’indicateur. Glassnode décrit les délais de confirmation et de traitement. Une réorganisation peut aussi modifier les données : un nœud remplace une partie de la branche suivie par une autre branche valide selon les règles du réseau. Pour évaluer une décision passée, Alice doit connaître la fin de la période, la disponibilité de la version précise, son heure de récupération et l’état de la chaîne utilisé. Une date sur le graphique actuel ne prouve pas que la valeur actuelle était connue à l’époque. [5]

Le fournisseur apprend plus tard que des adresses appartenaient au même service, ou corrige un calcul. L’indicateur historique peut changer sans modification du transfert initial. Pour les tests historiques, Glassnode propose des données Point-in-Time, conservant la première valeur publiée sans révision ultérieure. Alice peut utiliser cette ancienne version, mais doit toujours vérifier quand elle était réellement accessible. Introduire le savoir actuel dans une décision simulée du passé crée un Look-ahead Bias, un biais dû à des informations venues du futur. Figer les données ne garantit pas la justesse de l’attribution d’un propriétaire. [5]

Le Bitcoin Developer Guide distingue les sorties dépensées de celles qui ne le sont pas. Une sortie non dépensée, ou UTXO, est un montant créé auparavant et pas encore utilisé dans une autre transaction. Cette distinction montre déjà l’importance de définir ce que l’on compte. Alice conserve avec le résultat la plage de blocs, les unités, filtres, version du calcul et origine des étiquettes. Ajouter un prix de marché revient à introduire une donnée extérieure à la blockchain. Cette méthode rend les conclusions et leurs limites vérifiables. Elle ne fournit pas une prédiction certaine du futur prix de Bitcoin. [2]