Buip085 double passe relais bitcoin forum bitcoin problèmes

J’ai utilisé des nœuds XT pendant une demi-année mais un par un, ils ont tous commencé à souffrir de problèmes mystérieux comme être incapable de se connecter avec d’autres nœuds et même me refuser de dépenser mes propres fonds en raison de conflits étranges. Pour cette raison, je vous suggère fortement d’être très prudent lors de la mise en œuvre relayer deux fois dans les nœuds BU. Personnellement, je n’étais pas parfaitement satisfait de l’implémentation particulière de XT pour relayer deux fois parce que 90% des fois il a omis de m’avertir de vraies dépenses doubles. Je suppose que le hacker a directement poussé vers le pool de minage qui à son tour n’a pas relayé les doubles dépenses, donc le reste du réseau a seulement appris à ce sujet quand un bloc contenant le DS a été finalement exploité par ce pool.


Puisque la première option est beaucoup plus radicale que la deuxième option, je vais élaborer ici comment première règle pourrait être renforcé. Implémentez un pré-mempool qui stocke tous les nouveaux TX 0-conf que votre nœud apprend. Cependant, lorsqu’un TX est inséré dans la file d’attente pré-mempool, il devra attendre 10 secondes avant de pouvoir entrer dans le mempool. Pendant ce temps de 10 secondes, il est possible qu’un TX en conflit soit reçu par le même nœud. Lorsque cela se produit, le nœud peut déclencher l’événement `-respendnotify` afin que le commerçant puisse agir dessus. Chaque fois que des TX en conflit entrent dans le pré-mempool, toutes leurs minuteries de 10 secondes devraient être réinitialisées car elles deviennent toutes concurrentes et il pourrait y avoir plus d’une double dépense à venir. Il est plus logique de permettre au concurrent avec les frais les plus élevés de TX dans le mempool réel parce que les mineurs sont incités à faire exactement cela que nous le voulions ou non.

L’intervalle de 10 secondes est nécessaire pour que le nœud de réception puisse relayer immédiatement le nouveau TX à tous ses voisins, tout en attendant que les doubles dépenses potentielles arrivent. Je suppose que dans les 10 secondes un TX atteindra tous les nœuds du réseau. Si le double-dépense arrive plus tard que 10 secondes alors le première règle est naturellement appliqué même par les anciens nœuds qui ne relaient pas les doubles dépenses. Si le double-paiement arrive dans les 10 secondes, le commerçant a une chance théorique d’engendrer rapidement un TX CPFP à partir du paiement initial, en donnant tous les fonds aux mineurs et en rendant ainsi inutile que l’adversaire tente même de doubler ses dépenses.

En mettant en œuvre pré-mempool nous gardons cette nouvelle relayer deux fois la fonctionnalité est plus distincte de l’implémentation ancienne et fonctionnelle, ce qui réduit les risques d’introduction de nouveaux bogues et vulnérabilités. De nouveaux RPC doivent être ajoutés pour interroger le pré-mempool et obtenir des événements similaires à walletnotify exclusivement sur le pré-mempool. En d’autres termes, l’amélioration devrait être rétrocompatible avec tout logiciel utilisant les RPC actuels. Les logiciels reposant uniquement sur les anciens RPC connaîtraient un décalage de 10 secondes avant d’obtenir des informations sur les nouveaux paiements.

Le pré-mempool est utile car il fournirait également une solution d’opt-in pour le problème de malléabilité TX. Les TX à frais zéro sont conservés dans le pré-mempool pendant 10 secondes pour permettre à un TX CPFP d’arriver juste après le TX parent à frais zéro. L’enfant TX paie pour le parent et pour lui-même. Sans l’enfant, le parent ne peut pas être confirmé parce qu’il a des frais de zéro, donc le parent TX ne peut pas être malléable. Une petite règle consensuelle est cependant nécessaire pour que les TXs sans frais soient illégaux s’ils ne sont pas payés dans le même bloc. En d’autres termes, tous les blocs contenant un tarif zéro sans CPFP TX doivent être rejetés par tous les nœuds. En conséquence, nous aurons des notifications de double-dépense et un correctif opt-in pour la malléabilité TX implémentée dans le même correctif.

@torusJKL une telle attaque n’est pas possible car le concurrent pré-mempool est immédiatement relayé vers tous les autres nœuds. Si l’attaquant continue d’envoyer un double-dépense toutes les 10 secondes et que le marchand a un noeud mis à jour, le commerçant apprendrait ces double-dépenses via RPC. Si le marchand a un ancien nœud, alors la première règle est appliquée et le commerçant est vulnérable.

Cependant, votre commentaire a effectivement soulevé quelques questions dans ma conception proposée. Je ne suis pas vraiment sûr si une version plus à l’épreuve des balles peut être conçue, mais j’ai juste pensé que l’écart de 10 secondes n’est pas nécessaire pour le correctif de malléabilité TX. La correction de malléabilité TX peut être obtenue en relayant simplement le TX CPFP avant le TX parent. Le paiement de la CPFP sera traité comme un orphelin jusqu’à l’arrivée du parent qui n’aura pas de frais.

En ce qui concerne le pré-mempool, il serait peut-être préférable de rejeter d’autres doubles dépenses après 10 secondes écoulées depuis la réception du premier TX. Puis après 10 secondes celui qui ferait le plus d’argent aux mineurs est autorisé dans le mempool. De cette façon, l’écart de 10 secondes éliminera seulement le problème où le paiement et ses doubles dépenses sont diffusés simultanément et il y a une petite chance qu’un pool de minage reçoive le double-dépense mais le reste du réseau reçoit le paiement frauduleux.

Cliquez pour agrandir … Cela dit, je suppose que si nous avons une preuve compacte qui pourrait être utilisée au lieu de s’appuyer sur le double dépense txn, ce sera encore mieux et pourrait être facilement introduit dans le code XT tel que déployé et également proposé pour l’inclusion de BU. Voir https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/1018#issuecomment-377808701 pour plus de détails.

Un dernier sujet un peu lié: BitPay, en train de déployer BIP70 (protocole de paiement) pour tous les txns en ligne qu’il a géré introduire un changement au protocole pour que l’acheteur attende "200 OK" lors de l’envoi du message `payment` au marchand, avant la diffusion du paiement bitcoin. Si 200 n’est pas retourné, le paiement sera annulé.

Je me demande si nous pourrions aller encore plus loin et faire en sorte que le marchand soit celui qui va diffuser le txn sur le réseau et non sur l’acheteur. Mon instinct me dit de cette façon que le commerçant aurait beaucoup plus de contrôle sur le processus et l’acheteur qui veut double dépense aura plus de mal à s’en sortir.