Merci pour tes précisions. 
C'est très intéressant !
Une est tout à fait indispensable, mais je pense que pour constater des forks, il aurait fallu plusieurs noeuds et voir sur quelle chain est quel noeud après tes tentatives.
Avec un seul noeud, tu sera toujours sur "une branche" de la chain en cas de forks. Tu sauras pas si il y'a réellement eu un fork ou pas.
Après je me trompe peut être et quelque chose m'échappe
Oui quelquechose t'échappe mais ce qui t'échappe m'échappe :-).C'est très intéressant !
Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%
Il devait y avoir environ 4-5 node sur ce réseau de test. De toutes façons même s'il y en avait plus, la nouvelle chain aurait juste mis plus de temps à se propager (et à être vérifiée) : une seule instance est nécessaire, seule la puissance de calcul compte.Une est tout à fait indispensable, mais je pense que pour constater des forks, il aurait fallu plusieurs noeuds et voir sur quelle chain est quel noeud après tes tentatives.
Avec un seul noeud, tu sera toujours sur "une branche" de la chain en cas de forks. Tu sauras pas si il y'a réellement eu un fork ou pas.
Après je me trompe peut être et quelque chose m'échappe
Je ne comprends pas pourquoi tu pense qu'il faut plusieurs noeuds. Chaque noeud faisait tourner la même version du client : ils agissent donc tous de la même manière, selon les mêmes règles de consensus pré-définies et c'est la raison pour laquelle l'attaque fonctionne.
Concernant le "savoir si il y a eu un fork", en pratique bitcoin-core (dont a été forké le client que j'utilisais) avertira (dans les logs) si il y a une réorg de la block chain : ça arrive régulièrement.
Merci pour tes précisions.
C'est très intéressant !
Une est tout à fait indispensable, mais je pense que pour constater des forks, il aurait fallu plusieurs noeuds et voir sur quelle chain est quel noeud après tes tentatives.
Avec un seul noeud, tu sera toujours sur "une branche" de la chain en cas de forks. Tu sauras pas si il y'a réellement eu un fork ou pas.
Après je me trompe peut être et quelque chose m'échappe
C'est là que meuh nous manque, il aurait certainement une astuce à nous donner .... C'est très intéressant !
Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%
Il devait y avoir environ 4-5 node sur ce réseau de test. De toutes façons même s'il y en avait plus, la nouvelle chain aurait juste mis plus de temps à se propager (et à être vérifiée) : une seule instance est nécessaire, seule la puissance de calcul compte.Une est tout à fait indispensable, mais je pense que pour constater des forks, il aurait fallu plusieurs noeuds et voir sur quelle chain est quel noeud après tes tentatives.
Avec un seul noeud, tu sera toujours sur "une branche" de la chain en cas de forks. Tu sauras pas si il y'a réellement eu un fork ou pas.
Après je me trompe peut être et quelque chose m'échappe
mais sinon avec ce genre de commande, on doit pouvoir voir normalement si on est sur la même chaîne que les autres nodes du réseau non?
https://bitcoin.org/en/developer-reference#getpeerinfo
Non, `getpeerinfo` ne renverra toujours que la version actuelle et ne comparera pas avec le passé. Par contre si tu as un service qui tourne à côté de ton nom et qui "poll" (qui fait des requêtes toutes les `n` secondes) `bitcoin-cli getblockhash $(bitcoin-cli getblockcount)` pourrait facilement se rendre compte que le hash a changé pour la même hauteur de la chain. Le plus simple serait juste que ce service regarde les logs.
En tout les cas, avec un seul nœud, ça me paraît difficile.
Effectivement et de toute façon avec un seul noeud il n'y a pas de réseau donc....Dès que ça ne matche plus quelque part, c'est qu'il y'a un fork.
C'est comme ça que je le ferais. Je vois pas trop comment faire autrement pour te rendre compte d'un fork.
En tout les cas, avec un seul nœud, ça me paraît difficile.
C'est comme ça que je le ferais. Je vois pas trop comment faire autrement pour te rendre compte d'un fork.
En tout les cas, avec un seul nœud, ça me paraît difficile.
Au lieu de mesurer la variance sur le sync tu peux la mesurer sur le hashrate. C'est à mon avis plus facile à mesurer, les soucis de sync peuvent arriver assez fréquemment. Ca demanderait pas mal d'intelligence/d'analyse d'analyser pas mal de bugs/hangs par rapport à la simple puissance de minage.
Dès que ça ne matche plus quelque part, c'est qu'il y'a un fork.
La variance sur le hashrate est plus efficace en effet. Une tentative d'attaque a 51% devrait pouvoir être détectée par une hausse soudaine du hashrate de plusieurs nodes. A moins que l'attaquant utilise un grand nombre de nodes, les nodes des attaquants devraient être facile a identifier car ils devraient centraliser un hashrate extrêmement élevé.
Cependant, comme le hashrate d'un node est transmit par le logiciel de minage a travers le stratum du pool, c'est facile de masquer la vrai valeur du hashrate en modifiant le logiciel de minage pour qu'il envoie des données bidon, ou en utilisant son propre pool avec un stratum modifié.
Non c'est justement l'inverse : c'est l'absence soudaine d'une grande partie du hashrate sur la main chain. On ne peut pas se rendre compte du hashrate si on n'a pas connaissance de la chain alternative.La variance sur le hashrate est plus efficace en effet. Une tentative d'attaque a 51% devrait pouvoir être détectée par une hausse soudaine du hashrate de plusieurs nodes. A moins que l'attaquant utilise un grand nombre de nodes, les nodes des attaquants devraient être facile a identifier car ils devraient centraliser un hashrate extrêmement élevé.
Cependant, comme le hashrate d'un node est transmit par le logiciel de minage a travers le stratum du pool, c'est facile de masquer la vrai valeur du hashrate en modifiant le logiciel de minage pour qu'il envoie des données bidon, ou en utilisant son propre pool avec un stratum modifié.
Concernant le masquage du hashrate : il n'est possible que lorsque l'on n'a pas encore publié les blocs, si tu publie un bloc tu informe (statistiquement) sur ton hashrate. Dans le cas d'une attaque à "51" le hashrate est masqué avant la publication d'une chain avec une énorme preuve de travail. A ce moment c'est déjà trop tard.
(Mais juste une fois, pour tester et voir si ça marche 
#noevil)