Topic: Wanted Davout 400btc reward (Read 11634 times)

Oh ! Il est mimi 

Vachement plus classe qu'avec le cou nu.

Bah écoute, je te le souhaite.

400BTC c'est conséquent.

Vous voulez pas me prendre comme escrow ?

Comme ca j'ai 1% et je me fais de la réputation ?

Propose lui, ce serait cool 

Je ne me vexe pas, t'inquietes.

Vu le peu de choses dont il se souvient, il n'a pas du perdre que 1000 BTC, je ne serais pas surpris qu'il ai perdu son froc au même endroit.

Voila, je pensais aussi au fuseau.

Je commence à me dire que dudule se fout de notre gueule et démontre par son absence de réponse qu'il n'est pas sérieux.

Le mec n'a pas une info retrouvable dans la blockchain, ne sais pas a qui il a acheté, ni quand, a jeté le laptop...

Ca fait beaucoup quand même.

Pas de news de mon côté

Elle en est où cette affaire maintenant, j'ai pas trop suivi ? Davout a lâché les BTC ?

Yep. J'ai fait le même calcul.
Cela dit, considérant que ce gars est capable de se pointer à une conférence bitcoin avec un tutu rose (posté ici), je doute que réaliser ce type de transaction soit le genre de truc qui l'effraie.
 

c'est vrai que en cas de vol, l'intrus peut avoir interêt a suprimer des infos de la bdd pour camoufler le vol en cour.
Ca peut être une bonne piste facile a voir si des backup ont été fait régulierement.

Ou pas, si l'équipe d'Instawallet est honnête (ce qu'ils affirment)  et si les investigations permettent de trouver les transactions alors tout est bien qui fini bien.

Par contre en effet il est possible que tu es raison : mais c'est n'est pas la seule option possible.

Super boulot.
Par contre, vu que la suite de l'investigation ne peut être réalisée que par l'équipe instawallet, le résultat serait forcément biaisé !

Comme promis, voici un compte-rendu des recherches réalisées de mon côté. Ca va être un peu long et technique, aussi je m'excuse d'avance pour les lecteurs non versés dans la mécanique interne de bitcoin et de la blockchain. Les 3 premières parties sont ma tentative de synthèse pour poser le contexte du problème à partir d'éléments récupérés à droite et à gauche. Toute approximation ou erreur est de mon fait. N'hésitez pas à me les signaler, je corrigerai si nécessaire.


TL;DR: Ne pouvant retrouver les urls instawallet fournies par Phinnaeus Gage, l'équipe Instawallet a tenté d'identifier les transactions et adresses correspondant au dépôt initial de PG à l'aide de scripts développés spécialement à cette occasion. Il semble cependant que ces scripts puissent produire des faux négatifs. Une autre approche basée sur les backups bitcoind d'Instawallet est proposée.


1/ Fonctionnement d'Instawallet

Instawallet fonctionnait sur le principe de shared wallet:
  - tous les wallets utilisateurs étaient gérés au sein d'une même instance bitcoind
  - une base de données propriétaire servait à enregistrer les wallets et les données associées (url de l'instawallet, adresse de dépôt, transactions réalisées, balances, ...)
  - une transaction envoyant des coins vers une instawallet créditait les coins sur l'adresse de dépot associée à l'instawallet,
  - une transaction envoyant des coins depuis une instawallet ne débitait pas forcément les coins de l'adresse associée à l'instawallet (principe de shared wallet)
  - une cold wallet (1FrtkNXastDoMAaorowys27AKQERxgmZjY) était en place pour sécuriser les fonds. La cold wallet était alimentée/débitée par des opérations manuelles.


2/ Arrêt d'Instawallet

Début avril 2013, le service Instawallet a été suspendu suite à la détection d'une intrusion et du vol d'une partie des fonds. Une plainte a été déposée auprès des services de police et un audit a été réalisé par la société HSC.

Une opération de remboursement des utilisateurs a été mise en place par l'équipe Instawallet sur le principe de la fourniture de l'url d'accès à chaque wallet.


3/ Le cas Phinnaeus Gage

Dans le cadre de l'opération de remboursement, Phinnaeus Gage (PG) s'est déclaré propriétaire de 3 urls instawallet.

Deux de ces urls n'ont pu être retrouvées dans la base de données propriétaire par l'équipe Instawallet (IW).

L'équipe IW a demandé à PG de fournir les adresses de dépôt ou des identifiants de transactions afin d'identifier ces wallets. PG n'a pas été en mesure de fournir ces éléments.

Les éléments fournis à ce jour par PG sont les suivants:
  - achat autour de la seconde semaine de décembre 2012 d'un nombre de coins qui pourrait aller de 1123 à 1143btc.
  - achat réalisé dans l'Illinois (GMT-6)
  - achat réalisé a priori entre 12h et 15h
  - les coins achetés ont été déposés dans une instawallet fraichement créée
  - 2 ou 3 jours après, les coins ont été splittés vers 2 ou 3 nouvelles instawallets selon une répartition qui devrait approximativement être 1000btc / 132btc / x.xxxbtc

Afin de tenter d'identifier la transaction de dépôt initial PG, l'équipe IW a implémenté :
  - un script récursif visant à retrouver l'ensemble des adresses IW gérées par l'instance bitcoind d'IW
  - un script analysant la somme des coins reçus par les adresses identifiées à l'aide du premier script.
  Ces scripts n'ont pas permis d'identifier d'adresse IW correspondant aux éléments fournis par PG.

Principes du script récursif:
  - le script vise à retrouver toutes les adresses ayant appartenues à l'instance bitcoind d'IW.
  - dans une première étape, le script recherche dans la blockchain toutes les adresses qui sont associées aux entrées des transactions envoyant des fonds vers la cold wallet IW. Très logiquement, ces adresses sont considérées comme appartenant au bitcoind d'IW.
  - dans un second temps, le script s'appuie sur une heuristique dite des "transactions à entrées multiples". L'idée est que si une transaction a plusieurs entrées alors les adresses associées à ces entrées appartiennent au même bitcoind. Dans le cas d'un service comme IW, cette heuristique est tout a fait raisonnable.
  - l'idée du script est donc de rechercher les transactions ayant plusieurs entrées et dont l'une des entrées est associée à une adresse identifiée durant la première étape. Les adresses associées aux autres entrées sont alors considérées comme appartenant au bitcoind d'IW.
  - cette étape est ensuite répétée de manière récursive en s'appuyant sur les adresses identifiées à l'itération précédente.


4/ Analyse

4-1/ Identification des transactions candidates pour le dépôt initial

Le but est d'identifier dans la blockchain les transactions qui pourraient correspondre à l'achat initial des coins par PG et leur dépôt dans une première IW.

Nous sommes plusieurs a avoir réalisé ce travail. De mon côté, j'ai commencer par travailler sur des hypothèses élargies et recherché toutes les transactions réalisées entre le 01/12/2012 et le 31/12/2012 et dont une des sorties a un montant compris entre 998btc et 1500btc. Cette requête retourne environ 1600 txos candidates.

Dans un second temps j'ai filtré les résultats précédents pour ne retenir que les txos dont le montant est compris entre 1122 et 1143btc, ce qui donne une cinquantaine de txos candidates (et adresses associées).

Il est important de noter que cette recherche se base sur l'hypothèse que l'achat des coins s'est matérialisé par une transaction unique. Ca parait une hypothèse raisonnable pour commencer les recherches mais l'hypothèse de plusieurs transactions n'est pas à écarter totalement.

4-2/ Identification des adresses IW par l'algorithme récursif

J'ai implémenté l'algorithme proposé par Davout afin d'identifier les adresses IW. L'algorithme permet d'identifier environ 100k adresses IW.

4-3/ Tentative de matching des adresses

L'objectif est de vérifier si une ou plusieurs adresses remontées durant la première étape font partie de la liste des adresses IW.

Matching par rapport au set d'adresses étendu (~1600 txos candidates)
6 adresses sont identifiées comme des adresses IW
  16AJrCt6dx7pALFVxD6fGXoTnBCYEUmdor
  1J89pwTdTLNapnfUSYu4JA7NAuSGPFB4GJ
  1vD41j2ZJvxL3VQcUa4VFC9hwCUGBYkgZ
  16367mzW5XgsdmnkGtdhdMh9d9oyv5jTnC
  13KnmUZoMTpQ7hwM8g3QVbjVCK7dszQVt6
  1NEZpjPXRQToxSkcKe1UkXVkS9QBzL9S58
L'analyse rapide des transactions associées à ces adresses ne permet pas d'identifier formellement l'une d'elles comme correspondant aux informations fournies par PG (différences de montants, adresses utilisées avant décembre 2012, créneaux horaires différents, ...).

Matching par rapport au set d'adresses réduit (~50 txos candidates)
Aucune adresse n'est identifiée comme étant une adresse IW

4-4/ Analyse du script récursif

Avant de conclure définitivement que la requête de PG était illégitime (voir étape 4-3) je me suis penché sur les hypothèses associées au script récursif.

La principale hypothèse associée à ce script est qu'il permet de lister l'ensemble des adresses gérées par le bitcoind IW.

Cette hypothèse peut sembler raisonnable si on considère que :
  - IW était une shared wallet basée sur bitcoind
  - lors de la construction d'une transaction consommant des utxos de la shared wallet, l'algorithme de bitcoind a une partie déterministe (atteindre le montant désiré) et une partie aléatoire (randomization des utxos) pour la sélection des utxos à consommer. La partie aléatoire parait aller dans le sens d'un bon mixing des input adresses et donc d'une bonne couverture de l'algorithme récursif.

Cependant, même si la probabilité qu'une adresse IW ne soit pas listée par le script récursif est faible, cela ne signifie pas qu'elle est totalement nulle. Afin de creuser ce point, j'ai vérifié l'activité de la cold wallet IW durant le mois de décembre 2012:
  - entre le 08/12/2012 et le 26/12/2012 aucun transfert de coins vers la cold wallet n'a été réalisé
  - durant cette période, le flôt était plutôt inversé (transfert de 5,500btc de la cold wallet vers la hot wallet)
  - cela semble correspondre à une période ou il y avait plus de retraits que de dépôts sur IW
  - cette période correspond à l'époque ou PG déclare avoir réalisé ses opérations de dépôt et de split

Mon hypothèse est donc la suivante:
  - dans la période durant laquelle PG déclare avoir réalisé son dépôt, la hot wallet était a un niveau assez "bas" ce qui augmente la probabilité que les utxos de la hot wallet soient rapidement consommées. Il n'est donc pas improbable que les fonds déposés par PG aient pu être consommés par une transaction de retrait effectuée par un autre utilisateur avant le 26/12/2012
  - dans la mesure ou cet utxo avait un montant assez élevé, il n'est pas improbable qu'elle ait été la seule entrée d'une transaction de retrait
  - si c'est le cas, l'adresse de dépôt correspondant à l'IW initiale de PG ne peut pas être remontée par le script récursif, produisant de fait un faux négatif durant l'étape 4-3. Ceci pourrait expliquer pourquoi la transaction et l'adresse associées au dépôt initial de PG n'ont pu être identifiés.


5/ Suite de l'investigation

Arrivé à ce point, la suite de l'investigation nécessite de travailler à partir de backups du bitcoind et de la base de données propriétaire, travaux ne pouvant être réalisés que par l'équipe IW. J'ai donc transmis les résultats de mes recherches à Davout pour lui permettre d'avancer de son côté sur le sujet.

Selon moi, les prochaines étapes devraient être:
  - remonter une instance bitoind IW à partir d'un backup datant de début 2013, idéalement début janvier (en tout cas avant la date supposée de l'intrusion)
  - remonter une instance de la base de données propriétaire à partir d'un backup (même contraintes sur la date du backup)
  - exporter l'ensemble des adresses gérées par le bitcoind (seul moyen d'être sur d'avoir une liste exhaustive des adresses IW)
  - rechercher les matchings possibles entre les adresses listées en 4-1 et les adresses IW
  - si des matchings sont trouvés, rechercher les wallets correspondantes dans le backup de la base propriétaire pour vérifier si une IW semble correspondre de près ou de loin aux opérations décrites par PG (réception puis split dans 2 ou 3 autres IWs).

Un dernier point qu'il me semble important de prendre en considération: il n'est pas impossible que les personnes ayant réalisé l'intrusion et le vol de des fonds aient également modifié le contenu de la base de données propriétaire (et éventuellement du bitcoind) pour tenter de "camoufler" le délit en cours. Je pense notamment à la suppression de wallets dans la base propriétaire pour masquer un différentiel entre les fonds totaux apparaissant dans la base propriétaire et dans le bitcoind. Ce point pourrait expliquer pourquoi les urls de PG n'ont pu être retrouvées (mais à ce stade ce n'est qu'une hypothèse parmi d'autres possibles).

Non pas du tout. Pour l'instant des quelques échanges que j'ai eu avec les uns et les autres, rien ne me pousse à penser qu'il y ait eu malhonnêteté d'un côté ou de l'autre. Davout est très transparent sur le fonctionnement d'IW et sur les travaux réalisés de son côté pour résoudre le cas de Phinnaeus.

Le mystère n'est pas encore résolu, loin de là. Mon côté optimiste me laisse penser qu'il y a encore des pistes à explorer et qu'une fin positive pour tout le monde est encore possible. Cela étant il est aussi possible que ce ne soit pas le cas (impossibilité de recouper avec certitude les informations fournies par Phinnaeus, compte de Phinnaeus hacké, ou que sais-je...).
De mon côté,ça ne me coute pas grand chose d'y consacrer un peu de temps surtout que l'analyse de la blockchain est un sujet qui m'intéresse et que comme tout le monde je ne dirais pas non à 400btc. Et puis avoir résolu le mystère de la chambre jaune, ce serait assez la classe ! 

Sardokan le vautour.

   
 
 Quoi?
 Davout est tombé ?
 

Bonne news et n'oubliez pas de faire un postmortem dans tous les cas, for science  

Le mystère de la chambre jaune n'est pas encore élucidé mais ça progresse doucement.
D'un côté, j'ai une liste de transactions qui pourraient correspondre à la transaction initiale de Phinnaeus.
De l'autre côté, j'ai identifié 2 causes possibles qui pourraient expliquer pourquoi l'équipe Instawallet n'a pas été en mesure de valider certaines demandes. J'ai pu valider de mon côté une de ces causes avec certitude. Pour la seconde, ça nécessite de disposer du bitcoind d'instawallet, donc c'est hors de ce que je peux faire. J'ai transmis les éléments à Davout pour qu'il puisse avancer sur le sujet de son côté.
Rien n'est encore sur, mais j'ai bon espoir que cette histoire connaisse une happy end.

Je suis arrivé à la même conclusion (GMT-5) quelques posts au-dessus. J'espère que tes recherches aboutiront.

Il n'a pas précisé et comme il est rare que les gens répondent en GMT quand on leur demande l'heure, je fais l'hypothèse que c'est heure locale (Illinois). Ca parait une hypothèse raisonnable. Si je me trompe pas ça donne du GMT-5 en heure d'été et du GMT-6 en heure d'hiver.
De mon côté, j'ai quelques transactions qui pourraient correspondre. Maintenant il reste la question de les relier à un compte instawallet. Je vais me pencher sur la solution utilisée par Davout.

Un petit air de ressemblance avec Richard Stallman. Maitre GNU.

Il a bien la tête du crypto anarchiste de base :troll: