Le cours de développeur Bitcoin - Créer votre propre portefeuille Bitcoin !

1. Introduction: Bonjour, Bienvenue dans le cours pour développeurs Bitcoin. m'appelle Alberto et je suis heureux de vous présenter le premier et unique cours où vous apprendrez le Bitcoin en créant un portefeuille Bitcoin de bureau. Commençons donc par expliquer ce que vous allez apprendre dans ce cours. En bref, vous apprendrez comment fonctionne le Bitcoin d'un point de vue technique. Plus précisément, vous apprendrez en détail comment fonctionne un portefeuille Bitcoin. Vous apprendrez également comment fonctionne un nœud Bitcoin et comment l'exécuter. Nous verrons comment il interagit avec notre portefeuille et les autres nœuds. apprendrai également comment fonctionne le réseau Bitcoin et comment il parvient à un consensus. concepts que nous allons apprendre incluent les transactions, les adresses, les graines, les clés, les soldes, la blockchain, le minage et le portefeuille. Comme nous allons créer une application de bureau tout au long du cours, l'étudiant aura l' occasion de mettre en pratique les compétences suivantes en génie logiciel les compétences suivantes en génie logiciel, qui sont très demandées dans l'industrie du logiciel. Le paradigme de programmation orienté objet sur lequel repose notre portefeuille. La plupart des fonctionnalités seront créées, suivront la méthode de développement pilotée par les tests. Comme le nom de cette approche l'indique, chaque fonctionnalité créera d' abord ses tests, et les tests orienteront la fonctionnalité, le développement ultérieur posera également une grande inquiétude quant à l'application. les meilleures pratiques en matière de sécurité et considérez l'application comme un système critique. Personnellement, j'ai de la peau dans le jeu avec cette application, et je fais beaucoup d'efforts pour minimiser le risque que quelqu'un perde de l'argent avec elle. En outre, ce cours contient de nombreuses meilleures pratiques de programmation, des exemples, des principes solides et code propre imprègnent la culture de notre code. Voyons maintenant comment vous allez apprendre dans ce cours. Nous suivrons la méthodologie de l'apprentissage par la pratique. Environ 17 % de ce cours est composé de théorie, le reste de cours pratiques. Le cours est donc fortement axé sur le code, intercalé avec quelques présentations si nécessaire. Sous chaque vidéo, vous trouverez des liens supplémentaires et matériel d'étude sur la page Projets et ressources. Vous allez créer un portefeuille Bitcoin de bureau, en apprenant les concepts importants du Bitcoin. Maintenant, listons les exigences recommandées pour suivre ce cours. Il est recommandé que l'étudiant ait une bonne connaissance de la programmation orientée objet. L'étudiant doit connaître Java ou des langages similaires avant de suivre ce cours. Bien que ce cours présente différents concepts de génie logiciel, notre objectif est de comprendre le Bitcoin. Si l'étudiant souhaite connaître en détail certains des concepts de génie logiciel abordés dans ce cours. Il devra utiliser d'autres sources tout au long du cours pour mieux les comprendre. Vous aurez besoin d'un ordinateur Windows, macOS ou Linux avec une connexion Internet. Nous présenterons ce cours sous Windows. Mais comme Java est compatible avec plusieurs plateformes, chaque code de ce cours fonctionnera de la même manière sur ces trois systèmes d'exploitation. La seule différence sera d'installer les logiciels nécessaires sur chaque plateforme, mais vous pouvez facilement trouver des guides pour les installer sur ces systèmes d'exploitation. Vous aurez besoin d'au moins 30 Go d'espace libre pour exécuter le nœud Bitcoin sur l'environnement de test du réseau. En option, si vous avez l'intention d'exécuter l'application sur l'environnement réseau principal, vous aurez besoin d'au moins 430 Go d' espace disque pour télécharger la chaîne de blocs réseau principale. Mais ne vous inquiétez pas, nous n' utiliserons l'environnement réseau principal que dans la dernière vidéo du cours. Vous aurez donc tout le temps de le télécharger avant d'en avoir besoin. Parlons maintenant un peu plus du portefeuille que vous allez créer au fil du parcours. J'appellerai ce portefeuille BYOD W, acronyme de Build your own wallet, commencera à développer cette application avec Java 16, mais nous la mettrons à jour plus tard dans le cours. Diversion 19 utilisera le framework Spring Boot version 2.5, 0.4, qui fournira un conteneur d'injection de dépendances et de nombreuses fonctionnalités pour nous aider à créer notre application. Plus tard dans le cours, nous le mettrons à jour vers les versions 2.7, 0.5. Nous utiliserons la version 16 de Java FX dans le projet. Nous le mettrons à jour ultérieurement vers la version 19. Cette bibliothèque fournira des classes qui nous aideront à créer l'interface utilisateur graphique de l'application, également connue sous le nom de gooey. Pour les tests, nous utiliserons Groovy, le framework Spark et Test Ethics pour créer des portefeuilles, des adresses de départ, des transactions et d'autres opérations Bitcoin utiliseront la bibliothèque open source Bitcoin Java, que j'ai construit spécialement pour ce cours. Nous utiliserons la version 22 du Bitcoin Core Node pour communiquer avec la blockchain. Plus tard dans le cours, nous le mettrons à jour vers la version 23. Bien que le nœud Bitcoin Core puisse générer des portefeuilles et des adresses, il ne l' utilisera que pour récupérer des données et les envoyer vers la blockchain. opérations telles que la génération de graines, d'adresses, création et la signature de transactions seront effectuées par notre application. L'exception concernera les tests. Dans ces cas, nous utiliserons l'API RPC Bitcoin Core Node pour générer des adresses, envoyer des transactions et extraire des blocs dans les environnements de test. Nous nous familiariserons donc avec les plus importants API Bitcoin Core Note RPC et créez un client pour communiquer avec elle depuis notre application. Comme la base de données utilisera l' implémentation SQL Java, H SQL DB utilisera pour une intégration fluide avec la bibliothèque Spring Boot Data JPA pour communiquer avec la base de données. Enfin, nous utiliserons l'idée IntelliJ comme IDE pour créer ce projet. Tout le code présenté dans ce cours est open source et est disponible sur notre page GitHub. Pour chaque cours pratique, la page Projets et ressources contiendra un lien indiquant la différence de code entre les deux derniers cours pratiques pour faciliter la tâche des étudiants. Maintenant, présentons qui je suis. Je m'appelle Alberto Salazar et je serai votre professeur dans ce cours. J'ai plus de cinq ans d' expérience en tant que développeur de logiciels professionnel, notamment dans le secteur du commerce électronique. Je suis un passionné de Bitcoin depuis 2016. J'ai beaucoup étudié les Bitcoins depuis lors. Je développe la bibliothèque open source Bitcoin Java, que nous utiliserons dans ce cours. J'ai créé l' initiative éducative Bitcoin pour concentrer mes efforts sur la fourniture formation sur le Bitcoin aux développeurs du monde entier. Suivez-nous sur Twitter pour recevoir nos dernières mises à jour. J'ai concentré tout le code de ce cours, y compris la bibliothèque Java Bitcoin sur notre page GitHub. Nous avons également un site Web dont l'adresse est www point bitcoin education point site. Nous y avons quelques articles techniques qui peuvent servir de matériel d' étude supplémentaire. Découvrez-le en guise de dernier mot. J'aimerais dire que beaucoup de travail a été consacré à l'élaboration de ce cours. Il m'a fallu plus de deux ans de préparation et presque tout mon temps libre pendant cette période. Donc, s'il vous plaît, si vous rencontrez des difficultés ou rencontrez un problème avec ce cours, contactez-moi avant de lui attribuer une note faible afin que nous puissions vous aider à résoudre votre problème. Je ferai tout mon possible pour que vous ayez une excellente expérience d'apprentissage. Merci beaucoup de votre attention et à bientôt dans la prochaine vidéo. 2. 0 Installation des exigences Skillshare 2: Dans cette vidéo, nous allons vous présenter les logiciels nécessaires que vous devrez télécharger et installer avant de passer aux prochaines vidéos du cours. Commençons donc par le nœud Bitcoin Core. Le Bitcoin Core Node est l' implémentation originale de Bitcoin. Il est chargé de communiquer avec la blockchain, de créer, de recevoir, d'envoyer et de valider les transactions Bitcoin, recevoir des blocs, etc. Comme nous l'avons dit dans la vidéo précédente, les principales fonctions qui reposeront sur le nœud Bitcoin Core sont celles liées à la communication avec la blockchain. Passons donc au site Web Bitcoin core.org. Installera la version 22 de Bitcoin Core. Vous vous demandez peut-être pourquoi ne pas installer la version 23 ? Lorsque j'ai commencé à créer ce cours, la dernière version disponible était la 22. Il existe une petite différence dans l'API gRPC de la version 23 qui empêchera une méthode de notre application de fonctionner correctement. Dans l'une des dernières vidéos du cours, nous mettrons à jour la version 23 du nœud Bitcoin 2 et rendrons notre application compatible avec celle-ci. Mais pour l'instant, installons la version 22. Pour ce faire, cliquez sur le bouton de libération en haut de l'écran, puis cliquez sur le lien Bitcoin Core 22. Cliquez ensuite sur ce lien sur la page. Cette page contient les fichiers d'installation pour chaque système d'exploitation. Comme j'utilise Windows, je vais télécharger celui qui se termine par point EXE. Si vous utilisez macOS, vous téléchargerez celui qui se termine par point DNG. Pour les distributions Linux, choisissez le fichier point GZ approprié en fonction de la distribution que vous utiliserez sur la page Projets et ressources Des liens contenant des instructions d'installation sont pour chacune système d'exploitation. Pour Windows, après avoir téléchargé le fichier, ouvrez-le et suivez les instructions d'installation affichées à l'écran. Je ne le ferai pas car je l'ai déjà installé sur ma machine. Mais c'est un processus simple. Dans la dernière phase de l'installation, il vous sera demandé si vous souhaitez ouvrir le logiciel. Ne l'ouvrez pas encore. Interagira avec le nœud Bitcoin via l'interface de ligne de commande. Si vous ouvrez le nœud en cliquant sur son icône, il ouvrira une interface utilisateur graphique et commencera à télécharger la blockchain sur l'environnement réseau principal, ce que nous ne voulons pas encore faire. Configurons maintenant notre nœud Bitcoin. Pour cela, nous devrons créer un fichier nommé bitcoin.com et le dossier approprié de l'application Bitcoin. L'emplacement de ce dossier dépend du système d'exploitation que vous utilisez. Ce site Web à l'écran indique l'emplacement par défaut où vous devez créer ce fichier pour chaque système d'exploitation. Pour le créer, ouvrez un fichier texte et enregistrez-le sous le nom bitcoin.com dans le dossier approprié à votre système d'exploitation. Maintenant, écrivez la même configuration que celle que vous voyez à l' écran dans votre fichier, ou copiez et collez le contenu de la page Projets et ressources dans celui-ci. Ne vous inquiétez pas, nous vous expliquerons la signification de chaque ligne de ce fichier dans une prochaine vidéo. Pour l'instant, vous devrez décider où vous souhaitez stocker les données de la blockchain sur votre ordinateur, vous devrez choisir un chemin donnant accès à au moins 30 Go pour la blockchain nette de test, ou 430 supplémentaires gb pour la chaîne de blocs réseau principale. Définissez éventuellement la configuration DIR des données sur le chemin choisi dans ce fichier. Dans mon cas, j'ai décidé de stocker les fichiers blockchain le lecteur E dans le dossier de données Bitcoin, comme vous le voyez à l'écran. Maintenant, si nous exécutons le nœud Bitcoin avec cette configuration, il s'exécutera sur le réseau principal et commencera à télécharger la blockchain du réseau principal. Comme son nom l'indique, l'environnement net principal est le principal environnement bitcoin, où la blockchain est grande et où les bitcoins ont de la valeur, ne gérera l'environnement net principal dans le dernier vidéo du cours. Avant cela, je l'exécuterai sur l'environnement du réseau de test, qui est utilisé pour les tests. Pour exécuter notre note sur l'environnement du réseau de test, ajoutons une ligne écrite test net égal à un dans le fichier bitcoin.com. Maintenant, en utilisant le terminal, allons dans le dossier dans lequel vous avez installé le nœud Bitcoin Core. Dans le dossier Demon, exécutez l' application Bitcoin D comme suit. Dans les journaux de la console. Notez que nous exécutons Indeed dans l'environnement du réseau de test et toutes ses données seront stockées dans le dossier indiqué. Bien, cela signifie que notre nœud fonctionne avec la configuration que nous avons définie dans le fichier bitcoin.com. Maintenant, attendons que notre nœud se connecte à d'autres nœuds et commençons à télécharger et à valider la blockchain. D'accord, les lignes commençant par l'astuce de mise à jour du texte indiquent que le téléchargement de la blockchain a commencé. Chacune de ces lignes indique un bloc de transactions Bitcoin téléchargées. La progression sur chaque ligne indique le niveau de perte de la blockchain. Dans mon cas, cela indique qu' environ 98 % de la blockchain du réseau de test a été téléchargée. Lorsque cette valeur est égale à un, cela indique que notre copie de la blockchain est complètement synchronisée avec celle des autres nœuds. Pour l'environnement réseau de test, cela peut prendre quelques heures pour que cela se produise. Vous pouvez le laisser couler pendant que vous regardez le reste du cours, car nous ne l'utiliserons qu'après quelques vidéos. Pour quitter l'application, vous pouvez appuyer sur Ctrl plus C ou Commande plus C si vous utilisez Mac OS. Si vous redémarrez la note, le téléchargement de la chaîne de blocs à l'endroit où il s'est arrêté commencera . Une fois le téléchargement de l'environnement réseau de test terminé, vous pouvez éventuellement modifier le fichier bitcoin point conf et commencer à télécharger la chaîne de blocs réseau principale en exécutant la note sur l'environnement réseau principal, utilisera uniquement l'environnement réseau principal dans la dernière vidéo du cours Vous aurez donc tout le temps de le télécharger. L'autre exigence initiale de ce cours est l'IDE Java IntelliJ Idea. C'est le logiciel qui va utiliser pour écrire le code et exécuter notre application. Si vous ne l'avez pas, rendez-vous sur le site Web à l' écran pour le télécharger. Téléchargez et installez l'édition communautaire pour votre système d'exploitation en suivant les instructions du site Web. 3. Qu'est-ce que le Bitcoin ?: Bonjour, bienvenue dans le cours pour développeurs Bitcoin. Dans cette section de cours , vous aurez un aperçu du Bitcoin. Les concepts présentés dans cette section fourniront les connaissances de base nécessaires pour comprendre ce qui va suivre dans la suite du cours. Je vais donc commencer par la question, qu'est-ce que le Bitcoin ? Le Bitcoin avec un B majuscule est un protocole de communication. Ce protocole est un ensemble de règles qui permet l'échange de messages entre les entités participant au réseau Bitcoin. Le bitcoin avec un b minuscule est une cryptomonnaie. Une cryptomonnaie est une forme de monnaie numérique que nous pouvons échanger contre des biens ou d'autres actifs. La partie cryptographique du nom provient de la cryptographie, qui protège les transactions et autres opérations Bitcoin. Le Bitcoin est également un système de paiement. Nous pouvons envoyer et recevoir des paiements en Bitcoin à destination et provenance d'autres participants du réseau Bitcoin. En parlant de réseaux, Bitcoin est également un réseau pair à pair, ce qui signifie qu' il est composé d' entités ou de nœuds qui communiquent directement entre eux sans la participation de serveurs centralisés. La question suivante est quand le bitcoin a-t-il été inventé ? Le Bitcoin a été inventé en 2008 par Satoshi Nakamoto lors de la publication du livre blanc, Bitcoin, euh, système de paiement électronique peer-to-peer. Dans cet article, que je recommande vivement de lire, Satoshi décrit les éléments de base du Bitcoin. Personne ne sait qui est réellement Hitoshi Nakamoto, ni même s'il s'agit d'un vrai nom ou de plusieurs personnes. Qui que soit Satoshi, en 2009, il a publié le premier bloc Bitcoin appelé Genesis Block et a mis le réseau Bitcoin en service. Si vous ne savez pas ce qu'est un bloc Bitcoin, ne vous inquiétez pas. Je vais vous expliquer brièvement. Alors, qu'y a-t-il de si génial avec le Bitcoin ? Qu'est-ce que l'innovation du Bitcoin ? Le Bitcoin a été la première monnaie numérique à avoir connu un succès retentissant. Avant le Bitcoin, il y avait eu quelques tentatives pour créer des monnaies numériques, mais elles ont toutes échoué en raison de problèmes que Bitcoin a résolus plus tard. L'un de ces problèmes est le problème de la double dépense, que le bitcoin a été le premier à résoudre de manière décentralisée. Cela se produit lorsqu'une personne dépense deux fois une unité monétaire. Ainsi, l'une des transactions est invalidée ultérieurement, ce qui fait perdre de l'argent au destinataire de la transaction invalidée. Bitcoin est également à l'origine de l'invention de la blockchain, qui a été utilisée pour résoudre le problème de la double dépense. La blockchain est une structure de données chargée de stocker toutes les transactions Bitcoin. Il permet la validation de toutes ses transactions à toute personne y ayant accès, mais nous y reviendrons plus tard. Le Bitcoin a également introduit le concept de pénurie numérique. Cela signifie que contrairement aux fichiers de votre ordinateur qui peuvent être copiés et distribués indéfiniment, Bitcoin ne peut être transféré que par son propriétaire et ne peut pas être copié et distribué librement. 4. Transactions et clés privées de Bitcoin: Nous allons maintenant approfondir un peu les détails internes du Bitcoin. Je vais expliquer le Bitcoin du micro au macro. C'est-à-dire que je parlerai transactions Bitcoin et des clés privées, puis un peu de la blockchain et du minage. Ensuite, je terminerai l'aperçu en expliquant l'écosystème Bitcoin. Commençons donc par la question suivante : où sont la cryptomonnaie et le système ? Ou en d'autres termes, où se trouve le Bitcoin avec un b minuscule dans le système ? La réponse est que c'est dans une transaction. Cette figure montre une transaction Bitcoin courante avec une entrée et deux sorties. Une transaction Bitcoin peut avoir de nombreuses entrées et sorties, mais dans de nombreux cas, elles n'ont qu'une entrée et deux sorties. Dans une transaction Bitcoin, nous avons les informations d' où le Bitcoin est entré en entrée et où le Bitcoin va en sortie. Dans cet exemple, l' entrée zéro contient une instruction indiquant que cette entrée provient de John, elle a été signée par John et qu'elle contient un Bitcoin. La première sortie, appelée sortie zéro, indique à Mary qu'elle contient 0,9 Bitcoin. Dans la première sortie, il est indiqué que John contient 0,099 Bitcoin. Cette sortie correspond à la modification de la transaction. Dans la plupart des cas, nous devons inclure une modification, car lorsque vous dépensez du Bitcoin lors d'une transaction, vous devez dépenser toutes les unités provenant de l'entrée. Cela génère donc la nécessité de créer une sortie supplémentaire , à savoir le changement. Donc, si votre entrée contient plus de bitcoins, que vous souhaitez envoyer à une autre personne, vous devez créer une sortie supplémentaire, la modification pour vous-même. Nous avons le concept d'UTXO, qui signifie un résultat de transaction non dépensé. Un bitcoin se trouve plus précisément dans un UTXO. Une entrée de transaction doit faire référence à un UTXO d' une transaction précédente pour pouvoir dépenser ce Bitcoin dans cette transaction. Si vous remarquez que la somme des quantités de sorties est inférieure à la quantité de l'entrée. Pourquoi ça ? La différence est due à des frais mineurs. Chaque transaction en bitcoins doit séparer un montant pour les frais mineurs afin que votre transaction puisse être incluse dans la blockchain par un mineur. Le montant des frais de transaction est donc la différence entre la somme des Bitcoins présents dans les sorties et la somme des Bitcoins présents dans les entrées. Une autre information importante est que le Bitcoin peut être divisé en 100 millions de Satoshi. Par conséquent, dans cet exemple de transaction, nous aurions pu dire que les entrées contenaient 100 millions de Satoshi, la sortie zéro contient 90 millions de Satoshi et la sortie contient 9 900 000 De Satoshi. La redevance mineure était de 100 000 Satoshi. Voici d'autres exemples de transactions en bitcoins. Je les ai mis ici juste pour montrer que vous pouvez avoir des transactions avec plus d' une entrée et une sortie. Par exemple, vous pouvez avoir une transaction avec deux entrées et une sortie. Cette transaction n'a aucune modification. Vous pouvez avoir une transaction avec deux entrées et deux sorties. Dans ce cas, la transaction comporte des entrées provenant de deux personnes différentes et des sorties pour deux personnes différentes. Ce type de transaction spécifique est appelé transaction Coinjoin agit d'un type de transaction qui améliore la confidentialité car vous ne pouvez pas lier des entrées spécifiques à des sorties spécifiques. Vous pouvez avoir une transaction avec trois entrées et deux sorties. Il existe d'autres types de transactions, telles que les transactions à signatures multiples , dont nous ne parlerons pas maintenant, mais nous les inclurons peut-être plus tard dans une section de cours supplémentaire si la demande est suffisante. Voyons un peu plus en détail les détails d'une transaction. Dans cette image, il y a deux transactions, la transaction 1 et la transaction 2. Les deux transactions ont une entrée et une sortie. L'entrée comporte trois champs, l' identifiant de transaction précédent et le numéro de sortie d'une transaction précédente, ainsi qu'une signature valide. La sortie comporte deux champs, destin, adresse et quantité, qui font référence au montant de Bitcoin contenu dans la sortie. Dans ce cas, l'entrée de la transaction 2 dépense la sortie zéro de la transaction 1. Pour ce faire, saisissez-en un de la transaction à qui doit référence à l' ID de transaction de la première transaction. Il doit également faire référence au numéro de sortie de la première transaction, qui dans ce cas est zéro. Enfin, il doit contenir une signature valide produite avec la clé privée utilisée pour dériver l'adresse de destination à partir de la sortie zéro. Nous verrons plus de détails sur cette opération dans la diapositive suivante. Comme vous pouvez le constater, les clés privées sont un élément fondamental du Bitcoin. Les clés privées sont utilisées pour recevoir et envoyer des bitcoins à recevoir. Les clés privées sont transformées en clés publiques par multiplication par courbes elliptiques. Ensuite, après une fonction de hachage, les clés publiques sont transformées en adresses Bitcoin. Il s'agit des adresses Bitcoin que vous pouvez montrer à d'autres personnes pour recevoir des Bitcoins. Les clés privées sont également utilisées pour attribuer des transactions Bitcoin. Les signatures sont nécessaires pour transférer des Bitcoins d'une adresse à une autre. Dans cette image, nous avons une transaction non signée. Lorsque nous combinons la clé privée avec une transaction d'initié à l'aide l'algorithme de signature numérique Elliptic Curve, ECDSA, nous produisons une signature que nous incluons dans cette transaction. Elle devient ainsi une transaction signée. La même clé privée qui a produit l'adresse renvoyée à un zéro en entrée est également utilisée pour déverrouiller ces fonds et la transaction en cours en produisant la signature. Ainsi, une clé privée est utilisée indirectement pour bloquer des fonds dans une adresse et pour débloquer des fonds provenant de la même adresse en produisant une signature. important à propos des clés privées et leurs transformations est que vous ne pouvez pas produire de clé privée à partir d'une clé publique, et vous ne pouvez pas produire de clé publique à partir d'une adresse Bitcoin. Vous ne pouvez pas non plus générer de clé privée à partir d'une signature. Ces opérations ne se font que dans un seul sens, comme le montrent ces flèches. Une autre caractéristique importante des transactions Bitcoin est que toute personne ayant accès à une transaction peut valider les signatures. Cela est possible car si vous avez une clé publique, la signature et le message, qui dans ce cas constituent la transaction. Vous pouvez vérifier si une signature est valide pour cette clé publique. Et une signature n'est valide pour une clé publique que si elle a été produite avec une clé privée qui produit la même clé publique. 5. Portefeuilles Bitcoin, la chaîne de blocs et l'exploitation: Maintenant que vous avez des connaissances de base sur les clés privées, nous pouvons commencer à parler de portefeuilles. Un portefeuille Bitcoin est, en bref, une collection de clés privées. Il existe de nombreux types et normes de portefeuilles. Les portefeuilles ont un développement indépendant par rapport d'autres logiciels Bitcoin tels que les nœuds. Une règle de base pour posséder des bitcoins n'est pas le mantra. Vos clés, vos bitcoins, pas vos clés, pas vos Bitcoins. En effet, le propriétaire d' une clé privée peut transférer des Bitcoins verrouillés par sa clé privée et d'autres transactions. Quels sont les points communs des portefeuilles Bitcoin ? Ils disposent d'un moyen sûr de générer et de stocker des clés privées. Ils peuvent communiquer avec les nœuds Bitcoin. Ils peuvent créer, signer et envoyer des transactions Bitcoin. Ils peuvent générer des adresses Bitcoin. Notez que la plupart de ces capacités sont possibles grâce à des transformations de clés privées. Toutes les opérations utilisant des clés privées peuvent être effectuées hors ligne. vous suffit d'être en ligne lorsque communiquez avec les nœuds Bitcoin pour récupérer des informations de la blockchain et envoyer des informations à la blockchain. En parlant de blockchain, voyons enfin ce que signifie ce mot à la mode. La blockchain a été utilisée pour résoudre le problème de la double dépense de manière décentralisée. ce faire, il organise les transactions dans une chaîne de blocs afin que blocs valides ne puissent pas contenir de transactions avec un UTXO apparaissant dans le même bloc ou dans les blocs précédents. Pour comprendre ce qu'est la blockchain, examinons cette figure. Ces blocs représentent des blocs de la blockchain. Certaines de leurs données sont représentées dans ces petits rectangles. À l'intérieur de chaque bloc. Un bloc est composé de nombreuses transactions, un champ appelé hash précédent, qui, comme son nom l'indique, est le hachage du bloc précédent. Un champ appelé timestamp, qui stocke la date à laquelle le bloc a été créé, et un champ appelé nonce, dont nous parlerons dans la diapositive suivante. Chaque bloc produit un hachage qui est inséré dans le bloc suivant. Les blocs sont créés et ajoutés à la blockchain dans le cadre d'un processus appelé minage. minage est le processus par lequel les blocs sont inclus dans la blockchain. Les nœuds qui effectuent ce processus sont appelés mineurs. Pour inclure des blocs dans la blockchain, les mineurs doivent collecter les transactions et les organiser en bloc. Ensuite, les mineurs doivent résoudre le Proof of Work, qui est un algorithme nécessaire pour produire des blocs valides. La preuve de travail comprend les étapes suivantes. abord, un bloc est haché, puis le nombre de zéros initiaux du hachage obtenu est vérifié. Si ce nombre est supérieur ou égal au nombre de zéros nécessaire pour inclure le bloc dans la blockchain. Le bloc est inclus dans la blockchain. Si ce n'est pas le cas, le mineur modifie le nonce et répète le processus. C'est donc la fonction du nonce. Son seul objectif est de permettre à un bloc de produire différents hachages. La preuve de travail présente une caractéristique intéressante. Plus il faut de zéros pour obtenir une preuve de travail valide, plus il est difficile de la trouver. Cela rend la difficulté du minage facilement ajustable. En Bitcoin, la difficulté de minage est automatiquement ajustée, sorte que le temps moyen pour miner un bloc est de 10 minutes. Lorsqu'un mineur perçoit un bloc, il gagne une récompense par bloc et tous les frais de transaction par bloc. La récompense par blocs est le seul moyen de créer de nouveaux bitcoins. Il diminue de moitié tous les quatre ans lors d'un événement appelé avoir. Ainsi, tous les quatre ans, l'offre de nouveaux Bitcoins émis se raréfie. Et il est calculé que le dernier bitcoin sera extrait vers 21h40, date à laquelle l'offre totale de bitcoins sera égale à 21 millions. 6. Le réseau Bitcoin, l'écosystème et les principes: Parlons maintenant du réseau Bitcoin. Voyons les étapes de base du fonctionnement du réseau Bitcoin. Tout d'abord, les nouvelles transactions sont envoyées aux nœuds. Chaque mineur rassemble les transactions dans un bloc. Chaque mineur essaie de trouver une preuve de travail le plus rapidement possible. Lorsqu'un mineur trouve une preuve de travail, il diffuse son bloc mental sur le réseau. Les autres nœuds vérifient si le bloc est valide. Pour qu'un bloc soit valide, il doit respecter toutes les règles de consensus, telles que toutes les transactions, et il doit être valide et le hachage du bloc précédent doit être égal au cache de blocs du dernier bloc valide. Si le bloc est valide, les nœuds l'ajoutent à leur Blockchain. Copie. Petit début de travail sur de nouveaux blocs en utilisant le champ de hachage du dernier bloc mental comme hachage précédent. Vous vous demandez peut-être ce qui se passe si deux mineurs extraient un bloc valide en même temps. Eh bien, lorsque cela se produit, cela provoque une scission du réseau. Une partie des nœuds contiendra une version de la blockchain avec un bloc provenant d'un mineur et l'autre partie du réseau contiendra un bloc provenant de l'autre mineur. Mais cette scission n'est que temporaire. Lorsque le bloc suivant est miné, les deux groupes de nœuds considéreront uniquement la blockchain contenant plus de blocs comme la vraie blockchain et l'autre blockchain sera supprimée, la probabilité que la division du réseau persiste et diminue avec le temps. Il est donc prudent de supposer qu'après six blocs une transaction est définitivement réglée dans la blockchain. L'immuabilité et la sécurité des transactions en Bitcoin reposent sur le fait qu'il est presque impossible de produire une blockchain valide avec plus de blocs que la chaîne d'origine. Un tel exploit nécessiterait une énorme puissance de calcul pour dépasser la vitesse de génération de blocs du réseau d'origine pendant un temps suffisant. Maintenant que nous avons découvert les différentes parties du Bitcoin, voyons comment elles interagissent au sein de l'écosystème Bitcoin. Les utilisateurs de Bitcoin contrôlent les portefeuilles. Comme vous l'avez appris, les portefeuilles sont des collections de clés privées. Et ces clés privées peuvent être utilisées pour signer des transactions et pour générer des adresses pour recevoir des transactions. Les bourses peuvent échanger des bitcoins contre d' autres cryptomonnaies et devises fiduciaires, telles que le dollar. Vous pouvez également échanger des bitcoins contre des marchandises auprès de commerçants. Quelle que soit la personne avec laquelle vous effectuez des transactions, toutes vos transactions sont envoyées aux nœuds Bitcoin. Lorsqu'un mineur voit votre transaction, il peut l'inclure dans un bloc. Le mineur crée un bloc avec de nombreuses transactions et procède à l'extraction du bloc. C'est-à-dire qu'il commence à calculer la preuve de fonctionnement du bloc à l'aide de son matériel. Lorsqu'un mineur trouve enfin la preuve de travail par bloc, il diffuse le bloc à d'autres nœuds Bitcoin. Les autres nœuds reçoivent le mind block récemment et sont validés. Si le bloc est valide, les nœuds l'ajoutent à leur copie de la blockchain. De cette façon, le réseau parvient un consensus sur l' état actuel de la blockchain. Parlons des principes du Bitcoin. Les principes du Bitcoin sont importants pour comprendre les décisions techniques prises lors du développement du Bitcoin. L'un de ces principes est l'offre maximale de 21 millions de Bitcoins. Cette limite a été fixée au début du projet. modifier provoquerait ces arrangements dans l'économie du Bitcoin. Il est donc important de continuer ainsi. La résistance à la censure est un autre principe important du Bitcoin. Le fait que de nombreuses personnes puissent gérer des nœuds Bitcoin rend presque impossible pour une autorité de fermer le réseau. Les développeurs de bitcoins apprécient une forte résistance à la censure. L'open source est un autre principe du Bitcoin. Vous pouvez trouver le logiciel Bitcoin Core gratuitement sur le site Web de GitHub. Comme beaucoup d'autres développeurs, vous pouvez vérifier le code et vérifier qu'il ne contient pas de bogues. Vous pouvez également participer à son développement. Bitcoin dispose d'une solide communauté de développeurs responsables de sa sécurité et de ses nouvelles fonctionnalités. Et c'est le fait d'être open source qui le permet. Le Bitcoin est sans autorisation, ce qui signifie que n'importe qui est autorisé à gérer un nœud Bitcoin, à miner et à effectuer des transactions en bitcoins. C'est l'une des plus grandes forces du Bitcoin et ce qui le rend si populaire aujourd'hui dans le monde entier. Les transactions en bitcoins sont pseudonymes. Cela signifie qu'aucune information présente dans une transaction Bitcoin ne peut à elle seule être connectée à des personnes. Contrairement à l'exemple du début de l'aperçu, cela aurait pu suggérer que les transactions Bitcoin ne contiennent pas les noms et identifiants des destinataires et des expéditeurs. Une transaction Bitcoin affiche uniquement les transferts entre adresses Bitcoin, qui ressemblaient à des collections aléatoires de caractères. Si quelqu'un découvre qu' une adresse appartient à une personne en particulier, il peut suivre le montant de Bitcoin et les autres transactions de cette personne. Mais c'est une autre histoire. Le Bitcoin vise une fongibilité élevée. fongibilité est une caractéristique qui permet à une unité monétaire d' être évaluée de la même manière que toute autre unité de la même devise. Cela signifie que, idéalement, chaque Bitcoin est évalué et traité de la même manière. On soutient souvent que le Bitcoin n' est pas fongible car Bitcoins provenant de différentes transactions peuvent être retracés et traités différemment. Je dirais que même si cela est vrai dans la pratique, la plupart des bitcoins sont traités de la même manière et vous avez des moyens de rendre les transactions plus privées et fongibles. irréversibilité des transactions est un autre principe du Bitcoin. Une fois qu'une transaction est réglée dans la blockchain, elle ne peut pas être annulée. Il s'agit d'une caractéristique de sécurité importante car elle rend le Bitcoin difficile à confisquer. Mais cela transfère également la responsabilité d'une transaction au centre Bitcoin. D'où la nécessité de protéger vos clés privées. 7. 5 Commencer le projet skillshare 2: Dans cette vidéo, nous allons mettre en place un nouveau projet Spring Boot qui sera notre portefeuille Bitcoin. Pour ce faire, nous utiliserons l'outil Spring Initializer du site web start point spring point io. Entrez donc sur le site Web. Choisissez le projet Maven. Le langage est Java, j' utiliserai cette version de Spring Boot, mais si elle n'est pas disponible pour vous, vous pouvez choisir celle par défaut comme nom de groupe. Vous pouvez définir le nom que vous voulez. Dans mon cas, je vais le définir comme un portefeuille à points BYOD. J'utiliserai BYOD W comme nom de l'artefact, comme description. J'utiliserai le portefeuille Bitcoin. Nous utiliserons la dernière version de Java. Si vous ne connaissez que les versions précédentes de Java, ne vous inquiétez pas, les anciennes fonctionnalités de Java fonctionnent toujours sur la dernière version car Java est rétrocompatible. Enfin, cliquez sur Générer pour télécharger le projet, ouvrir et extraire son contenu dans le dossier de votre choix. Maintenant, nous allons ouvrir le projet en utilisant une idée intelligente. Après avoir démarré le programme, cliquez sur Ouvrir, puis choisissez le dossier que vous venez d'extraire. Cliquez sur Trust Project. Attendez qu'IntelliJ Idea indexe tous les fichiers du projet. Ensuite, vous pouvez explorer les fichiers créés automatiquement par Spring Initializer. Pour vérifier si le projet a été correctement configuré. Cliquez sur Maven sur le côté droit de l'écran. Ensuite, dans le dossier du cycle de vie, double-cliquez sur Test. Oups, nous avons eu une erreur Maven. Pour résoudre cette erreur, cliquons sur la boîte de dialogue de configuration. Changeons le chemin d'origine de Maven en Maven Three groupé. Cliquez ensuite sur Appliquer. D'accord. Avant de cliquer à nouveau sur tester, je vais vérifier si la structure de mon projet a été correctement configurée. Je vais donc cliquer sur Fichier. Ensuite, la structure du projet garantit que le SDK du projet possède la version Java que vous avez choisie ( Spring Initializer). Si ce n'est pas le cas, cliquez sur Ajouter un SDK et téléchargez le SDK, choisissez la bonne version de Java et l'une de ses implémentations cliquez sur Télécharger. Dans mon cas, je ne le ferai pas car j'ai déjà la bonne version. Je vais donc cliquer sur Annuler. Assurez-vous que le niveau de langue du projet est également défini sur la bonne version de Java. Maintenant, relançons le test. Attendez que le test réussisse. Génial. La console indique que le test est réussi. Nous sommes prêts à commencer à travailler sur notre portefeuille. 8. 6 Configurer le partage de compétences de l'interface graphique 2: Dans cette vidéo, nous allons commencer à créer la première fenêtre de notre portefeuille. Pour ce faire, nous allons d'abord ajouter quelques dépendances à notre projet. Ouvrez le fichier XML Palm Dot à la racine du projet. Le fichier XML Palm Dot contient toutes les dépendances externes du projet. Nous allons ajouter quelques dépendances Java FX. Java FX est un framework responsable des fonctionnalités de l'interface utilisateur graphique. Il est très connu dans la communauté Java. La version est 16. La dépendance suivante est JavaFX, FXML. La version est également 16. Nous ajouterons également un plugin. C'est ce qu'on appelle le plugin Java FX Maven. Sa version est 0.0, 0.6. Pour charger ces dépendances dans votre projet, cliquez sur cette icône. Le projet a chargé toutes les dépendances. Nous allons maintenant créer le code nécessaire au démarrage de notre application. Ce processus nécessite une certaine coordination entre les modes de démarrage de Spring Boot et des effets Java. Pour ce faire, nous allons d'abord créer une nouvelle classe Java appelée application GUI. Cette classe doit étendre la classe d'application à partir des effets Java. Et nous devons implémenter la méthode de démarrage à partir de la même classe. Nous allons ajouter une propriété privée avec le type de contexte d'application configurable. Nous utiliserons Next. Nous allons ajouter ici la méthode init, qui est exécutée avant la méthode start, lors de l' initialisation de l'application. Le code que je viens de taper est responsable de l' initialisation des dépendances injectées par notre application Spring Boot . Passons maintenant à la classe d'application BYOD W. Modifions la méthode principale. La méthode principale de cette classe est la première méthode appelée lorsque nous exécutons notre application. Lorsque le code que je viens de taper est exécuté, il appelle d'abord la méthode init de la classe d'application GUI plutôt que la méthode start de la même classe. Revenons à la classe d'application GUI. Continuons à implémenter la méthode start. Nous allons maintenant appeler la méthode publish event sur la propriété context, transmettant un nouvel objet d'événement lancé dans l'interface graphique, qui créera next comme argument. Créons la classe d'événements Gooey Started. Nous allons le créer dans un nouveau dossier d'événements. En raison de la façon dont nous avons créé cette classe, l'ID savait déjà quelle classe nous devions étendre et il a automatiquement créé le code standard qui aura besoin d'être très pratique, n'est-ce pas ? Nous allons maintenant continuer à implémenter notre constructeur. Nous appellerons le super constructeur en passant un objet d'application GUI comme argument. Et nous allons assigner l'étape principale de l'argument à la scène. La propriété privée créera également un écouteur pour cette classe d'événements dans un package appelé listeners. Nous allons ajouter l' annotation du composant à cette classe. Vous verrez souvent cette annotation tout au long du parcours. Il provient de Spring Boot et son but est de rendre un objet d'une classe disponible pour l'injection. Les autres objets du projet implémenteront également l' interface d'écoute de l' application . pour cette classe, en transmettant l' événement gooey started en tant que paramètre de type. Cela est nécessaire pour que Spring Boot interprète cette classe comme un écouteur d'événements pour un événement commencé de manière gluante. Nous allons maintenant implémenter la méthode requise pour l'interface. Il aura également besoin d'un constructeur. Ce constructeur prendra un objet ressource avec une annotation de valeur pointant vers un fichier appelé point FXML de la fenêtre principale, qui sera ajouté ultérieurement au projet. Le constructeur prendra également un argument de contexte d'application. Ensuite, nous initialiserons avec des propriétés privées portant le même nom que les arguments du constructeur. Les deux propriétés seront définitives. Très bien, maintenant que nos dépendances sont injectées dans cette classe, implémentons le code de la méthode d'événement de l'application. Ce code sera chargé d'afficher la fenêtre principale de notre portefeuille lorsque nous démarrerons le programme. Nous allons donc d'abord instancier un objet chargeur FXML. Ensuite, nous obtiendrons l'objet de scène à partir de l'événement de démarrage de l'interface graphique. Pour cela, nous allons ajouter la méthode gets stage à la classe d'événements gooey Started. Cette méthode renverra l'objet de scène. Nous ajouterons un titre au portefeuille en utilisant la méthode set title de l'objet de scène. Il peut s'agir de n'importe quelle chaîne de caractères. Je vais le définir comme portefeuille BYOD W. Ce texte sera affiché dans la barre supérieure de la fenêtre des programmes. Appelera également la méthode set scene, en transmettant un nouvel objet de scène comme paramètre instancié avec un objet renvoyé par une nouvelle méthode qui créera un FXML appelé initialize. Cette méthode commencera à déclarer une variable du type parent appelée root. Ensuite, dans un bloc try catch vous utiliserez la méthode set location à partir de la variable du chargeur FXML en transmettant l'emplacement URL de notre propriété FXML. Nous allons définir la fabrique de contrôleurs du chargeur FXML sur une référence de la bonne méthode bean de la propriété context. Cela est nécessaire pour que le framework JavaFX reconnaisse les classes de contrôleurs annotées avec l'annotation Component. Nous définirons également la variable racine du résultat de l'appel de la méthode de chargement du chargeur FXML qui détectera une IOException et la lancera encapsulée dans une exception d'exécution. Nous allons renvoyer la variable racine. Enfin, dans la méthode sans application vous appellerez la méthode show de l'étape, ce qui fera apparaître la fenêtre à l'écran. Nous allons maintenant créer le fichier FXML, mais nous avons fait référence à l'annotation de valeur de la propriété FXML du constructeur de l' écouteur. Et le fichier FXML est un type de fichier utilisé pour coder les éléments de l'interface graphique d' une application JavaFX. Comme un fichier HTML, encode les pages Web, les fichiers FXML et les fenêtres d'effets de code Java créeront ce fichier dans le nouveau chemin FXML qui le créera. Ce répertoire sera situé dans le chemin des ressources. Nous l'appellerons point de la fenêtre de soulignement principale FXML. Supprimons le standard généré automatiquement. Ajoutons une balise au volet de bordure. Nous y ajouterons quelques attributs. Ajoutera un identifiant Fx qui permettra de faire référence à la balise Border Panel dans sa classe de contrôleur, qui sera créée ultérieurement. Ajoutons quelques attributs pour définir la taille de la fenêtre. Enfin, nous allons ajouter quelques attributs métalliques pour définir le schéma du fichier. C'est ça Lancer l'application pour voir si tout s'est bien passé. Dans l'onglet Maven, cliquez sur les plug-ins, Spring Boot et Spring Boot s'exécutent. Génial. La première fenêtre de notre portefeuille s'affiche à l'écran. Bon travail. 9. 7 Créer notre première partie de portefeuille 1 skillshare 2: Dans cette vidéo, nous allons commencer à tester la première fonctionnalité de notre portefeuille. La première fonctionnalité de notre portefeuille sera la possibilité de créer un portefeuille. Plus précisément, nous allons créer un menu avec un bouton qui, une fois cliqué, fera apparaître une boîte de dialogue à l'écran. Cette boîte de dialogue contiendra initialement un champ de texte dans lequel l'utilisateur définira le nom du portefeuille et un bouton Créer qui, une fois cliqué, générera une graine mnémotechnique aléatoire. J'apprendrai ce qu'est la graine mnémotechnique. Dans la vidéo suivante, nous allons créer chaque fonctionnalité de notre portefeuille en utilisant l' approche TDD ou développement piloté par les tests. Cette approche consiste à créer d' abord un test d' intégration, qui décrit ce que nous voulons obtenir pour cette fonctionnalité. Ensuite, nous allons implémenter la fonctionnalité et exécuter le test jusqu'à ce qu'il soit réussi. Au cours de la mise en œuvre, nous pouvons rencontrer des situations dans lesquelles nous devons créer de nouvelles classes ou méthodes pour nous aider à atteindre nos objectifs. Si tel est le cas, nous créerons des tests unitaires pour ces classes de méthodes et les implémenterons à l'aide de TDD. À la fin de chaque cycle TDD, nous refactoriserons notre code si nécessaire. Voyons comment cela fonctionne dans la pratique. Mais d'abord, ajoutons quelques dépendances à notre projet. Nous allons ajouter quelques dépendances liées au framework Spark. Le framework Spark est un framework de test en groovy, un langage de programmation compatible avec Java. Il contient des fonctionnalités qui facilitent les tests de construction utilisera également une version de test FX compatible avec Spock. Test fx est un framework qui fournit des fonctionnalités pour tester les applications JavaFX. Maintenant, ajoutons la version 3.0, 0.6 de Groovy à notre fichier POM. Et ajoutons-y Spock Spring. La version sera 2.0, Groovy 3.0. Son champ d'application sera testé. La prochaine dépendance à ajouter est Spark Core. La version sera la même que celle de Spock Spring. Le scope sera testé. La prochaine dépendance sera le test FX Spock. Sa version sera 4.0, 0.16 alpha ajoutera également un plugin G Maven. OK, j'ai oublié de mettre la bonne lunette et de tester la dépendance aux effets. Nous ajouterons également quelques objectifs dans le plugin GI Maven. Il faudra que Groovy fonctionne correctement. Nous allons maintenant apporter une modification au fichier de propriétés des points de l'application. Spring crée par défaut un serveur Web, mais nous n'en aurons pas besoin dans notre application. Nous devons donc attribuer à cette propriété la valeur none. Spring ne créera donc pas de serveur Web au démarrage. Nous allons maintenant créer notre premier test. Mais d'abord, supprimons ce fichier. Le test d' application BYOD W, généré automatiquement par Spring Initializer, créera un package dans ce dossier appelé gooey qui contiendra tous nos utilisateurs graphiques tests d'interface. Dans ce package, nous allons créer le test. Mais d'abord sur le fichier XML Palm Dot, cliquez sur le bouton Charger Maven Changes. Maintenant, l'IDE va nous permettre de créer des classes géniales. Créons-en donc un appelé Create Wallet Test. Nous ajouterons à cette classe une annotation de test Spring Boot qui étendra cette classe avec la classe de spécification de l'application. Cela est nécessaire pour que Spring Boot et test fx considèrent cette classe comme une classe de test. Chaque test d'intégration doit contenir cette annotation et cette extension. Nous devons implémenter la méthode de démarrage à partir de la spécification de l'application. Nous mettrons également en œuvre les méthodes d'unité et d'arrêt. À l'intérieur de la méthode init, vous ajouterez ce code nécessaire à l'initialisation du test. À l'intérieur de la méthode d'arrêt, vous trouverez un code nécessaire pour arrêter le test. Dans la méthode stark, nous devons inclure le code nécessaire pour afficher le premier écran de notre application. Ce code sera similaire au code présent dans la classe d'écoute démarrée par l'interface graphique. Nous allons donc instancier un chargeur FXML passant l'URL FXML comme argument, puis nous créerons la propriété privée FXML avec la même annotation de valeur présente dans la classe d' écouteur démarrée par l'interface graphique. Groovy transforme chaque méthode avec getter défini dans une propriété d'objet, nous pouvons utiliser cette URL ici. Au lieu de get URL, la propriété factory du contrôleur sera définie sur la référence contextuelle de la méthode get bean. Ajoutons le champ contextuel à la classe. Ci-dessus. Cela mettra l'annotation câblée automatique. Cette annotation est nécessaire pour que Spring Boot injecte l'objet de contexte de l'application depuis son conteneur d'injection de dépendances dans cette variable. Ensuite, nous allons créer la variable racine à l'aide de la méthode de chargement du chargeur FXML. Ensuite, nous définirons le titre de la scène, la scène et appellerons la méthode Stage Show tout comme le code contenu dans l'écouteur gooey a démarré. D'accord, nous sommes prêts à travailler sur le code de notre premier test. Le nom du test sera «  devrait créer un portefeuille ». Le test contiendra les exigences de la fonctionnalité que nous voulons implémenter utilisera le mot clé pour décrire les actions que l'utilisateur du test effectuera. Mettons-le donc en œuvre. L'utilisateur cliquera sur un bouton dont le texte est connu. Ensuite, vous cliquerez sur un bouton contenant le portefeuille de texte. Ensuite, sur un champ de texte avec un identifiant FX. Lorsque nous voulons faire référence à un identifiant FX, nous mettons le nom de l'identifiant après un signe dièse comme celui-ci. Ensuite, l'utilisateur écrira les mots MyText wallet. Ensuite, il cliquera sur un bouton contenant le texte de création. Ensuite, le test recherchera le contenu d' un champ de zone de texte portant l'identifiant éthique d'une graine mnémonique. Il attribuera le contenu de ce champ à la variable de départ mnémotechnique. Enfin, nous utiliserons le mot clé pour définir ce à quoi nous nous attendons fois que l'utilisateur aura effectué toutes les actions à l'intérieur du wind block. Nous nous attendons à ce que la variable de départ mnémonique contienne une valeur non nulle. Pour ce faire, il suffit de placer la variable de départ mnémotechnique dans le bloc then. Si la valeur mnémotechnique est définie, le bloc sera évalué comme vrai et le test sera réussi. Sinon, il sera évalué comme faux et le test ne réussira pas. Faisons ce test pour voir ce qui se passe. Tout d'abord, nous allons cliquer sur Construire plutôt que sur Reconstruire le projet pour nous assurer que l'IDE charge toutes les modifications que nous avons apportées au code. Ensuite, nous cliquerons sur Test dans l'onglet Maven Config. *****. L'IDE s'est à nouveau plaint de Maven, corrigeons cela rapidement. À présent. Faisons à nouveau le test. Le test a échoué comme prévu. Avez-vous remarqué qu' une fenêtre s'est rapidement affichée à l'écran pendant le test ? Cela montre au moins que notre fenêtre est ouverte. Regardons les résultats de nos tests sur la console. Il indique que la nouvelle requête ne renvoie aucun nœud. Le test a ouvert notre application, puis a essayé de trouver un élément dont le texte était connu car il ne l'a pas trouvé, il a rapidement échoué et a fermé l'application. Dans la vidéo suivante, nous allons apprendre ce qu'est une graine mnémotechnique. Ensuite, dans la vidéo qui suit, nous créerons notre premier portefeuille et ferons passer ce test. On se revoit. 10. Graines de Mnemonic: Dans cette vidéo, nous allons en apprendre davantage sur les graines mnémotechniques. Alors, qu'est-ce que la graine mnémotechnique ? Une graine mnémotechnique est une phrase contenant 121-51-8201 ou 24 mots. Il est utilisé pour obtenir tous les portefeuilles, clés privées et adresses. Les règles de génération de graines mnémotechniques que nous utiliserons sont décrites dans la proposition d'amélioration du Bitcoin 39 ou BIP 39. De nombreux portefeuilles ont utilisé les règles BIP 39 pour générer des graines mnémotechniques. Les graines mnémotechniques sont combinées avec la chaîne mnémonique plus un mot de passe optionnel pour produire une graine racine représentée ici au format hexadécimal. Le mot de passe facultatif est communément appelé phrase secrète, mais nous utiliserons le mot mot de passe pour des raisons de simplicité. Ensuite, à l'aide d'autres algorithmes, le root seed génère des clés privées, des clés publiques et des adresses, apprendra les détails de ces opérations dans une vidéo ultérieure. Concentrons-nous maintenant sur la façon dont les graines mnémotechniques sont générées. Pour générer une graine mnémotechnique, il faut d'abord générer une séquence aléatoire de bits appelée entropie d'une longueur égale à 128 bits. Si nous voulons une graine mnémotechnique de 12 mots, 160 bits, si nous voulons une graine de 15 mots, 192 bits, si nous voulons une graine de 18 mots, 224 bits si nous en voulons une de 21 mots ou 256 bits, si nous en voulons une de 24 mots, puis nous calculons la somme de contrôle. Pour ce faire, nous calculons la longueur de l'entropie divisée par 32 et obtenons la taille de la somme de contrôle. Ensuite, nous obtenons les premiers bits de la taille de la somme de contrôle du hachage SHA-256 de l'entropie. Le résultat est le checksum. La somme de contrôle est utilisée pour vérifier si une graine mnémotechnique donnée est valide. Nous ajoutons la somme de contrôle à la fin de l'entropie initiale. Le résultat est divisé en groupes de 11 bits. Chaque groupe de 11 bits est converti en un nombre 0-2047. Ces nombres sont utilisés comme index dans une liste de mots. Les mots correspondants forment la graine mnémotechnique. 11. 9 Créer notre première partie de portefeuille 2 skillshare 2: Dans cette vidéo, nous continuerons à implémenter la fonctionnalité de création de portefeuille de notre application. La première étape consiste à ajouter un bouton avec le nouveau texte écrit dessus. Faisons ça. Ouvrez le fichier FXML à points de la fenêtre principale. Désormais, nous utiliserons l'outil IDE Scene Builder pour créer les fenêtres de notre projet. Scene Builder nous permet de créer l'interface utilisateur graphique de notre application de manière interactive et simple. Cliquez sur le bouton Scene Builder en bas de l'écran. Dans mon cas, cette fenêtre est apparue. Mais si vous n'avez pas installé Java FX ou Scene Builder , un bouton pour les télécharger apparaîtra en haut de votre écran. Après les avoir téléchargées et installées, cette fenêtre s'affiche. Nous allons maintenant ajouter une barre de menu supérieure à la fenêtre principale. Pour ce faire, cliquez sur les commandes, puis glissez et déposez le composant de la barre de menu vers la partie supérieure du menu du volet de bordure ci-dessous. Nous allons maintenant avoir une barre de menu avec trois éléments de menu. Supprimons les modifications et celles d'aide. Changeons le menu Fichier intitulé « deux nouveaux ». Génial. Nous avons maintenant notre nouveau bouton. Regardons notre test pour voir ce qu'il faut faire ensuite. La prochaine action que fera notre utilisateur est de cliquer sur le bouton du portefeuille. Créons-le. Revenez à la fenêtre principale. Nous ajouterons un élément de menu dans le nouveau menu. Dans ce cas, nous avons déjà un élément de menu. Changeons donc son étiquette en portefeuille. Lorsque l'utilisateur clique sur le bouton du portefeuille, une nouvelle fenêtre de dialogue doit apparaître. Implémentons-le dans le Scene Builder. Cliquez sur l'élément du menu du portefeuille. Nous allons ajouter une action à ce bouton. Cliquez sur Code, tapez Ouvrir la boîte de dialogue de création de portefeuille. Si nous cliquons sur le bouton Texte en bas de l'écran et vérifions le fichier FXML. Nous remarquerons que l'IDE a ajouté l' attribut on action dans la balise d'élément de menu avec la valeur que nous venons de saisir. Maintenant, pour créer une action pour ce bouton, vous devez créer un contrôleur. Mais d'abord, faisons quelques refactorisations dans notre code. Nous allons créer un nouveau package dans le package BYOD W. Appelons-le gooey y transférera les packages d'événements et d' auditeurs, ajoutera toutes les classes liées à l' interface utilisateur graphique de l'application à ce package. De retour à la fenêtre principale, j'ajouterai un attribut de contrôleur FX à la balise Border Panel et le définirons sur le nouveau contrôleur que nous allons créer pour le créer dans un nouveau package de contrôleurs. À l'intérieur de l'emballage gluant. Son nom sera le contrôleur de fenêtre principal. Chaque fichier FXML peut avoir un contrôleur qui est utilisé pour définir les actions qui se produisent en réponse aux interactions de l'utilisateur avec la fenêtre codée par ce FXML. Dans notre cas, le contrôleur de la fenêtre principale contiendra un code qui définira les actions en réponse aux événements de la fenêtre principale. Retournez au fichier FXML à points de la fenêtre principale. Lorsque nous cliquons sur l'attribut de dialogue Ouvrir, créer un portefeuille et que nous appuyons sur Alt et Entrée, l'IDE affiche la possibilité de créer une méthode dans le contrôleur de fenêtre principal. Cliquez sur cette option. L'IDE a automatiquement généré la méthode dans le contrôleur de fenêtre principal. Supprimons l'argument d'événement d'action car nous n'en aurons pas besoin. Cette méthode inclura le code responsable de l' ouverture de la boîte de dialogue de création de portefeuille. Lorsque nous cliquons sur l'élément du menu du portefeuille, nous instancions d'abord un objet de dialogue de type bouton. Ensuite, nous définirons les dialogues dans son propriétaire sur la fenêtre du volet de bordure pour indiquer que le dialogue appartient au volet de bordure de la fenêtre principale. Retournez au fichier FXML à points de la fenêtre principale. Nous pouvons cliquer sur l'attribut Ethics ID de la balise Border Panel, appuyer sur Alt plus Entrée et créer la propriété du volet de bordure dans le contrôleur de fenêtre principal. L'IDE a automatiquement généré la propriété. Définissons-la comme privée et incluons l'annotation FXML au-dessus pour indiquer qu'elle fait référence à un composant FXML. Ensuite, nous définirons le titre du dialogue pour créer un nouveau portefeuille. Maintenant, à l'intérieur d'un bloc try catch, vous instancierez un objet chargeur FXML. Faire passer ces arguments. Nous allons ensuite créer la propriété de dialogue Create Wallet et la propriété context. Ensuite, nous allons créer un constructeur pour initialiser les deux propriétés. Les deux propriétés seront automatiquement injectées par le conteneur d'injection de dépendances Spring qui ajoutera une annotation de valeur à l'argument du constructeur du dialogue create wallet transmettant le chemin d'un FXML. fichier qui sera créé par la suite. Ensuite, nous définirons le contenu du dialogue en fonction du résultat de l'appel de la méthode load du chargeur FXML qui détectera ensuite une IOException et lancera en tant qu'exception d'exécution. Enfin, nous appellerons le dialogue en mode émission et attendrons pour ouvrir le dialogue. N'oubliez pas d' ajouter l' annotation du composant à cette classe. Maintenant, lançons notre application pour voir ce que nous avons jusqu'à présent. Dans l'onglet Maven à l'intérieur des plugins et de Spring Boot, cliquez sur Spring Boot run. Nous avons notre barre de menu supérieure avec le bouton Nouveau et le bouton portefeuille. Lorsque nous cliquons sur le bouton du portefeuille, l' application génère une exception. est parce qu'il n'a pas trouvé le fichier FXML à points de la boîte de dialogue Create Wallet. Créons-le. Après l'avoir créé, cliquez sur Scene Builder. Supprimons ce volet d'ancrage. Faites glisser le dialogue et déposez-le ici. Bon. Ajustons la taille de celui-ci. Cliquez sur Layout. Ensuite, dans le champ pref height, tapez 500, dans le champ pref width, tapez 50. Définissez ensuite la taille de préparation à utiliser sur les champs largeur minimale et hauteur minimale. Ajoutons maintenant un texte d'en-tête à la fenêtre. Dans le champ de texte de l'en-tête, tapez. Donnez un nom à votre portefeuille et cliquez sur Créer. Ajoutons un peu de rembourrage autour. Bon. Ajoutons maintenant un volet quadrillé. Glissez et déposez ce composant dans le menu de dialogue ci-dessous. À l'intérieur de la première cellule du volet de la grille, vous pouvez ajouter une étiquette comme celle-ci. Et cette étiquette contiendra le texte du nom du portefeuille. Nous ajouterons également un champ de texte au volet de la grille. Changeons ses coordonnées, définissons l'index de sa colonne sur un. Ajoutons maintenant un bouton au volet de la grille. Remplacez son index de ligne par un et son index de colonne par un. Changeons son texte pour le créer. Revenons à notre test pour vérifier ce qu'il nécessite d'autre. Il essaiera de cliquer sur un composant dont le nom est un identifiant éthique. Ajoutons donc un identifiant Fx dans le champ de texte. Après cela, il essaiera d'écrire mon portefeuille de texte dans le champ de texte. Ensuite, il cliquera sur un composant le texte Créer, créera avec un C. En cliquant dessus, le test recherchera le contenu d' une zone de texte avec une idée FX d'une graine mnémonique. Créons donc cette zone de texte. Faites-le glisser vers le volet de la grille ci-dessous. Changez ensuite son index de ligne à deux et sa portée de colonne à deux afin que le champ de départ mnémotechnique occupe l'espace de deux colonnes. Bon. Nous ajouterons également une étiquette pour le champ de semences mnémotechniques. Mais d'abord, ajoutons une autre ligne au volet de la grille. Bon. Augmentons l'indice mnémotechnique des rangs des champs de semences à trois. Ensuite, nous allons faire glisser une étiquette vers le volet de la grille. Ajustez son index de ligne à deux, remplacez son texte par une graine mnémotechnique. Ajoutons maintenant un Fx ID de graine mnémonique à la zone de texte. Maintenant, lançons notre application et voyons ce qui se passe. Reconstruisez d'abord le projet et cliquez sur Spring Boot Run. Génial. Mais lorsque nous cliquons sur Créer, rien ne se passe. Nous devons également nous occuper de la clôture de notre dialogue. Pour l'instant, cliquez sur Arrêter. Le positionnement de ces champs me dérange un peu. Réglons ça. Cliquez sur le bouton Texte. Nous avons inclus le volet quadrillé dans la balise d'en-tête du dialogue. L'endroit approprié pour l'inclure est dans la balise de contenu. Changeons-le. Vérifions maintenant son apparence sur le Scene Builder. Super, maintenant ça a l'air bien mieux. Dans la vidéo suivante, nous continuerons à implémenter la fonctionnalité de création de portefeuille. revoit. 12. 10 Créer notre première partie de portefeuille 3 skillshare 2: Dans cette vidéo, nous continuerons à implémenter la fonctionnalité de création de portefeuille et, enfin, réussir notre premier test d'interface graphique. Pour cela, ajoutons une dépendance au projet. Nous ajouterons Bitcoin, Java et une bibliothèque open source conçue exclusivement pour ce cours. Cette bibliothèque contient de nombreux utilitaires liés au Bitcoin, tels que des méthodes permettant de générer des graines mnémotechniques aléatoires , de créer des transactions, etc. Pour le bon fonctionnement de cette bibliothèque, il faut ajouter un objectif de plugin qui copiera le fichier ( liste de mots (point TXT) depuis Bitcoin Java vers le projet lors la phase de compilation des applications. processus de construction. Wordless dot TXT contient tous les mots valides pour la génération de graines mnémotechniques. Ouvrez maintenant le point FXML de la boîte de dialogue de création de portefeuille. Passez en mode texte. Nous allons ajouter un contrôleur à ce FXML afin d'ajouter une action au bouton Créer. Ajoutons donc l'attribut FX Controller à la balise Dialogue Pain. Le nom du contrôleur sera créé par wallet dialogue controller, et nous l'ajouterons au package des contrôleurs. Comme pour chaque contrôleur, y ajoutera l' annotation du composant. Créons la propriété mnémotechnique seed dans ce contrôleur. Dans le fichier FXML, nous ajouterons une action au bouton Créer. Ajoutons-le ici. Nous appellerons l'action «  créer une graine mnémotechnique ». Et nous allons le créer dans le contrôleur correspondant. Ainsi, lorsque l'utilisateur clique sur le bouton Créer, cette méthode sera appelée et la zone de texte affichera une graine mnémonique aléatoire. Nous allons donc définir les textes de départ mnémotechniques en fonction du résultat de la méthode de création que le service de semences mnémotechniques créera ensuite. Injectons le service de semences mnémotechniques dans cette classe. Créons maintenant la classe de service de départ mnémonique dans le nouveau package appelé api point services dans le package BYOD W. En gros, chaque classe professionnelle non liée à l' interface utilisateur graphique sera placée dans le package API. Ajoutons la méthode create au service de semences mnémotechniques. Ajoutez l' annotation de service à cette classe. Son objectif est identique à celui de l'annotation Component, mais il est plus adapté aux classes de service. Initialisons maintenant la propriété mnémonique Seed Service dans le constructeur Create Wallet. Maintenant, implémentons cette méthode car nous utilisons TDD pour créer notre application. Nous allons d'abord créer un test unitaire pour cette classe. Créons un package d'API dans le dossier de test. À l'intérieur, créez une classe géniale appelée mnémonic seed service test. En tant que test unitaire, cette classe doit uniquement étendre la classe de spécification de Spock. Maintenant, nous allons créer un test appelé devrait renvoyer une graine mnémonique aléatoire. Et nous nous attendons à ce que le service de semences mnémotechniques renvoie une valeur non nulle. Instancions le service de semences mnémotechniques ici. Laissons ce test pour vérifier ce qui se passe. Cela a échoué comme prévu. Implémentons cette méthode. Pour ce faire, nous allons utiliser la méthode generate random de la classe de générateur de graines mnémotechniques de Bitcoin Java. Nous devons transmettre le nombre de bits d' entropie que nous voulons que la graine mnémonique possède comme argument de cette méthode, nous l'utiliserons à 56. N'oubliez pas qu'une entropie de 256 bits génère une graine mnémotechnique de 24 mots. Enfin, nous appellerons la méthode get sentenced au retour de cette méthode et renverrons le résultat. Comme pour chaque tâche, exception vérifiée, nous devons également ajouter la phrase qui renvoie FileNotFoundException à la signature de la méthode create. Nous devons faire de même avec la méthode create mnémotechnique seed dans le contrôleur de dialogue Create Wallet. Faisons à nouveau ce test. Super, le test est passé. Voyons maintenant ce qui se passe lorsque nous exécutons notre application. Oups, une erreur s'est produite. Oh, c'est remplacé par un W majuscule dans cette balise. Cette étiquette d'identification de groupe est également incorrecte. En fait, il s'agit simplement d'une formation sur les tirets du Bitcoin. Réexécutons notre application. Super. Nous avons réussi à générer une graine mnémotechnique, mais je veux que son texte soit encapsulé. Réglons ça. Passons au point FXML de la boîte de dialogue de création de portefeuille. Dans le Scene Builder, cliquez sur la zone de texte et cochez la case The Wrap Text. Réexécutons le projet. OK, bien mieux. Maintenant, faisons tous nos tests. Super. Ils sont tous décédés. 13. 11 Créer notre première partie de portefeuille 4 skillshare 2: Dans cette vidéo, nous allons continuer à développer fonctionnalité de création de portefeuille de nos applications. Ajoutera un bouton OK et un bouton d'annulation à la boîte de dialogue de création du portefeuille. Lorsque l'utilisateur clique sur le bouton OK, son portefeuille est créé et le nom du portefeuille apparaît en haut de l'écran. Lorsqu'il clique sur le bouton Annuler, la boîte de dialogue se ferme. Nous ajouterons également une restriction au bouton OK afin qu' il soit désactivé par défaut et qu'il ne soit activé que lorsque le nom et les champs de départ mnémotechniques sont remplis. Enfin, nous ajouterons un champ de mot de passe facultatif afin que l'utilisateur ne puisse accéder à son portefeuille et effectuer des transactions qu' après avoir fourni le mot de passe correct. Ajoutons d' abord ces nouvelles fonctionnalités lors de notre test de création de portefeuille. Tout d'abord, nous allons ajouter un clic sur le bouton OK. Ensuite, nous nous attendrons à ce que le titre de l' étape soit égal au nom de notre application, puis à celui de notre portefeuille, qui est mon portefeuille de test. Nous allons maintenant créer la propriété de la scène. Nous allons l'initialiser dans la méthode de démarrage. Créons maintenant un autre test pour vérifier ce qui se passe lorsque l'utilisateur essaie de cliquer sur le bouton Annuler. Pour cela, nous allons créer un test dont le nom devrait annuler la création du portefeuille. Nous nous attendons donc à ce que lorsque l'utilisateur clique sur un nouveau portefeuille et annule, aucune exception ne soit déclenchée. Faisons ces tests pour voir ce qui se passe. Les tests ont échoué comme prévu. Implémentons ces fonctionnalités. Accédez au fichier FXML à points de la boîte de dialogue Créer un portefeuille. Cliquez sur le volet de dialogue sur le côté gauche. Ajoutez ensuite un bouton OK et ce champ de types de boutons. Cliquez sur Plus, puis ajoutez un bouton d'annulation. Nous allons maintenant ajouter le champ du mot de passe. Mais d'abord, ajoutons une autre ligne dans le volet de la grille. Déplaçons maintenant le nom, étiquette et le champ sur la première ligne. Ensuite, nous ajouterons une étiquette de mot de passe et un champ de mot de passe dans la ligne suivante. Ajoutons également une idée Fx du mot de passe dans le champ du mot de passe. Maintenant, changeons le texte de l'en-tête du dialogue comme suit. Pendant que nous y sommes, rendons le champ de départ mnémotechnique non modifiable. Il s'agit d'une mesure de sécurité car nous ne voulons pas que l'utilisateur modifie accidentellement sa graine mnémotechnique. Passez à l'affichage du texte. Nous ajouterons quelques modifications à ces boutons, balises dans le bouton OK, nous ajouterons une idée Fx de OK. Le bouton Annuler effacera son contenu et ajoutera une idée d'annulation à Fx. Nous ajouterons également la valeur d'annulation à proximité des données du bouton Attribut. Nous ajouterons également la chaîne d'annulation à l'attribut de texte. Cela est nécessaire car lorsque nous utilisons le bouton d'annulation par défaut, le texte est traduit dans la langue de l'ordinateur, ce que nous ne voulons pas. Maintenant, apportons quelques modifications au contrôleur de dialogue Create. Y ajoutera une méthode appelée initialize. Mais d'abord, revenons à son FXML et ajoutons un identifiant Fx de dialogue Pain au tag dialogue Pain. Maintenant, ajoutons les propriétés avec un ID FX au contrôleur. Je le ferai avec le mot de passe des propriétés nommé dialog pain, OK et Annuler. Revenons maintenant à la méthode initialisée. Cette méthode sera exécutée après l'initialisation du dialogue. Y inclura un code pour définir les actions de chaque bouton. Nous allons d'abord définir l' action du bouton Annuler. Lorsqu'un utilisateur clique dessus, la boîte de dialogue est masquée. Nous appellerons donc la méthode du bouton de recherche du dialogue en passant le bouton d'annulation comme argument. Ensuite, nous y ajouterons un gestionnaire d' événements, en transmettant l'argument action et un rappel qui appellera la méthode hide de la fenêtre Dialogue Pains. Nous ferons de même avec le bouton OK. Mais nous appellerons plutôt la méthode create wallet dans le callback. Incluons le même code pour masquer la fenêtre lorsque vous utilisez la méthode create wallet pour le moment et exécutons l'application pour voir ce qui se passe. Lorsque nous cliquons sur le bouton Annuler, la boîte de dialogue se masque. La même chose se produit lorsque nous cliquons sur le bouton OK. Bon. Mais lorsque nous cliquons sur le X sur le côté du dialogue, rien ne se passe. Réglons ça. Accédez au contrôleur de fenêtre principal. Vous devrez inclure le code suivant pour fermer la fenêtre de dialogue lorsque nous cliquons sur le bouton X. Maintenant, lançons l' application et réessayons. Bien, ça a réglé le problème. Changeons également la méthode show and wait utilisée dans le dialogue pour simplement montrer qui simplifie un peu les choses. Maintenant, réexécutez l'application. Tout continue de fonctionner comme prévu. Mais il y a un autre problème avec le dialogue. Il permet la création de portefeuilles sans nom et sans graine mnémotechnique. Nous voulons que chaque portefeuille ait un nom et une graine mnémotechnique. Nous devons donc désactiver le bouton OK s'il n'est pas rempli. Réglons ce problème. Accédez à la manette de dialogue Créer un portefeuille. Nous allons maintenant créer une propriété privée de type liaison booléenne appelée toutes les entrées requises sont complètes. Nous allons définir cette propriété dans la méthode initialisée avec le code suivant. Ici, nous allons utiliser une classe anonyme Java qui étend la liaison booléenne. Ensuite, nous initialiserons la classe avec la méthode bind, transmettant le nom et les propriétés mnémotechniques du texte de départ comme arguments. Ensuite, la méthode de calcul de la valeur inclura un code qui ne renverra vrai que si le nom et champs de départ mnémotechniques ne sont pas vides. Nous allons maintenant créer une méthode getter pour cette propriété. Enfin, nous appellerons la méthode de propriété désactivée sur le bouton OK. Ensuite, nous appellerons bind sur le résultat et transmettrons la méthode get all required input is full appelant la méthode correspondante. Apportons d'abord une petite correction à cette méthode, elle doit renvoyer une liaison booléenne. Et retirons-le, prends-le . Bon. Maintenant, exécutons à nouveau notre application. OK, le bouton OK est désactivé par défaut. Si nous saisissons quelque chose dans le champ du nom du portefeuille, cela reste désactivé. Mais lorsque nous cliquons sur le bouton Créer, il est activé. Génial. Faisons à nouveau nos tests. Cela devrait créer un portefeuille. Le test a échoué car nous n'avions pas encore implémenté le code pour modifier le titre de l'application. Nous allons le faire dans la vidéo suivante. 14. 12 Créer notre première partie de portefeuille 5 skillshare 2: Dans cette vidéo, nous allons implémenter une fonctionnalité qui permettra l'application de charger le portefeuille et afficher son nom sur le titre de l' application. Une fois que l'utilisateur a créé, le portefeuille. Créera un code qui sera utile plus tard lorsque nous voudrons afficher fonctionnalités d'autres portefeuilles telles que les adresses à l'écran. Une fois cette fonctionnalité mise en œuvre, ce test sera réussi car le titre de l'étape sera égal à BYOD W wallet space, dash space, nom du portefeuille. Mettons-le donc en œuvre. D'abord. Nous allons accéder au contrôleur Create Wallet. Ensuite, dans cette méthode, créera un portefeuille en utilisant un nouveau service appelé create wallet service et une méthode appelée create. Nous transmettrons le nom, le mot de passe et le code mnémotechnique du portefeuille à la méthode. Nous allons maintenant créer la classe de portefeuille. Nous allons ajouter un nouveau package dans le BYOD W, appelé domaines. À l'intérieur, il ajoutera un nouvel enregistrement Java appelé portefeuille. Pour l'instant, nous allons simplement ajouter un attribut de chaîne appelé name à cet enregistrement. Un enregistrement Java est une fonctionnalité récente du langage. Chaque attribut d'enregistrement possède un getter et un constructeur intégrés, nous n'avons donc pas besoin de les ajouter. Maintenant, importez l'enregistrement du portefeuille dans le contrôleur de dialogue Create Wallet. Nous allons maintenant injecter le service Create Wallet dans cette classe. Et nous allons créer cette classe dans le package de services API. Ajoutera l' annotation du composant à cette classe. Injectons ce service dans le constructeur de cette classe. Nous allons maintenant créer la méthode create dans le service create wallet. Pour l'instant, nous allons uniquement renvoyer un nouveau portefeuille en retransmettant le nom comme paramètre à la manette de dialogue Create wallet. Maintenant que nous avons créé le portefeuille, nous publierons un événement qui prendra le portefeuille créé comme paramètre. Cet événement sera écouté par une classe sorte que lorsque l'utilisateur créera un portefeuille, l'auditeur mettra à jour le portefeuille actuellement chargé par l'application. Injectons le contexte de l'application dans cette classe. Créons maintenant l'événement de portefeuille créé dans le package d'événements. Appellera ensuite le super constructeur passant par le contrôleur de dialogue Create Wallet. Et nous allons définir un nouveau champ de portefeuille L' attribution de l'argument constructeur du portefeuille à celui-ci inclura également un getter pour ce champ. Créons maintenant un écouteur pour cet événement appelé Created Wallet Listener. Et nous allons le créer dans le package Listeners. Il implémentera la classe d'écoute de l'application avec l' événement de portefeuille créé comme paramètre. Implémentera ensuite la méthode lors d'un événement d'application. Il appellera une méthode provenant d'un nouveau service appelé update current wallet service. Cette méthode appelée update prend le portefeuille d'événements comme paramètre. Injectons ce nouveau service dans cette classe et créons le service. Nous l'ajouterons dans un nouveau package de services. À l'intérieur de l'emballage gluant. Y créera ensuite la méthode de mise à jour. Nous y ajouterons également une annotation de service. Pour l'instant, la méthode de mise à jour définira uniquement le nom du portefeuille actuel par le nom du portefeuille nouvellement créé. Maintenant, créons un nouveau package dans BYOD W appelé observables. À l'intérieur de ce package, vous allez créer la classe de portefeuille actuelle. Retour au service de portefeuille Update Current instanciera le portefeuille actuel dans son constructeur. Dans le portefeuille actuel, la classe inclura l'annotation Component. Cette classe représentera le portefeuille actuellement chargé par l'application. Chaque modification apportée par l' application à cette instance de classe apparaîtra dans l'interface utilisateur graphique de l'application. Nous l'avons inclus dans un package appelé observable, car chaque propriété de cette classe ne sera pas observable. Et l'observable est un type d'objet dans lequel chaque changement d'état peut être écouté, mis en œuvre par d'autres objets. La première propriété observable que nous y ajouterons est le nom. Il aura le type de propriété de chaîne simple. Ce type implémente l'interface observable et déclenche un événement de modification lorsque la valeur de sa chaîne change. Nous allons l'instancier ici. Et nous allons créer un getter pour ce champ. Intellij Idea a identifié qu'il s' agissait d'un observable et a créé deux getters. L'un pour la propriété appelée name property et l'autre pour la valeur de propriété appelée getName créeront également un setter pour ce champ afin de définir la valeur de la propriété name. Faisons en sorte que ce terrain soit définitif. Procédera également à un test pour cette classe de service Create Wallet. Nous aurions dû créer le test avant d'implémenter cette méthode, puisque nous utilisons TDD. Mais étant donné que nous allons augmenter la fonctionnalité de cette méthode là où elle est pardonnée. Créons le test. Maintenant. Nous allons d'abord créer une propriété pour le service create wallet et l' instancier dans la méthode de configuration qui s'exécute avant chaque test. Ensuite, nous allons créer un test appelé should create wallet. Étant donné que nous avons un nom, un mot de passe et une graine mnémotechnique. Lorsque nous appelons la méthode create à partir du service create wallet avec ces paramètres. Ensuite, nous nous attendrons à ce que le nom du portefeuille soit égal à la variable name. Faisons le test. Le test est réussi. Récapitulons maintenant ce que nous avons fait jusqu'à présent. Lorsque l'utilisateur clique sur le bouton OK, la méthode de création de portefeuille à partir du contrôleur de dialogue de création appelée et le portefeuille créé par le service de portefeuille. Pour ce faire, il utilise la méthode create, prend le nom, le mot de passe et la graine mnémotechnique choisie par l'utilisateur. Pour l'instant, cette méthode renvoie uniquement un nouveau portefeuille portant son nom. Ensuite, nous transmettons le portefeuille créé à un nouvel événement de portefeuille créé et publions cet événement. Lorsque cela se produit, cela déclenche la méthode d'écoute du portefeuille créée lors d'un événement d'application. Il recevra l'événement de portefeuille créé en tant que paramètre. Nous devons ajouter l' annotation du composant à cette classe et injecter le service de mise à jour du portefeuille actuel dans son constructeur. Ainsi, la méthode d' événement de l'application appellera la méthode de mise à jour à partir du service de mise à jour du portefeuille actuel, en transmettant le portefeuille de l' événement comme paramètre. Enfin, la méthode de mise à jour. Nous allons attribuer au portefeuille actuel le nom du portefeuille que vous venez de créer. Revenons maintenant au contrôleur de fenêtre principal. Ici, vous allez créer une méthode initialisée qui sera exécutée avant que la fenêtre principale de l'application n'apparaisse. À l'intérieur, vous ajouterez un écouteur à la propriété actuelle du portefeuille. Injectons d'abord le portefeuille actuel dans cette classe. À l'intérieur de la méthode ad listener, la méthode Ad Listener transmettra un rappel qui prendra trois paramètres et une valeur observable et une ancienne valeur, et une nouvelle valeur dans le corps du rappel passera au stade Windows et attribuez-le à la variable stage. Nous devons mettre en scène ce type. Ensuite, nous définirons son titre comme BYOD W wallet space, dash space, new value. La nouvelle variable de valeur contient la nouvelle valeur du nom du portefeuille actuel. Chaque fois que le nom du portefeuille actuel change, ce changement sera pris en compte par ce rappel et le titre de la scène sera également remplacé par la phrase que nous venons de prononcer. Lancer l'application pour vérifier si cela fonctionne. Nous allons créer un nouveau portefeuille avec le test du nom, puis une graine mnémotechnique et cliquer sur «  OK, super, ça a marché ». Le titre de la fenêtre devient BYU OWL a dash test. Créons un autre portefeuille avec un nom différent pour voir ce qui se passe. Comme prévu. Il a été modifié pour correspondre au portefeuille nouvellement créé. Maintenant, faisons tous nos tests. Génial. Tous les tests ont réussi. Bon travail. 15. 13 Créer notre première partie de portefeuille 6 skillshare 2: Dans cette vidéo, nous allons commencer à implémenter une fonctionnalité qui nous permettra créer des adresses qui seront utilisées ultérieurement pour recevoir des Bitcoins. La première chose que nous allons faire est de créer l'onglet Recevoir. Cet onglet contiendra les adresses dérivées de notre portefeuille. Accédez donc au fichier FXML à points de la fenêtre principale. Dans le Scene Builder, une boîte en V sera incluse au centre du panneau de bordure. À l'intérieur de la boîte en V, vous trouverez un onglet. Supprimera automatiquement le deuxième onglet créé. Modifiez le texte des onglets restants à recevoir. Dans le menu de configuration de VBox vous pouvez régler la hauteur préférée sur 300. À l'intérieur de l'onglet Recevoir , vous trouverez un volet en forme de grille. Pour une raison ou une autre, nous ne pouvons pas inclure de volet de grille dans un onglet à l' aide du Scene Builder. Pas de problème. Nous allons le faire à l'aide de l'éditeur de texte. Au lieu de cela. Nous allons inclure une étiquette. Son texte sera égal à l'adresse de réception. À l'intérieur, il ajoutera des balises pour définir ses marges. Nous allons maintenant inclure un champ de texte. Il ne sera pas modifiable. Il aura 350 selon sa largeur préférée. Et son index de colonne sera égal à un inclura les mêmes balises de marge du volet de la grille que nous utilisions précédemment. Le générateur de scènes ne fonctionne plus en raison du volet quadrillé que nous avons inclus dans l'onglet. Pas de problème. Nous verrons à quoi ressemble l'application en l'exécutant. Super, notre portefeuille est maintenant prêt à recevoir une adresse dans ce nouveau champ que nous venons de créer. Le test de création de portefeuille inclura un code permettant de vérifier si une adresse a été créée et insérée dans le champ de l'adresse de réception après la création du portefeuille. Ainsi, une fois que le test a cliqué sur le bouton OK, il cliquera sur l'onglet Recevoir. Et le test recherchera le contenu du champ d' adresse de réception et le stockera dans la variable d' adresse. Ensuite, le test affirmera si l'adresse n'est pas connue, lançons le test pour voir ce qui se passe. Le test a échoué comme prévu. Maintenant, faisons quelques refactorisations et notre fichier FXML de la fenêtre principale. Nous voyons maintenant que notre fichier FXML principal est de plus en plus volumineux, il vaut mieux créer un nouveau fichier FXML uniquement pour l'onglet de réception, auquel la fenêtre principale se référera plus tard. Créons-le donc. Nous l'appellerons Recevoir le point FXML copiera tout le contenu de l'onglet dans le point FXML de l'onglet Recevoir. La seule modification que nous apporterons concerne la balise tab. Nous allons le remplacer par la racine f x deux-points. Ensuite, nous utiliserons la classe tab comme attribut type. Nous devons également inclure l' attribut Meta XML et le signe S deux-points FX. Nous allons maintenant importer les autres balises. Retour au point FXML de la fenêtre principale supprimera la balise tab et tout son contenu. Inclura le contrôleur d'onglet Receive, qui sera créé maintenant. Nous allons le créer dans le package des contrôleurs. Et importons-le dans le point FXML de la fenêtre principale. De retour à l' onglet Réception, le contrôleur ajoutera l' annotation du composant à cette classe. Nous allons créer un constructeur qui transmet une ressource avec une annotation de valeur pointant vers l'onglet Réception. Le fichier FXML transmettra également le contexte de l' application. Nous allons configurer ici une nouvelle instance de chargeur FXML avec des paramètres similaires à ceux que nous avons utilisés pour les autres contrôleurs. Ensuite, nous allons régler sa manette sur cette valeur. Nous allons également définir son itinéraire à cet égard. Ensuite, nous appellerons la méthode de chargement correspondante. OK, nous devons faire encore une chose pour que cela fonctionne. Dans la classe d'écoute gooey Started, ajoutez le code suivant ici. Ce code est nécessaire pour indiquer à Java FX comment créer des composants personnalisés, tels que le contrôleur d' onglet Receive lorsqu'il voit dans les fichiers FXML. Ce code obligera Java FX utiliser la méthode context to get bean pour créer un composant lorsqu' une balise Receive tab Controller apparaît. Ainsi, chaque fois que Java FX a besoin créer une balise de contrôleur d' onglet Receive, il utilise la classe Receive tab controller pour la créer. Pour les autres balises, il utilisera le générateur Java FX par défaut. C'est ça. Maintenant, Java FX sait comment créer notre nouvelle balise FXML personnalisée. Lancer notre application pour vérifier si tout va bien. ***** et une erreur s'est produite. Cela signifie que le contrôleur racine n'est pas une instance d'onglet. Je sais comment y remédier. Nous devons faire en sorte que le contrôleur de l'onglet Receive étende la classe TAP. Maintenant, voyons si cela fonctionne. OK, ça marche comme avant. Ainsi, lorsque nous créons un nouveau portefeuille, nous nous attendons à ce que le champ de l' adresse de réception soit rempli avec la nouvelle adresse Bitcoin. Dans les deux prochaines vidéos, nous allons comprendre le processus de dérivation d'une adresse Bitcoin et implémenter cette fonctionnalité dans notre portefeuille. Tu vois, oui. 16. Adresses Bitcoin et portefeuilles HD: Dans cette vidéo, nous allons en apprendre davantage sur portefeuilles HD et les adresses Bitcoin. Alors, qu'est-ce qu'une adresse Bitcoin ? Une adresse bitcoin est un mot codant pour une clé publique, le hachage d'une clé publique ou un hachage de script. Il est utilisé pour recevoir des bitcoins lors d'une transaction. Pour recevoir des Bitcoins par le biais d'une transaction Bitcoin, vous montrez votre adresse à une autre personne afin que cette personne puisse envoyer des bitcoins à votre adresse. Il existe plusieurs types d'adresses Bitcoin et les règles pour les générer se trouvent dans de nombreux VIP, tels que VIP, VIP 3d2 et BIP 44. Parlons maintenant des portefeuilles HD. Les portefeuilles HD sont synonymes de portefeuilles déterministes hiérarchiques. Elles sont hiérarchiques car composées de plusieurs niveaux de clés, et elles sont déterministes car une seule graine génère toujours les mêmes adresses et clés privées. Et HD Wallet est un type de portefeuille dans lequel, à partir d'une seule graine, des tablettes de dérivation sont utilisées pour obtenir des clés privées, des clés publiques et des adresses. Les spécifications des portefeuilles HD ont été définies à l'origine dans BI P32, d'autres BIP s'étendant sur cette spécification. Récapitulons maintenant une diapositive de notre dernière présentation ppt. Dans cette présentation, nous avons appris à générer une graine mnémotechnique. Et nous avons mentionné qu'en combinant une graine mnémotechnique avec une phrase secrète facultative, nous pouvions générer une graine racine en utilisant l'algorithme P vk df two. À partir de cette racine, nous pourrions générer des clés privées, des clés publiques et des adresses. Dans cette présentation, nous aborderons en détail cette dernière partie sur la façon dont les clés et adresses privées et publiques sont générées à partir d'une racine. Ainsi, en commençant par une racine 512 bits, en y appliquant l'algorithme de hachage HMAC SHA-512, nous obtenons la clé principale, qui contient également 512 bits de la clé principale. En appliquant la fonction CKD, qui signifie dérivation par clé enfant, nous pouvons obtenir différentes clés étendues en utilisant différents index comme paramètres. Si n est l'indice de cette fonction, n peut varier de 0 à 2 à la puissance 32 moins un. Chaque touche étendue peut générer des touches plus étendues à l'aide la fonction CKD et ainsi être la mère de nombreuses touches pour enfants. Ce schéma de dérivation permet de former un arbre de clés avec un nombre indéfini de générations. Voyons plus de détails sur les fonctions CKD. Il existe deux types de clés étendues. Il peut s'agir de clés privées étendues ou de clés publiques étendues. Et la clé privée étendue dont la version sérialisée commence par x PRV, ou une autre lettre plus PRV est générée à l'aide de la fonction privée CKD. Si l'indice transmis à cette fonction est égal ou supérieur à deux à la puissance 31, il s'agit d'une dérivation renforcée. Et il a indiqué que la clé privée étendue générée est un enfant renforcé. Les clés renforcées possèdent des fonctionnalités de sécurité supplémentaires que nous expliquerons en bref Il est possible de générer une clé publique étendue en utilisant la fonction publique CKD. Clés publiques surveillées lors de la sérialisation, commencez par x pub, ou une autre lettre plus pub. Il est également possible de générer une clé publique étendue à partir d' une autre clé publique étendue en utilisant la fonction publique CKD, deux dérivations ne sont pas possibles. Génération d'une clé privée étendue à partir d'une clé publique étendue et d'une clé publique étendue renforcée à partir d'une clé publique étendue. Alors, comment passer des clés étendues aux adresses ? En commençant par une clé privée étendue, nous en extrayons une clé privée. Une clé privée fait partie d' une clé privée étendue. Cette extraction est donc une opération simple. Ensuite, par une opération appelée multiplication de courbes elliptiques, nous générons une clé publique à partir d'une clé privée. Enfin, en hachant et en encodant la clé publique, nous obtenons une adresse Bitcoin. Il existe différents types de hachage et de codage des clés publiques pour produire différents types d'adresses. Nous en apprendrons davantage sur ces opérations dans les prochaines vidéos. Nous utilisons également des clés privées pour générer des signatures de transaction, pour transférer des Bitcoins vers d'autres adresses. Les signatures de transaction sont produites à l'aide de l'algorithme de signature numérique Elliptic Curve ou ECDSA. Vous pouvez également générer des adresses avec une clé publique étendue. Pour ce faire, vous devez en extraire la clé publique. Ensuite, une adresse bitcoin est générée à partir de la clé publique par hachage et encodage, comme expliqué précédemment. N'oubliez pas qu'une clé publique ne peut pas être convertie en clé privée. Il ne peut donc pas être utilisé pour signer des transactions et transférer des Bitcoins. Voyons maintenant le concept de chemins de dérivation, commençant par la clé principale, dont la profondeur est égale à zéro dans un arbre de clés étendues. En dérivant une clé étendue passant zéro comme argument à une fonction CKD, nous obtenons une clé étendue d'une profondeur de un. En répétant le processus avec la clé étendue nouvellement générée, nous obtenons une clé étendue d'une profondeur de deux. Ensuite, nous pouvons répéter le processus en passant un comme index et en obtenant une clé étendue d' une profondeur de trois. À partir de cette dernière clé étendue, nous pouvons extraire une clé publique et une adresse. On dit que cette adresse a un chemin de dérivation zéro barre oblique zéro barre oblique un parce que c'est à cette adresse que l'index est utilisé pour dériver la clé étendue qui a généré cette adresse. En appliquant le même raisonnement. Dans cet autre exemple, nous obtenons une adresse dont le chemin de dérivation est composé d'une barre oblique zéro et d'une barre oblique deux. Cet autre exemple montre que vous pouvez utiliser d'autres nombres comme index des fonctions CKD sur n'importe quelle touche étendue d'un arbre de touches, ce qui permet de générer un nombre presque infini de chemins et adresses de dérivation. Cet autre exemple montre la génération d' un enfant renforcé. En utilisant un guillemet simple après l'index, nous pouvons représenter les index qui génèrent des enfants renforcés dans un chemin de dérivation. Zéro suivi d'un guillemet simple représente le premier indice renforcé, qui est égal à deux à la puissance de 3011, suivi d'un guillemet simple représente le deuxième indice de durcissement, etc. Cette notation est utilisée pour faciliter la description d' un chemin de dérivation afin que nous puissions utiliser de petits nombres pour le décrire. Il est important d'ajouter cela. Pour dépenser des Bitcoins à partir d'une adresse, il est nécessaire de produire une clé privée avec le même chemin de dérivation que celui utilisé pour obtenir cette adresse. Vous pouvez donc utiliser les fonctions publiques de CKD pour produire des clés et des adresses publiques étendues. Mais pour dépenser des fonds provenant de ces adresses, vous devez utiliser les fonctions privées de CKD pour produire des clés privées étendues et des clés privées. Une autre caractéristique des portefeuilles HD et de leurs voies de dérivation est leur relation entre la mort et la fonction. Une fonction est attribuée à chaque niveau d'une arborescence de touches. Bi P32 définit la profondeur, l'un représente la profondeur deux chaînes différentes et la profondeur de trois adresses différentes. Bip 44 a proposé différentes définitions qui sont de plus en plus utilisées de nos jours dans la plupart des portefeuilles HD. Selon une profondeur de 44, une clé étendue renforcée a des objectifs différents. Profondeur pour durcir les clés, différents types de pièces, profondeur trois clés renforcées, différents comptes. Depth for définit si les adresses descendantes doivent être utilisées pour les modifications ne se font pas de manière booléenne et Death Five représente des adresses différentes. Pour mieux comprendre comment cela fonctionne dans la pratique, voyons quelques exemples de chemins de dérivation et de leurs fonctions. Et adressé avec un chemin de dérivation de 84 guillemets, barre oblique zéro, barre oblique zéro, barre oblique zéro a pour but de trouver et BIP A14. Vip 84 définit que les adresses ayant pour objectif 84 doivent être des adresses P2 WP k h, ce qui signifie « pay to witness public key hash address ». Nous parlerons en détail des différents types d' adresses dans les prochaines vidéos. Mais en bref, les adresses natives P2, WP k, h, alias segue, sont les types d' adresses natives les plus courants dans les portefeuilles modernes les plus récents. Cette adresse comporte également un type de pièce dont la valeur est zéro, ce qui signifie qu'il s'agit d'une adresse Bitcoin. Il possède également un compte zéro, ce qui signifie qu'il fait partie du compte du premier utilisateur. Cela a changé. L'index est défini sur zéro, ce qui signifie qu'il ne s'agit pas d'une adresse de changement. Enfin, son index d'adresses est nul, ce qui signifie qu'il s'agit du premier utilisateur à recevoir une adresse. L'exemple suivant possède un chemin de dérivation similaire à l'exemple précédent, sauf que son index d' adresses en est un. Il s'agit donc de la deuxième adresse de réception native Bitcoin Segue du compte du premier utilisateur, selon le même raisonnement. Le troisième exemple est le premier changement d'adresse native de changement d'adresse Bitcoin Segue du compte du premier utilisateur. L'index un en profondeur quatre indique qu'il s'agit d'un changement d'adresse. Le dernier exemple est similaire au premier, sauf que son objectif est de 49 caractères entre guillemets. Vip 49 définit que les adresses à cet effet doivent être P2 WP k-th imbriquées dans des adresses SSH P2. Si cela vous semble compliqué, ne vous inquiétez pas, nous en apprendrons plus dans les prochaines vidéos. Passons maintenant à un aperçu des fonctionnalités du HD Wallet. Avec les portefeuilles HD, nous pouvons facilement générer un nombre presque infini d' adresses à partir d'une seule graine. C'est formidable car nous pouvons éviter réutilisation des adresses et la perte de confidentialité. Les portefeuilles HD permettent également une structure de comptes multiples dans laquelle la clé privée étendue des parents a accès aux fonds clés de leurs enfants, mais les enfants peuvent transférer les fonds des parents. Ce schéma peut être utile dans des cas tels que les propriétaires d'entreprises ayant accès aux clés pour enfants auprès des services de leur entreprise. Une autre fonctionnalité utile que permettent les portefeuilles HD est la création de portefeuilles réservés aux montres dont les adresses peuvent être générées et leurs fonds audités à l'aide uniquement de clés publiques étendues, mais où aucun fonds ne peut être déplacé car aucune transaction ne peut être signée. Une autre fonctionnalité du HD Wallet est la possibilité de générer d' autres adresses de cryptomonnaies à partir de la même graine mnémonique. Une liste des différents types de pièces est décrite sur le feuillet 44, un système de proposition similaire au BIP élaboré par Satoshi Labs, la société responsable de la ferme ou du portefeuille. Une autre caractéristique des portefeuilles HD est que leurs adresses et clés privées peuvent être reconstruites avec leurs origines et leurs chemins de dérivation. Cela vous permet d'importer une graine mnémotechnique et un mot de passe dans un portefeuille compatible pour récupérer toutes vos adresses et clés privées. Le compartimentage de sécurité est une autre caractéristique intéressante des portefeuilles HD. Si une clé privée étendue est divulguée par accident, cela n'affectera que les fonds bloqués dans des adresses descendant de la clé divulguée. Les fonds placés dans les clés d'un parent ou d'un frère ou d'une sœur seraient en sécurité. Enfin, les portefeuilles HD facilitent la génération et l'organisation de différents types d'adresses Bitcoin. Voyons maintenant pourquoi des clés renforcées sont nécessaires. Au cours du développement de HD Wallet, il a été découvert que si une clé publique étendue et une clé privée non hodgkinienne provenant du niveau suivant fuyaient, cela équivaudrait à une fuite fuyaient, cela équivaudrait à clé privée étendue apparente. Cela pourrait entraîner une perte de fonds pour chaque adresse provenant de la clé publique étendue divulguée. Par conséquent, la dérivation du pardon a été créée pour empêcher que cet exploit ne se produise sur des comptes et à des profondeurs plus basses. Enfin, discutons de la manière dont nous allons implémenter le schéma de dérivation d'adresses dans notre portefeuille. Utilisera le chemin de dérivation 84 guillemets, barre oblique zéro, barre oblique zéro, barre oblique zéro pour générer notre première adresse de réception. Après avoir reçu des Bitcoins, l'adresse de réception suivante sera modifiée en augmentant l'index d'adresses d'une unité. Ainsi, les prochaines adresses de réception auront des index d' adresses de 123 et ainsi de suite. Cela nous empêche d'utiliser la même adresse pour recevoir des Bitcoins plus d'une fois. Utilisera le chemin de dérivation 84 guillemets, barre oblique, barre oblique, barre oblique zéro pour générer notre premier changement d'adresse. Après avoir envoyé des Bitcoins et reçu une modification, l' adresse de changement suivante est modifiée en augmentant l'index d' adresses d'une unité. Nous ferons de même pour les adresses de réception. Vous vous demandez peut-être pourquoi il est important d'éviter la réutilisation des adresses pour deux raisons principales. Tout d'abord, ce faisant, nous augmentons notre confidentialité. Ainsi, si un tiers découvre qu'une adresse nous appartient, cette information ne sera pas reproduite vers d' autres adresses que nous utilisons. L'autre raison est la sécurité. Si, pour une raison quelconque, la clé privée d'une adresse fuit, cela n' affectera que cette adresse. Le proverbe qui dit « ne mettez pas tous vos œufs dans le même panier » s'applique ici. Cela dit, nous allons implémenter le schéma de dérivation en générant d'abord la clé publique étendue avec un chemin égal à 84 guillemets, barre oblique zéro, barre oblique zéro, barre oblique zéro pour les adresses de réception. Et la clé publique étendue avec un chemin égal à 84 guillemets barre oblique zéro, barre oblique 1 pour changer d'adresse. Ensuite, nous obtiendrons les clés publiques étendues et les adresses de leurs enfants . Ce faisant, nous générerons toutes les adresses dont nous avons besoin sans exposer aucune clé privée en mémoire. Notre principale politique de sécurité consiste donc à éviter exposer les graines et les clés privées autant que possible d' exposer les graines et les clés privées à la mémoire. Nos clés privées ne seront dérivées que lors de la signature de transactions à l'aide des mêmes tablettes de dérivation que celles utilisées pour générer les adresses à partir desquelles ces transactions dépensent des Bitcoins. 17. 15 Créer notre première partie de portefeuille 7 skillshare 2: Dans cette vidéo, nous allons créer les clés publiques étendues dont Wallet aura besoin pour créer des adresses. Comme nous l'avons vu dans la dernière vidéo, nos portefeuilles seront initialement équipés de clés étendues, qui seront la clé étendue pour les adresses de réception segmentées, et la clé étendue pour les modifications d'adresses Segue. Tout d'abord, corrigeons certains problèmes liés à nos tests d'interface graphique. Si vous essayez d'exécuter le test de création de portefeuille , vous verrez maintenant que cela fonctionnera. Cela est dû en partie à une instanciation prématurée de notre nouvelle classe de contrôleurs Receive tab. Pour résoudre ce problème, créez un nouveau package appelé Config dans le package de test BYOD W. Créez ensuite une nouvelle classe appelée test lazy contenant une configuration IP. Cette classe implémentera le post-processeur Bean Factory implémentera cette méthode requise avec ce code. Ce code fera en sorte que chaque classe pendant les tests soit initialisée paresseusement. Il y a un autre bout de code que nous devons ajouter dans notre test de création de portefeuille pour que cela fonctionne. la méthode start, nous ajouterons au chargeur FXML la même usine de construction que celle que nous avons définie dans notre classe d' écoute démarrée par l'interface graphique. Exécutons maintenant nos tests d'interface graphique. Génial. Les tests fonctionnent maintenant. Nous voyons qu'ils sont les seuls à devoir annuler les tests qui ont réussi et que l'autre doit encore le faire réussir. Maintenant, ajoutons les clés publiques étendues à notre portefeuille. La première chose que nous allons faire est d'ajuster notre test de service Create Wallet qui transmettra une valeur mnémotechnique valide à cette variable. Vous pouvez l'obtenir sur la page Projet et ressources. Ensuite, nous vérifierons si le portefeuille créé possède des clés publiques étendues. Vérifiera s'il possède deux clés publiques étendues, puisque chaque portefeuille disposera d'une clé publique étendue pour les adresses de réception et d'une clé publique étendue pour les modifications d'adresses. Nous allons maintenant ajouter une liste de clés publiques étendues à l'enregistrement du portefeuille. Créons notre classe de clés de pub étendue. Il aura une clé et un type. Ajoutons-les à un constructeur. Les deux propriétés auront un getter. Nous allons maintenant créer une classe de configuration d'adresses. Tout d'abord, créons un nouveau package de configuration dans le package API. Ensuite, nous y créerons la classe de configuration d'adresse. Ajoutez-y l' annotation de configuration. Cette annotation est nécessaire pour que Spring Boot initialise tous les objets définis dans cette classe lors du démarrage de l'application. Nous allons maintenant créer une classe de domaine appelée address config. En fait, ce sera un record. Il aura un type d'adresse et le chemin de dérivation. Créez ensuite une énumération appelée type d' adresse dans le même package. Il sera de deux types, segmenté et segmenté avec changement de trait de soulignement. Revenons maintenant à la classe de configuration des adresses. Nous allons créer un faisceau pour l'adresse de notre segment. Dans Spring Boot, un bean est simplement un objet qui peut être injecté dans d'autres classes de projet. Instanciera ce bean avec ces paramètres. Et ajoutez l' annotation Bean à cette méthode. Le fait de transmettre la chaîne de segment comme paramètre dupliquera cette méthode et la modifiera pour qu'elle corresponde à notre configuration de changement d'adresse. Le paramètre d'annotation Bean sera remplacé par Segue Change. Le nom de la méthode sera segue change config. Le type d'adresse qui sera défini pourrait changer. Et le chemin de dérivation aura un indice de variation de un. Nous allons maintenant utiliser ces configurations dans notre service de création de portefeuille. Injectons donc une liste de configurations d' adresses dans cette classe. Ce faisant, Spring Boot identifie automatiquement qu'il existe deux beans avec le type de configuration d' adresse et injectera les deux dans cette liste. Maintenant, dans la méthode create vous allez créer une variable de départ mnémotechnique. abord, nous allons remplacer le paramètre de la méthode mnémotechnique par une chaîne de graines mnémotechniques qui instanciera ensuite un objet de départ mnémotechnique en passant la chaîne de départ mnémotechnique comme paramètre. Ensuite, nous allons créer une clé principale, qui est un type de clé privée étendue. Pour cela, nous allons appeler la méthode mnémotechnique seed to master key et transmettre le mot de passe et cette constante comme paramètres. Mais d'abord, nous devons mettre à jour notre version Bitcoin Java à 0.3, 0.0 dans le fichier POM. Allons-y. Maintenant. Cliquez sur Load Maven pour revenir à la méthode de création. Il nous permet maintenant d'importer la constante de préfixe réseau principale transmettre son préfixe privé en paramètre. Ajoutons maintenant ce code, puis je vais vous expliquer ce qu'il va faire ensuite. Ce code lance la conversion de la liste de configuration d'adresses en flux. Dans Java 8 ou version ultérieure, les flux sont utilisés pour appliquer des opérations fonctionnelles à une collection de données. Dans ce cas, chaque configuration d' adresse de la liste est transmise à cette fonction lambda, qui utilisera le service de clé de pub étendu créera ensuite pour renvoyer un objet de clé de pub étendu. Chaque clé de pub étendue renvoyée sera collectée dans une liste qui sera stockée dans la variable Extended Pub Keys, puis transmettra la liste étendue des clés de pub au portefeuille renvoyé. Maintenant, injectons le service de clé pub étendu dans cette classe. Il va falloir le créer. Nous pouvons maintenant l' ajouter au constructeur. Maintenant va créer sa méthode de création. Il renverra une clé de pub étendue. Après le TDD. Il est temps de créer un test pour cette méthode. Allons-y. Il sera créé dans le package de l'API de test. Il doit étendre la classe de spécification. Instancions le service de clé de pub étendu ici. Nous devons également ajouter ce morceau de code à la méthode de configuration. Et nous allons créer un test appelé devrait créer une clé étendue. Lorsqu'on lui donne une graine mnémotechnique et une clé maîtresse dérivée de celle-ci. Lorsque nous appelons la méthode create à partir du service étendu Pub Key. Nous nous attendons alors à ce que la clé de pub étendue créée soit égale à la clé de pub étendue attendue. OK, alors comment allons-nous créer ces variables en gris ? Nous les passerons en utilisant la clause where comme celle-ci. Vous vous demandez peut-être où j'ai obtenu ces valeurs ? Je les ai trouvés sur le site Web EN Coleman io Slash Pip Threonine. Ce site Web est très utile pour générer de nombreux types de clés et d'adresses étendues. Je vais copier et coller cette graine mnémotechnique dans le champ BIP 39 du site Web pour montrer comment elle fonctionne. Immédiatement après avoir collé la graine mnémotechnique, l'outil a calculé la clé principale de racine et les clés étendues pour afficher le BIP AT dérivé pour les clés étendues, cliquez sur cet onglet. Nous constatons que la clé de pub attendue et le test sont égaux à cette valeur sur le site Web. En appliquant la fonction CKD à cette clé publique étendue avec des nombres différents sous forme d' index, vous obtiendrez ensuite des clés publiques étendues dont les clés publiques extraites seront utilisées pour générer adresses de réception utilisant le même site Web que j'ai créé pour d'autres cas de test. Je vais les coller ici et ajuster le formatage. Les deux derniers cas de test généreront des clés de pub étendues qui seront utilisées pour générer des modifications d'adresses. Vous pouvez les copier à partir des ressources de cette vidéo ou créer vos propres scénarios de test sur le site Web de Ian Coleman. À l'aide de la clause where, le même test sera exécuté pour chaque paramétrage que nous avons créé. Faisons le test. Le test a échoué comme prévu. Implémentons maintenant la méthode. D'abord. Nous allons créer ici une carte qui n'adressera pas types aux préfixes de clés de pub étendues. Les deux types d'adresses correspondront au même préfixe de segment réseau principal. Ce faisant, nous facilitons l'extension de cette fonctionnalité si nous devons ajouter d' autres types adressés ultérieurement. Maintenant, dans la méthode create une nouvelle clé de pub étendue sera renvoyée. transmission de ces paramètres entraînera le retour de la méthode CKD à partir de la clé principale, qui empruntera un chemin de dérivation. Faux car il ne s'agit pas d'une clé privée étendue du préfixe du type d'adresse. Ensuite, nous allons sérialiser le résultat. Et le deuxième argument de clé pub étendu sera le type d'adresse et la forme sous forme de chaîne. Enfin, n'oublions pas d'ajouter l' annotation du service ici. Maintenant, relançons le test étendu du service Pub Key. Super, ils sont tous passés. Exécutons maintenant nos tests du service Create Wallet. Mais d'abord, apportons quelques modifications à ce test. Nous devons ajouter le fournisseur de sécurité , nécessaire au fonctionnement des fonctions de cryptographie Java de Bitcoin. Nous devons également définir les bons arguments pour le service. Créons les configurations d'adresses et le service Pub Key étendu. Maintenant, exécutons-le. Super, les tests sont réussis. Cela signifie que notre portefeuille a été créé avec une liste de clés publiques étendues de taille deux. Oups, l' indice de changement en est un. Cela n'affectera pas ce test puisque nous affirmons simplement que le portefeuille devra utiliser des clés de pub étendues. Mais changeons-le en un par souci d'exactitude. 18. 16 Créer notre première partie de portefeuille 8 skillshare 2: Dans cette vidéo, nous allons créer une robe pour chaque clé de pub étendue fabriquée par le portefeuille. Pour ce faire, chaque clé de pub étendue sera transmise à la méthode Dresses générée, qui sera créée maintenant. Cette méthode définira une liste d' adresses pour l'enregistrement de clé de pub étendu. Créons ce centre. Cette liste d'adresses sera créée par un nouveau service générateur séquentiel d'adresses qui le créera. Il utilisera une méthode de génération qui prendra la clé de pub étendue et le type de clé de pub étendue. Le service générateur séquentiel d'adresses portera ce nom car il générera une robe avec un indice de dérivation d'adresses croissant. Injectons le générateur séquentiel d'adresses dans cette classe et créons le. Maintenant, créons sa méthode de génération qui renverra une liste d'adresses. Créons l'enregistrement d'adresse. Cet enregistrement comportera un champ d'adresse et un champ d'index. Ajustons la méthode set addresses à partir de la clé pub étendue. Il prendra une liste d' adresses et définira le champ étendu des adresses clés de pub. Créons un test pour la classe de générateur séquentiel d'adresses. Pour l'instant, sa méthode renverra null. La classe de test étendra la classe de spécification. Nous allons créer un test appelé devrait générer 20 adresses utiliser le générateur séquentiel d'adresses dans le wind block. Ajoutons-le donc en tant que champ à cette classe. Lorsque la méthode generate est appelée avec ces paramètres, il s'agit d'une clé publique étendue dans le type de segment. Ensuite, nous nous attendons à ce que la liste des robes de retour ait une taille de 20. Vous pouvez copier la clé publique étendue de ce test à partir des ressources de cette leçon. Instancions le générateur séquentiel d' adresses dans la méthode de configuration et exécutons le test. Il a échoué comme prévu. Implémentons maintenant que le service déclarera une clé de pub étendue. Ensuite, à l'intérieur d'un try catch, bloquera et sérialisera le paramètre clé reçu. La méthode sérialisée ANS transforme la clé de pub étendue en objet de clé de pub étendue à partir de Bitcoin. Java encapsulera ensuite l'IOException dans une exception d'exécution dans le bloc catch. Nous allons maintenant utiliser la méthode range de la classe de flux pulmonaires pour passer de zéro à un nombre initial de variables d'adresses générées qui sera défini ultérieurement. Nous allons injecter cette variable dans cette classe. Dans le constructeur, une annotation qualificative sera définie pour cette variable, qui prendra le même nom de variable comme paramètre, changera son type en indice, cartographiera chaque index et appellera la méthode de génération d' adresses. Ainsi, pour chaque index, nous appellerons la méthode generate address, transmettant le retour de la méthode Get d'usine du générateur d'adresses, la clé pub étendue et l' index comme paramètres. Enfin, nous allons convertir le résultat en liste. Créons la méthode de génération d'adresses. Il faudra un générateur d'adresses, une clé de pub étendue et un index. Le générateur d'adresses sera transmis par une usine de générateurs d'adresses, qui injectera dans cette classe et créera maintenant. Remplaçons le paramètre type par type d'adresse. Nous allons maintenant créer la méthode Get d'usine du générateur d'adresses . Il renverra une interface de générateur d'adresses qui va maintenant revenir à la méthode de génération d'adresse à partir du générateur séquentiel d'adresses. Nous allons d'abord dériver une clé enfant étendue à partir de la clé pub étendue en utilisant la méthode CKD. Cette méthode appliquera la fonction de dérivation des touches pour enfants que nous avons apprise il y a deux vidéos. Il faudra un indice qui définira l'indice de dérivation de l'enfant. Maintenant, un nouvel enregistrement d'adresse sera renvoyé. Il prendra le résultat de la méthode generate à partir du générateur d'adresses. Cette méthode utilise la clé enfant étendue et en déduit une adresse. Le deuxième paramètre d'adresse sera l'index. Nous allons maintenant ajouter la méthode generate à l'interface du générateur d'adresses. Nous allons maintenant implémenter la méthode get depuis l'usine du générateur d'adresses. Il renverra le résultat de la GetMethod à partir d'une carte génératrice d' adresses. Cette variable sera un champ de cette classe et sera initialisée dans ce constructeur de classe. Ce sera une carte de chaînes sous forme de clés et de générateurs d'adresses sous forme de valeurs. Dans le constructeur passera un service générateur d'adresses de segment, qui créera. Ensuite, nous associerons chaque type d'adresse au générateur d' adresses de segment. Dans la carte du générateur d'adresses. Le générateur d'adresses de segment implémentera l'interface du générateur d'adresses. Créons la méthode d'interface requise. Avant de l'implémenter, créons son test. Cela étendra la classe de spécification. Instanciera le générateur d' adresses de segment ici. Dans la méthode de configuration, vous ajouterez le fournisseur de sécurité, tout comme nos autres tests qui en ont besoin. Ensuite, nous allons créer ce qui devrait générer un test d'adresse de segment. Dans le bloc donné, une clé de pub étendue sera créée en utilisant la classe de clé de pub étendue sur la méthode sérialisée. La méthode sérialisée utilisera une chaîne de clé pub étendue, qui sera transmise dans le bloc where. Ensuite, nous allons créer une garde d'enfants étendue en utilisant la méthode CKD sur la variable de clé pub étendue. À cette méthode sera transmis un paramètre d'index qui passera par le bloc Web. Lorsque la méthode de génération du générateur d'adresses de segment est appelée avec la clé enfant étendue. Nous nous attendons alors à ce que l'adresse de retour soit égale à l'adresse attendue. Maintenant, utilisons le bloc where pour initialiser les variables en gris et utiliserons les données de test qu'ils ont extraites du site Web de E et Coleman pour cela. Vous pouvez copier ces paramètres à partir des ressources de cette leçon. Faisons le test. Cela a échoué comme prévu. Dans la vidéo suivante, nous en apprendrons davantage sur les adresses sig what. Ensuite, dans la vidéo qui suit, nous implémenterons le générateur d' adresses segmentées et le générateur d'adresses séquentielles et ferons en sorte que leurs tests soient réussis. 19. Comprendre les adresses Segwit et l'introduction aux environnements de réseau Bitcoin: Dans cette présentation, nous en apprendrons plus sur les adresses des segments Bitcoin, qui seront le type d'adresse par défaut fourni par notre portefeuille. Alors, qu'est-ce qu'un Bitcoin Segue, quelle adresse ? Les adresses de segment sont également appelées adresses natives Segue 32 , adresses segmentées version zéro ou adresses P2 WP k-th, où P2 WP k h signifie payer pour être témoin du hachage d'une clé publique. Chacun de ces termes est utilisé pour désigner la même chose. Il s'agissait du type d' adresse Bitcoin le plus récent jusqu'en novembre 2021. Après novembre 2021, lorsque la mise à niveau de Taproot a été activée sur le réseau Bitcoin, un nouveau type d'adresse Bitcoin appelé adresse taproot, alias adresse Ségue version 1 , est devenu disponible. Pour l'instant, concentrons-nous sur l'adresse du segment, dont la plupart des adresses segmentées compatibles avec les portefeuilles modernes sont devenues disponibles en 2017 sur le réseau Bitcoin après la mise à niveau séparée des témoins. Cette mise à niveau autorisait éventuellement des transactions plus petites puisque la partie de ces nouvelles transactions appelée témoin est envoyée séparément et n'est pas incluse dans la blockchain. Les règles pour générer des adresses de segment sont décrites dans VIP one-seventh three et sont également implémentées dans méthodes de la bibliothèque Java Bitcoin. Les adresses segmentées permettent aux expéditeurs de bitcoins de payer les frais les moins chers pour les transactions courantes. explique par le fait que les transactions qui envoient des bitcoins à des adresses segmentées sont effectivement plus petites que les transactions envoyées vers d'autres types d'adresses. Mais nous en apprendrons plus sur les transactions en Bitcoin dans les prochaines vidéos. Étant donné que les adresses segmentées sont bien prises en charge par plupart des portefeuilles modernes et qu'elles nous permettent d'effectuer des transactions moins chères, nous les définirons comme type d' adresse par défaut de notre portefeuille. Récapitulons maintenant une diapositive de la présentation précédente sur les clés étendues. Dans cette vidéo, nous avons appris que nous pouvions obtenir une clé publique à partir d'une clé privée étendue ou d'une clé publique étendue. Ensuite, en hachant et en codant la clé publique, nous pourrions obtenir une adresse. Voyons maintenant plus de détails sur ce processus de hachage et d' encodage. commençant par une clé publique obtenue comme expliqué précédemment, en appliquant les fonctions de hachage cryptographique SHA-256 et 160 à droite à la clé publique, nous obtenons un hachage de clé publique d'une taille de 20 octets. Le SHA-256, combiné au 160 de la main droite , est appelé algorithme de hachage 160. Enfin, le hachage de la clé publique, associé à un préfixe et à une version numérique, génère une adresse de segment grâce au codage Beck 32. encodage Back 32 est réversible par le processus appelé décodage Beck 32. Lors de la création de transactions, nous devons décoder 32 adresses en hachages à clé publique avant de les inclure dans les résultats des transactions. C'est pourquoi ce type d'adresse est également appelé pay to witness public key hash. Nous reviendrons ce sujet plus en détail lorsque nous parlerons transactions pour des adresses segmentées. Lorsque la clé publique d'encodage Beck 32 est hachée, la version est mise à zéro lorsque le préfixe est défini sur BC unnamed net. En parlant de Main Net, passons rapidement en revue les environnements du réseau Bitcoin. Chacun de ces environnements constitue un réseau distinct avec des chaînes de blocs et des objectifs différents, mais avec des règles similaires. Le réseau Bitcoin peut être appelé ainsi le principal réseau Bitcoin. C'est là que les bitcoins ont de la valeur. La blockchain est immuable et la difficulté de minage est la plus élevée. L'environnement du réseau de test est similaire au réseau principal mais présente une difficulté de minage plus faible. Lorsque les bitcoins n'ont aucune valeur, il est utilisé pour effectuer des tests dans un environnement où les nœuds interagissent lorsque maintenir une chaîne de blocs partagée. Test Net a eu différentes versions depuis sa création avec différentes blockchains. Enfin, l'environnement de test reg est un réseau individuel qui peut être géré par n'importe quel utilisateur de nœud Bitcoin avec une blockchain non partagée avec d'autres. Les blocs peuvent être générés instantanément, sans effort et librement par l'utilisateur. Il est utilisé pour effectuer des tests plus rapides et plus automatisés dans un environnement contrôlé. Les adresses de chaque réseau ont des préfixes différents et ne sont valides que dans leur environnement. Pour les adresses de segment, ce C est le préfixe utilisé pour les robes rouges sur le réseau principal. Tb est utilisé pour les adresses sur le réseau de test. Et BCRP est le préfixe utilisé pour les robes rouges lors du Reg Test. Comme indiqué précédemment, la version zéro est utilisée pour les adresses de segment. La première version est utilisée pour les adresses pivotantes. 20. 18 Créer notre première partie de portefeuille 9 skillshare 2: Dans cette vidéo, nous allons effectuer tous les tests pour lesquels nous avons créé des chemins. Nous allons d'abord implémenter la méthode du générateur d' adresses de segment. génération d'une adresse de segment convertira une clé étendue en clé publique. Changeons le nom de ce paramètre en clé étendue. Ensuite, la clé publique sera convertie en adresse de segment en utilisant cette méthode car son paramètre transmettra un préfixe. Passons cette constante pour le moment, ce qui rendra l' adresse valide dans l' environnement principal du net Bitcoin. Ajoutons également l' annotation du service à cette classe. Maintenant, nous allons exécuter le test du générateur d'adresses de segment. Cela a échoué car nous devons faire passer la version Java de Bitcoin à 0.4, 0.0, qui contient la bonne méthode CKD pour cette opération fonctionne. Allons-y. Cliquez sur Load Maven changes. Faisons à nouveau le test. Super, tous les tests sont réussis. Ajustons maintenant le test du générateur séquentiel d'adresses. Nous avons deux nouveaux paramètres de constructeur que nous devons transmettre au service. Tout d'abord, instancions l'usine du générateur d' adresses. transmission d'un nouveau set serait un générateur d' adresses. Ensuite, nous allons passer à 20 le nombre initial d'adresses générées. Maintenant, relancons ce test. OK, nous avons oublié d'ajouter le fournisseur de sécurité dans la méthode de configuration. Réglons ça. Lancez-le à nouveau. OK, le test est réussi. annotation de service ne figure pas dans certains services. Réglons ça. OK, ajoutons maintenant un nouveau Bean, qui correspondra au nombre initial d' adresses générées pour chaque clé étendue, fixera arbitrairement à 20. Maintenant, lançons notre application pour voir comment elle fonctionne. Une erreur s'est produite dans la console indiquant que fournisseur de sécurité ne figure pas dans notre application. Ajoutons-la à la méthode principale de la classe d'application BYOD W. Réexécutons notre application. D'accord, l'erreur ne s'est pas produite, mais il manque toujours une adresse dans le champ de l'adresse de réception . Changeons cela. D'abord. Exécutons tous nos tests pour vérifier quels autres tests doivent être corrigés. Les tests du service Create Wallet ne fonctionnent pas. Réparons-les. Tout d'abord, nous devons inclure un objet générateur séquentiel d'adresses valide comme troisième paramètre. Instancions-le en passant 20 comme premier paramètre et un générateur d'adresses Factory comme second. Ensuite, nous instancierons l'usine comme lors du test précédent. Maintenant, je vais m'assurer que le service de création de portefeuille crée un portefeuille avec deux clés de pub étendues, chacune avec 20 adresses. Affirmera que le premier champ d'adresses clé de pub étendu a une taille de 20. Créons un getter pour ce champ. en sera de même pour la deuxième clé de pub étendue. Maintenant, nous allons exécuter ce test. Super, c'est passé. Faisons maintenant passer le test de création de portefeuille. N'oubliez pas que nous nous attendons à ce que l' adresse de réception TextField contienne une adresse après la création d'un portefeuille. Passons donc au contrôleur de tabulation de réception. Ajoutera une méthode appelée initialize, qui s'exécutera une fois que l'application initialisé ce contrôleur. Ensuite, nous injecterons le portefeuille actuel dans cette classe. Dans la classe de portefeuille actuelle, la classe inclura un nouveau champ de propriété de chaîne simple appelé adresse de réception, qui s' initialisera ici et créera des setters et des getters pour celui-ci. Passons maintenant à l'onglet Recevoir. Fxml ajoutera un ID Fx au TextField. Cet identifiant éthique sera appelé adresse de réception, et nous l'ajouterons également au contrôleur d'onglets de réception. Maintenant, dans la méthode initialisée actuelle de l' adresse de réception du portefeuille sera propriété actuelle de l' adresse de réception du portefeuille sera liée à un écouteur qui prendra ces trois paramètres dans une fonction Lambda. Dans le corps Lambda, le champ d'adresse de réception sera défini sur la nouvelle valeur, qui sera une adresse. Désormais, dans la mise à jour, le service de portefeuille actuel définira l' adresse de réception du portefeuille actuel sur la première adresse de la clé pub étendue du premier portefeuille. Désormais, lorsque l' adresse de réception est modifiée de cette façon, cela déclenche cet écouteur que nous avons défini ici dans le contrôleur de l'onglet Réception. Et j'espère qu'il ajoutera l'adresse dans le champ de l'adresse de réception. Maintenant, exécutons ces tests pour voir s'ils fonctionnent. Groupes. C'est un échec. Découvrons pourquoi. D'accord, l'erreur s'est produite car cette méthode doit être initialisée et non initialisée. Réparons-le et lançons l'application. Génial. Le portefeuille a répondu à nos attentes et a rempli le champ d'adresse de réception une fois que nous l'avons créé. Maintenant, si nous présentons cette adresse à quelqu'un, il peut lui envoyer des bitcoins. Maintenant, nous allons exécuter tous les tests d'application. Super, ils sont tous passés. 21. 19 Créer notre première partie de portefeuille 10 skillshare 2: Dans cette vidéo, nous allons rapidement modifier le générateur d'adresses de segments. Au lieu de coder en dur le préfixe du segment réseau principal en tant que paramètre de l'adresse du segment à partir clé publique compressée, la méthode créera un service qui nous permettra de créer des adresses pour les environnements de test Test Net et Reg . Nous appellerons cette adresse de service prefix factory. Il aura une méthode get dans laquelle nous transmettrons un type d'adresse et renverrons un préfixe d'adresse. Cette valeur renvoyée sera utilisée comme paramètre pour l'adresse du segment à partir de la méthode de clé publique compressée. Nous allons maintenant injecter ce service dans cette classe et le créer. Nous allons maintenant créer la méthode It's GET. Pour implémenter cette méthode, vous aurez besoin d'une carte auxiliaire, qui associera les types d'adresses à une autre carte, mappant les trois environnements les préfixes d' adresses correspondants. Construisons-le et ce que je voulais dire deviendra clair. Maintenant, changeons le nom de ce paramètre en type d'adresse. Dans la méthode GetMethod, un préfixe d'adresse sera renvoyé en utilisant le type d'adresse comme première clé. Et une variable appelée environnement Bitcoin comme deuxième clé de la carte que nous venons de créer. La variable d'environnement Bitcoin sera définie ultérieurement dans le fichier de propriétés de notre application, et nous l' injecterons dans cette classe. Maintenant. Dans le constructeur, nous ajouterons une annotation de valeur avant la variable pour injecter sa valeur depuis le fichier de propriétés. Maintenant, saisissons correctement le champ de la carte du type d'adresse. Ajoutons maintenant la configuration de l'environnement Bitcoin au fichier de propriétés point de l'application. Nous allons le configurer pour qu'il soit testé. Corrigons maintenant quelques fichiers de test pour gérer les modifications que nous avons apportées jusqu'à présent. commençant par le test du générateur d' adresses de segment, je supprimerai cette partie et instanciera le générateur d'adresses de segment dans la méthode de configuration, en passant le préfixe d'adresse factory comme paramètre. Nous allons maintenant instancier la fabrique de préfixes d' adresse en passant la constante réseau principale en paramètre. Maintenant, lançons ce test. Super, ça continue de fonctionner. Corrigons maintenant le test du service Create Wallet. Nous ferons la même chose que lors du dernier test. Il suffit d'injecter le préfixe d' adresse factory dans le générateur d' adresses de segment. Faisons le test. Super, c'est passé. Corrigons maintenant le test du générateur séquentiel d'adresses. Nous ferons comme avant. Maintenant, faisons le test. Super, il est passé deux heures. Maintenant, nous allons exécuter tous nos tests. Certains tests ont échoué car il manque une annotation dans la fabrique de préfixes d'adresses . Réglons ça. Réexécutez les tests. Génial. Tous les tests ont réussi. Faisons maintenant cette petite modification en ajoutant des importations statiques pour ces constantes. Maintenant, lançons l'application pour voir ce que nous avons accompli jusqu'à présent. N'oubliez pas que nous nous attendons maintenant à ce que notre portefeuille génère des adresses compatibles avec reg test puisque notre propriété d'environnement Bitcoin est configurée sur reg test. D'accord, comme prévu, notre portefeuille a généré des adresses commençant par BCR t, puisqu'il s'agit du préfixe des adresses de segment dans l'environnement de test reg. Changeons maintenant la propriété d' environnement Bitcoin two main net et exécutons à nouveau l'application. Nous avons maintenant des adresses commençant par BC, qui est le préfixe d'adresse de segment du réseau principal. Enfin, changeons la propriété d'environnement Bitcoin pour tester net et essayer de même. OK, nous pouvons maintenant générer des adresses commençant par TB, qui est le préfixe pour les adresses de test compatibles avec le réseau. Super, nous avons maintenant un moyen simple de modifier l'environnement réseau compatible avec notre portefeuille. 22. 20 Préparer un nœud pour recevoir des bitcoins skillshare 2: Nous disposons désormais d'un portefeuille Bitcoin capable de générer des adresses compatibles avec différents environnements de réseaux Bitcoin , à savoir reg , test, net et réseau principal. Il est déjà possible d'utiliser ces adresses pour recevoir des Bitcoins. Pour cela, il vous suffit de les montrer aux autres propriétaires de bitcoins, qui peuvent utiliser leur portefeuille pour vous envoyer des Bitcoins, ou très probablement des Satoshi, qui sont des fractions de Bitcoin. Mais pour l'instant, notre portefeuille est activé pour détecter ces paiements. Rien ne se passera donc dans l'interface utilisateur de notre portefeuille après une transaction à l'une de nos adresses. À partir de maintenant, nous avons pour objectif de changer cela. Nous allons commencer à créer une fonctionnalité qui nous permettra d'écouter les transactions qui arrivent dans notre nœud principal Bitcoin. Ensuite, nous filtrerons les transactions dont les sorties correspondent aux adresses actuelles de notre portefeuille. Enfin, nous modifierons notre portefeuille pour afficher des informations sur le montant de Bitcoin que contient notre portefeuille. Assurons-nous maintenant que notre nœud Bitcoin est correctement configuré et prêt à envoyer et recevoir des informations sur les transactions vers notre portefeuille. Pour cela, ouvrez le fichier bitcoin.com. L'emplacement de ce fichier dépend du système d'exploitation que vous utilisez. Comme j'utilise Windows Ten, mon fichier bitcoin.com se trouve dans le chemin à l'écran. Ouvrez le fichier et assurez-vous qu'il ressemble à ceci. Passons en revue la signification de chacune de ces configurations. Le premier paramètre, reg test, est défini sur un pour que notre nœud fonctionne dans les environnements de test reg. Puisque nous utiliserons l'environnement de test reg pour nous aider à développer notre application. Le deuxième paramètre, les données s' y trouvent, est défini dans le dossier dans lequel vous souhaitez que le nœud enregistre les informations relatives à la blockchain et au portefeuille. J'ai défini le mien sur les données Bitcoin avec deux points, mais vous pouvez choisir le chemin que vous préférez. Le paramètre serveur est défini sur un pour permettre à notre nœud de recevoir des appels d'API depuis notre application. Les paramètres d'utilisateur et de mot de passe RPC peuvent être définis comme vous le souhaitez. Pour l'instant, je vais choisir BYUI W pour les deux. Mais lorsque vous utilisez notre application pour de vrai, il est fortement conseillé de choisir valeurs plus sûres pour ces paramètres. L'indice TX est défini sur un. Cela est nécessaire pour permettre à notre nœud de récupérer toutes les informations de transaction de la blockchain. Le paramètre de frais de secours peut être défini sur 0,00 001. Cette valeur sera utilisée pour les frais de transaction qui pas pu être calculés correctement par le nœud. Enfin, nous allons attribuer cette valeur à la propriété z MQ pub Ratti x. Cette propriété définit l'adresse TCP à laquelle les informations de transaction qui vont les informations de transaction qui arrivent au nœud. notre application, nous écouterons la même adresse TCP et capturerons les nouvelles transactions envoyées à l'une de nos adresses Bitcoin de cette façon. Maintenant, exécutons notre nœud Bitcoin avec ces configurations à l'aide du terminal, accédez au dossier où votre application Bitcoin est installée. Cela dépend de l' endroit où vous l'avez installé et du système d'exploitation que vous utilisez. Comme j'utilise Windows Ten, j'ai déjà ouvert mon terminal et je suis allé dans ce dossier à l'écran. Exécutez maintenant le nœud Bitcoin en tapant la barre oblique Bitcoin D et en appuyant sur Entrée. Votre nœud principal Bitcoin fonctionne maintenant avec les configurations. nous l'avons dit précédemment, nous sommes maintenant prêts pour les prochains cours. 23. 21 Nœud client partie 1 skillshare 2: Dans cette vidéo, nous allons créer un client HTTP qui effectuera des appels vers notre nœud principal Bitcoin. Ce client sera nécessaire ultérieurement lorsque nous l'utiliserons pour envoyer et recevoir des transactions. Nous allons d'abord importer une dépendance dans le fichier POM. Cette dépendance est le Spring Boot Starter Web, qui est nécessaire à l'implémentation du client HTTP exclura une dépendance transitive de cette bibliothèque en ajoutant une balise d'exclusion. La dépendance exclue sera le Tomcat Spring Boot Starter. Nous le ferons pour éviter de démarrer un serveur Web dans notre application. Cliquez maintenant sur le bouton Charger Maven Changes. Créons maintenant une classe de configuration pour le client de nœud. Créez une classe appelée Configuration du client Node dans le package api point config en y ajoutant une annotation de configuration. Nous allons maintenant créer des propriétés privées dans cette classe, toutes précédées d'une annotation de valeur. Dans un premier temps, nous aurons cette annotation de valeur. Et cela s'appellera Node RPC URI. La suivante comportera cette annotation de valeur. Et ce sera le nom d'utilisateur RPC du nœud qui aura une autre propriété avec l'annotation de valeur suivante avec le nom égal au mot de passe RPC du nœud. Toutes ces propriétés seront injectées à partir de valeurs qui seront ajoutées plus tard dans l'application. Le fichier de propriétés des points créera également un faisceau avec la classe de modèle Rest. Il faudra un générateur de modèles Rest comme paramètre. Nous utiliserons ce générateur pour renvoyer un objet modèle d'arrestation avec un URI racine égal à la propriété note RPC URI. Il disposera d'une authentification de base avec le nom d'utilisateur RPC de la note et les propriétés du mot de passe RPC de la note. Ensuite, nous appellerons Build and return. Attribuons maintenant les propriétés qui seront injectées dans cette classe. Passons au fichier de propriétés des points de l'application. Attribuons à la propriété node point RPC point URI l'adresse suivante. Cet URI avec le port 18443 est l' URI par défaut de l'API RPC Bitcoin Core Node pour l'environnement de test reg. En tant que propriété node point RPC point username, vous devez choisir la même valeur que celle que vous avez choisie pour la configuration utilisateur RPC dans votre fichier bitcoin.com tant que propriété de mot de passe node point RPC point, choisissez la même valeur que celle que vous avez définie pour la configuration du mot de passe RPC sur votre site bitcoin.com. Maintenant, dans le package api point services, créez le package de nœuds, invitez, créez le package client. Créons maintenant la classe client node à l'intérieur de celle-ci. Ajoutons-y l' annotation du service. Maintenant, injectons le reste du modèle de bean dans cette classe. Nous allons ajouter la méthode suivante pour envoyer des requêtes à l'API Bitcoin RPC. Quant à ses paramètres, il faudra une méthode de chaîne, une référence de type paramétrée de type node client response, qui créera ensuite une URL de chaîne et zéro objet ou plus. Créons maintenant la réponse conforme au nœud dans le nœud point des domaines du package. méthode Back to the node client instanciera un nouvel objet de demande de client de nœud. Il prendra les arguments de méthode et de paramètres dans son constructeur. Créons cette nouvelle classe dans les domaines, ce package de nœuds. Créons son constructeur. Nous allons maintenant encapsuler la demande dans un objet d'entité HTTP. Ensuite, nous renverrons le résultat de cet appel de méthode, qui enverra finalement une demande de publication au nœud Bitcoin Core, ajustera la classe de réponse du client du nœud, transformera en qui enverra finalement une demande de publication au nœud Bitcoin Core, ajustera la classe de réponse du client du nœud, la transformera en enregistrer et y ajouter une propriété de résultat apportera un ajustement similaire à la demande du client du nœud, transformera en enregistrement et y ajoutera ces champs. Nous avons oublié de mettre un T ici. Nous allons maintenant voir comment passer un appel important à l'API Bitcoin Core Node. Accédez à ce site Web à l'écran. Il s'agit d'une référence à l'appel RPC Create Wallet Bitcoin Core. Nous voyons dans la dernière ligne que cette clé appelée prend une clé de méthode avec le portefeuille value create dans son corps. Chaque appel d'API Bitcoin a ce format avec la clé de méthode contenant le nom de la méthode. appels d'API Bitcoin ont également une clé de paramètres contenant différents types de données. Dans ce cas, sa valeur est un tableau avec un seul élément. Le nom du portefeuille, appelé create wallet crée un portefeuille dans le Bitcoin Core et le charge. De nombreux appels d'API que nous utiliserons ultérieurement seront nécessaires. Mais notre nœud principal Bitcoin a un portefeuille chargé. Revenez au client du nœud. Nous pouvons maintenant comprendre pourquoi la méthode make request crée un objet de requête qui prend un argument de chaîne appelé method et un argument de type variable appelé params. Créons maintenant une classe appelée node create wallet client. Ajoutons-y une annotation de service. Y injectera le client du nœud. Nous allons maintenant créer une méthode appelée create, qui prendra un paramètre de chaîne. Passons maintenant à la méthode de création de portefeuille de l'API Bitcoin Core. Nous les appellerons méthode make request du client node comme ceci, suivant la référence du site Web Bitcoin Core. Nous allons maintenant tester cette méthode pour cela. Exécutons notre nœud Bitcoin Core dans le terminal. Au lieu d'utiliser notre méthode TDD traditionnelle, nous testerons cette méthode différemment. De retour au nœud Create Wallet, le client créera une méthode précédée d'une annotation après la construction. L' annotation de construction Post est utile pour exécuter du code lors du démarrage d'une application Spring. Il est également utile pour les tests rapides et les applications Spring , un peu comme pour créer une méthode statique principale dans une classe Java, mais avec tous les avantages des beans gérés par l'application. À l'intérieur de cette méthode, vous appellerez la méthode create en passant n'importe quel nom de portefeuille. Lancer l'application. D'accord, en regardant les journaux du nœud Bitcoin Core dans le terminal, nous voyons que notre nœud a créé et chargé un portefeuille avec le nom que nous avons indiqué dans l'appel à la méthode. Avec cela, nous savons que notre méthode fonctionne et pouvons supprimer cette méthode de post-construction. Maintenant, revenons sur le site Web de Bitcoin Core et recherchons la méthode DIR du portefeuille de listes. Cette méthode ne prend aucun paramètre et renvoie tous les portefeuilles de nœuds créés jusqu'à présent. Il renvoie une structure JSON avec un champ de portefeuilles. Ce champ contient un tableau d'objets, chacun représentant un portefeuille existant avec un champ de nom. Créons un client pour cette méthode. Nous l'appellerons liste des nœuds tant que c'est client. Encore une fois, injectons le client de nœud dans cette classe. Ensuite, nous allons créer la méthode list all, qui renverra une liste de noms de portefeuilles. À l'intérieur de cette méthode, ils les appelleront la méthode make request depuis le client du nœud en passant liste du portefeuille DIR comme nom de méthode. Une nouvelle référence de type paramétrée et une URL vide. Nous ne transmettrons aucun paramètre supplémentaire. L'objet renvoyé sera un enregistrement de portefeuille de nœuds, qui sera créé maintenant, nous allons le créer dans le package de nœuds à points du domaine. Cet enregistrement ne comportera qu'un seul champ. Ce sera une liste de portefeuilles de nœuds. Son nom sera Wallets. Créons l' enregistrement du portefeuille de nœuds dans le même package. Son seul champ sera un nom de chaîne. N'oubliez pas que nous modélisons ces objets sur la base de cette référence du site Web Bitcoin Core. Mais le champ wallets sur l'enregistrement des portefeuilles du nœud correspond au nom de ce champ dans la réponse JSON de l'appel d'API. Il en va de même le champ de nom de l'enregistrement du portefeuille de nœuds. Le champ « portefeuilles » de la réponse contiendra une liste d'objets avec le champ « nom ». Chacun de ces objets sera stocké sous forme d'enregistrements NerdWallet sur l'application pour revenir à la liste des nœuds lorsqu'elle est client. Dans la liste, toutes les méthodes renverront une liste de noms de portefeuilles. Pour ce faire, nous allons récupérer les portefeuilles à partir des portefeuilles de nœuds. Ensuite, nous appellerons stream, puis cartographierons en transmettant une référence au champ du nom du portefeuille de nœuds. Ensuite, nous convertirons le résultat en liste et le renverrons. Maintenant, testons la méthode list all en utilisant une méthode annotée avec Post construction affichera chaque élément renvoyé par l'appel à la méthode list all. Sur cette ligne de la console, nous voyons que l' application enregistre le nom du portefeuille de nœuds que nous avons créé. Génial. Nous allons maintenant implémenter un autre client pour appeler la méthode d'API Node appelée list wallets. La différence entre cette méthode et le portefeuille de liste DIR est que les portefeuilles de liste renverront uniquement les portefeuilles actuellement chargés par le nœud. Il renvoie également une liste de noms de portefeuilles sans les encapsuler dans des objets. Créons maintenant la méthode chargée par liste. Il renverra une liste de noms de portefeuilles. Pour cela, il suffit de renvoyer cet appel de méthode. allons maintenant le tester de la même manière que nous avons testé la liste. Je vais appeler. Nous pouvons le voir depuis la console, mais notre application enregistre deux fois le nom du portefeuille que nous avons créé. Le premier était dû à l'appel de méthode list all, et le second était dû à l'appel de méthode chargé par liste. Maintenant, pour voir la différence entre les deux appels de méthode, nous allons procéder comme suit. Mettez fin à l'application Bitcoin Core Node en appuyant sur Control plus C sur le terminal. Maintenant, redémarrez le Bitcoin Core Note. Faisons maintenant le même test. Mais d'abord, ajoutez ces lignes avant les appels de méthode pour différencier chaque méthode. Depuis la console, nous voyons que seul l'appel à la méthode list all a renvoyé le portefeuille créé. Cela montre qu'après avoir démarré l'application Bitcoin Core Node, nous devons charger le portefeuille que nous utiliserons, afin de pouvoir effectuer d'autres appels d'API nécessitant le chargement d'un portefeuille de nœuds. Mais nous verrons comment cela fonctionne en pratique dans les prochaines vidéos. 24. 22 Noeud client partie 2 skillshare 2: Dans cette vidéo, nous continuerons à mettre en œuvre d'autres méthodes qui nous permettront d'interagir avec notre nœud Bitcoin depuis notre application. La première est une méthode qui chargera un portefeuille de nœuds. Lorsque vous exécutez votre nœud, vous devez charger un portefeuille pour pouvoir appeler de nombreuses autres méthodes de nœud. Créons donc le client Node Load Wallet. Comme toujours, dans une annotation de service y afférente. Nous allons maintenant y injecter le client du nœud. Ensuite, nous allons créer la méthode de chargement, qui prendra le nom du portefeuille comme paramètre. Ensuite, nous les appellerons simplement la méthode make request depuis le client du nœud comme ceci. Maintenant, testons cette méthode à l'aide d'une construction de post-construction. Tout d'abord, supprimons cette méthode de post-construction que nous avons créée auparavant. Nous allons maintenant appeler la méthode de chargement en passant le nom du portefeuille que nous avons créé. Avant de l'exécuter, exécutons notre nœud Bitcoin dans le terminal. D'accord, d'après les journaux du terminal, nous voyons que notre nœud a correctement chargé notre portefeuille. Nous allons maintenant créer un service utile pour charger un portefeuille de nœuds s'il existe déjà et n'est pas chargé. Si un portefeuille portant ce nom existe déjà et qu'il est déjà chargé par le nœud , la méthode ne fera rien et nous y retournerons. Enfin, s'il n'existe pas de portefeuille portant ce nom, la méthode le créera et le nœud sera automatiquement chargé puisqu'il charge un portefeuille après sa création. Ainsi, dans le package services point node, créons un nom de classe, chargeons un nœud ou créons un service de portefeuille. Injectons-y les clients suivants. Le nœud crée le client de portefeuille, le nœud charge le client de portefeuille et la liste des nœuds en tant que client. Nous allons maintenant créer une méthode nommée load ou create wallet. Il prendra un nom comme paramètre. À l'intérieur, il appellera la méthode list all à partir de la liste des nœuds. Le client des portefeuilles stockera le résultat dans une variable appelée tous les portefeuilles. Ensuite, nous appellerons la méthode chargée par liste depuis le même client. Et nous allons stocker le résultat dans la variable wallets chargée. Nous allons maintenant ajouter une instruction if vérifiant la condition suivante. Si cette condition est évaluée comme vraie, cela signifie que le portefeuille portant ce nom existe déjà et qu'il est chargé par le nœud. Si tel est le cas, nous n'avons rien à faire et pouvons revenir. Maintenant, nous allons ajouter la déclaration if suivante. Si cette instruction renvoie la valeur true, cela signifie qu'un portefeuille portant ce nom existe déjà, mais qu'il n'est pas chargé par le nœud. Si tel est le cas, nous appellerons la méthode load depuis le client node load wallet en transmettant le nom du portefeuille et en la renvoyant. Enfin, si l'exécution du code donne une valeur fausse aux instructions IF précédentes, cela signifie qu'il n'existe pas de portefeuille portant ce nom. Dans ce cas, nous créons simplement le portefeuille, appelant la méthode create depuis le client node create wallet et en transmettant le nom du portefeuille. OK, la méthode est terminée. Nous l'utiliserons dans les prochaines vidéos. Créons maintenant un autre client utile. Il s'appellera Node get new address client. Comme son nom l'indique, il sera utilisé pour générer une nouvelle adresse à partir de notre portefeuille de nœuds chargé. Injectons donc le client du nœud dedans. Nous allons maintenant créer une méthode nommée get new address. Il renverra l' adresse sous forme de chaîne. Et il prendra le nom du portefeuille comme paramètre. Ensuite, nous reviendrons pour effectuer un appel de méthode de demande depuis le client du nœud avec ces paramètres. Notez que nous avons défini le paramètre URL sur la chaîne Wallet slash the name of the wallet. C'est ainsi que nous indiquons à notre nœud que nous voulons obtenir une adresse provenant de ce portefeuille spécifique. Nous allons tester cette méthode. Pour cela, nous allons créer la construction Post suivante méthode annotée appellera la méthode get new address en passant le nom d' un portefeuille que nous avons chargé précédemment comme paramètre. Si nous appelons cette méthode sans charger d'abord ce portefeuille, cela ne fonctionnera pas et le nœud renverra une erreur. Nous stockerons le résultat de l'appel de méthode dans la variable d'adresse et nous l'imprimerons. Mettons-le à l'essai. Le journal de la console montre qu'elle a généré et imprimé une adresse de test d' enregistrement du segment Bitcoin. Génial. Prenez note de l'adresse que vous avez générée. Nous l'utiliserons pour tester la méthode que nous allons implémenter ensuite. Nous allons maintenant créer une méthode qui sera utilisée pour traiter certains blocs produisant des Bitcoins à une adresse. Cette méthode ne fonctionne que sur l'environnement de test reg, et elle nous sera utile lors de certains tests qui nécessitent un nombre initial de pièces pour jouer. Créons une classe appelée no degenerate pour s'adresser au client. Comme d'habitude, nous allons y injecter le client du nœud. Ensuite, nous allons créer une méthode appelée generate to address. Il prendra comme paramètres un nom de portefeuille, un certain nombre de blocs et une adresse. Ensuite, nous les appellerons la méthode make request depuis le client du nœud avec les paramètres suivants. Encore une fois, nous allons transmettre la chaîne Wallet et slash à la variable name. Ensuite, nous transmettrons le paramètre blocks, qui indique le nombre de blocs que vous souhaitez générer. Enfin, nous transmettrons la variable d'adresse, qui est l'adresse qui recevra les Bitcoins générés. Maintenant, testons cette méthode. D'abord. Supprimons la méthode annotée de construction du post précédent . Maintenant, nous allons faire en sorte que cette méthode de post-construction appelle la méthode generate to address, en transmettant le nom d' un portefeuille chargé. Encore une fois, si vous transmettez le nom d'un portefeuille qui n'existe pas ou qui n'est pas chargé, la méthode fonctionnera. Nous allons créer 1 000 blocs et transmettre l'adresse générée précédemment. Laissons-le fonctionner. Si nous inspectons les journaux de nos nœuds, nous voyons que certaines lignes indiquent que notre méthode appelée a fonctionné. Le dernier client à créer pour cette vidéo s'appellera Node get balanced client. Il sera utilisé pour vérifier le solde de nos portefeuilles. Injectons le client du nœud dedans. Ensuite, nous créerons la méthode get, qui renverra le nombre de bitcoins que contient notre portefeuille. Il prendra le nom du portefeuille comme argument. Ensuite, nous allons renvoyer cet appel de méthode. Comme les méthodes précédentes. Cette méthode enverra au Wallet une barre oblique sur le nom du portefeuille en tant que paramètre URL afin de définir le retour du solde de ce portefeuille spécifique. Testons cette méthode à l'aide d'une post-construction. Appellera la méthode get en passant le nom d'un portefeuille précédemment chargé. Encore une fois, cette méthode ne fonctionnera pas. Si l'ancien portefeuille n'est pas chargé par le nœud, nous stockerons le résultat de l'appel dans une variable et l' imprimerons . Mettons-le à l'essai. Génial. D'après les journaux, nous voyons que nous avons maintenant des milliers de Bitcoins. Bien entendu, ces bitcoins ne sont valables que dans notre environnement de test officiel. Dans les prochaines vidéos, nous les utiliserons pour les tests. 25. 23 Noeud client partie 3 skillshare 2: Dans cette vidéo, nous allons créer un client qui nous permettra d'envoyer bitcoins depuis notre portefeuille Node vers n'importe quelle autre robe rouge de notre choix. Ensuite, nous utiliserons tous les clients que nous avons créés jusqu'à présent pour créer un test permettant de recevoir des bitcoins à une adresse de notre portefeuille d' applications. Donc, après avoir supprimé toutes les méthodes de construction précédentes des leçons précédentes, créons une classe appelée nœuds envoyés au client d'adresse. Injectons maintenant le client du nœud dans celui-ci. Ensuite, nous allons créer une méthode nommée send to address en tant que paramètres ou nom et adresse du portefeuille et montant. Ensuite, nous les appellerons la méthode make request depuis le client du nœud en transmettant les paramètres suivants. Encore une fois, nous allons transmettre Wallet à slash à la variable du nom du portefeuille. Ce sera le portefeuille d'où les bitcoins seront envoyés. Il faudra également une adresse à laquelle les bitcoins seront envoyés et un montant, qui correspond au montant transféré en Bitcoins. Nous allons tester cette méthode. Tout d'abord, assurez-vous que votre nœud est en cours d'exécution. Dans mon cas, il va falloir que je commence. Maintenant, assurons-nous que notre portefeuille de nœuds est financé par des Bitcoins afin que nous puissions envoyer des bitcoins à partir de celui-ci appellerons la méthode get balanced pour vérifier cela. Mais cette fois, nous l' appellerons depuis le terminal. Chaque méthode d'API que nous pouvons appeler depuis notre application peut être appelée depuis le terminal à l'aide l'application Bitcoin CLI. Ouvrez une autre fenêtre de terminal, accédez au dossier dans lequel votre nœud est installé. Tapez ensuite la commande suivante pour charger un portefeuille créé précédemment et appuyez sur Entrée. Dans mon cas, après avoir chargé le portefeuille, je dois taper le nom du portefeuille de test, qui est le nom du portefeuille que j'ai créé entre guillemets doubles. OK, maintenant que notre portefeuille est chargé, nous pouvons entrer d'autres commandes qui l'exigent. Entrez donc cette commande pour vérifier le solde de notre portefeuille. Eh bien, c'est équilibré, c'est zéro. Il semblerait que chaque fois que nous redémarrons le billet et l'environnement de test Reg, nos fonds disparaissent. Pas de problème Nous financerons notre portefeuille de nœuds. Maintenant, en utilisant l'interface de ligne de commande. Pour ce faire, nous obtenons d'abord une nouvelle adresse de notre nœud alors que c'est comme ça. Ensuite, nous appelons la commande generate to address pour générer 1 000 blocs et destinons les récompenses par bloc à l'adresse que nous venons de générer. Maintenant, appelons à nouveau la commande Get balanced. Génial. Nous voyons que notre portefeuille contient désormais des milliers de Bitcoins. Encore une fois. Revenons maintenant au nœud d' envoi au client d'adresse. Créons une méthode de post-construction pour tester la méthode d'envoi à l'adresse. Appellera la méthode d'envoi à l'adresse en transmettant le nom du portefeuille chargé. Le deuxième paramètre peut être n'importe quelle adresse de test reg. Nous utiliserons l'interface de ligne de commande Bitcoin pour générer une nouvelle adresse. Ensuite, nous le transmettrons comme deuxième paramètre à la méthode send to address. Ensuite, nous en choisirons un comme montant. Laissons-le fonctionner. D'accord, si nous appelons la méthode Get balanced depuis la CLI Bitcoin, nous verrons que notre équilibre a à peine changé. Il y a une petite différence entre le solde actuel et le solde précédent. Cette différence est due aux frais de transaction puisque nous avons transféré un Bitcoin à une adresse provenant du même portefeuille de nœuds, si nous appelons la méthode get received by address depuis la CLI. En passant l'adresse, nous avons envoyé un Bitcoin au chiffre zéro comme deuxième paramètre, ce qui indique que nous voulons obtenir le solde, y compris les transactions non confirmées, y compris les transactions non confirmées, la valeur un, qui est le montant que nous transférons à cette adresse. OK, nous avons fini de jouer à notre CLI pour le moment. Supprimons la méthode de construction Post. Maintenant, dans le package BYOD, un point gooey créera le test de réception du Bitcoin. Ce test aura besoin de beaucoup de points communs avec le test de création de portefeuille. Nous allons donc lui faire étendre une classe abstraite que nous allons créer appelée GUI test. Cette classe aura toutes les méthodes communes à tous les tests d'interface graphique dont nous avons besoin. Créons-le donc. Dans le test de création du portefeuille, toutes les propriétés et méthodes sauf la dernière seront supprimées et transférées vers la classe de test de l'interface graphique. Ensuite, nous y ajouterons l'annotation de test Spring Boot, et cela étendra la classe de spécification de l' application. Nous allons supprimer la même annotation du test de création de portefeuille et étendre à la classe de test de l' interface graphique. Supprimons toutes les importations non utilisées. Désormais, toutes les propriétés privées de l'interface graphique seront protégées par test et incluront ce point de sécurité, ajoutez appel au fournisseur dans sa méthode de démarrage. Enfin, nous allons rendre ce cours abstrait. Maintenant, testons le test de création de portefeuille pour voir si tout continue de fonctionner comme avant erreur ne s'est produite. Selon mon intuition, il s'agit d'un bogue conceptuel d'IntelliJ. Pour y remédier, appelons-les méthode Maven Clean Lifecycle. Reconstruisons également le projet et exécutons tous les tests d'application. Tous les tests ont réussi. Il ne s'agissait donc que d'un bogue IDE. Maintenant, continuons à construire notre test de réception de Bitcoin y injectera les haricots suivants. Le nœud envoie au client d'adresse, le nœud charge ou crée un service de portefeuille. Le nœud est équilibré, client. Et le nœud obtient une nouvelle adresse client. *****. Il semblerait que nous ayons oublié d'ajouter le mot client et que le nœud obtient une nouvelle adresse. Renommez-le. Créons maintenant une méthode de configuration qui s'exécutera avant que cette classe ne soit testée. À l'intérieur, il appellera la méthode load or create wallet à partir du nœud load ou create wallet service car son paramètre transmettra la chaîne, testera le portefeuille et le stockera dans la constante. Ensuite, nous appellerons la méthode create balance si nécessaire, qui créera ensuite. Avec cette méthode, nous allons d'abord vérifier le solde du portefeuille de test à l'aide du client node get balanced. Si le solde est inférieur à 100 bitcoins, nous obtiendrons une nouvelle adresse à partir du portefeuille de test. Utiliser le node generate pour adresser le client, que nous avons oublié d' injecter dans cette classe, et nous allons le faire maintenant. Nous allons générer 1 000 blocs, finançant ainsi notre portefeuille. Et nous allons rendre cette méthode privée. Cette méthode étant exécutée avant les tests, nous garantissons que nous aurons toujours des Bitcoins que nous pourrons utiliser lors de nos tests. Maintenant, nous allons créer un test appelé « devrait recevoir du Bitcoin ». C'est lorsque le bloc sera similaire au bloque-vent dans le test de création de portefeuille Nous utiliserons les méthodes suivantes pour créer un nouveau portefeuille. Nous allons cliquer sur l'onglet Recevoir. Ensuite, nous rechercherons la valeur dans l'adresse de réception saisie, qui contiendra à ce stade la première adresse de notre portefeuille. Et nous allons le stocker dans la variable d'adresse. Nous allons maintenant appeler la méthode send to address depuis le nœud envoyé au client d'adresse. En tant que paramètres, le nom du portefeuille de test, l'adresse que nous avons générée avec le portefeuille de notre application et le montant 1 seront validés. Après avoir reçu des Bitcoins, nous nous attendons à ce que notre portefeuille d'applications détecte la transaction, mais ce processus ne sera pas immédiat. Cela prendra quelques secondes pour que cela se produise. Pour cette raison, nous utiliserons une méthode appelée wait-for from test fx. Comme ses paramètres passeront dix, ce qui sera la valeur du délai d'attente pour le poids. Dans ce contexte, le délai d'attente est le délai maximum pendant lequel l' application doit attendre avant de lancer une exception de temporisation. Le deuxième paramètre indique l'unité de temps du paramètre précédent. Nous allons donc choisir les secondes. Le dernier paramètre sera une méthode de rappel. À l'intérieur, il recherchera un composant de l'interface graphique avec un identifiant d'adresses. Table, interrogera si elle possède un TableView et stockera son résultat dans une variable du même type. Nous allons ensuite renvoyer la comparaison entre la taille de l' article TableView et une taille. Ce TableView avec une table d'ID d'adresses sera un composant qui stockera un tableau contenant des lignes, chacune avec une adresse approvisionnée de notre portefeuille. La méthode de rappel s'exécute en boucle et ne s'arrête que si la comparaison renvoie la valeur vraie ou si le délai d'attente est atteint. En résumé, cette pondération pour l' appel de méthode aura les effets suivants. Il vérifiera s'il existe un tableau avec une ligne remplie à l'écran. Cela se produira lorsque notre portefeuille détectera qu'une de ses adresses a reçu une transaction et qu'il a rempli une ligne du tableau avec cette information. Il faudra attendre 10 secondes pour que cela se produise ou moins. Si le tableau est rempli d'une ligne auparavant, nous copierons la ligne de recherche pour l' affichage du tableau et la collerons ici. Ensuite, block vérifiera à nouveau si la taille de l'élément TableView est égale à un. Stockons cette valeur de délai d'attente dans une constante. Maintenant, lançons le test. Comme prévu. Le test a échoué car il n'a pas trouvé la table des adresses. Dans la vidéo suivante, nous allons commencer à implémenter cette fonctionnalité dans notre portefeuille. 26. 24 Recevoir des bitcoin partie 1 skillshare 2: Dans cette vidéo, nous allons créer un tableau contenant des informations sur nos adresses. Ce tableau contiendra chaque adresse financée, leur montant en Bitcoin et le nombre minimum de confirmations des transactions vers ces adresses. L'idée est de remplir ce tableau juste après que nos portefeuilles détectent les transactions envoyées à nos adresses. Ainsi, dans le point FXML de la fenêtre principale, si nous cliquons sur l'onglet Scene Builder, nous verrons qu' un message s'affiche pour télécharger Java FX, même si nous l'avons déjà téléchargé. Cela se produit parce que cette fonctionnalité IDE ne gère pas correctement les composants externes, tels que le contrôleur d' onglet Receive. Donc, pour pouvoir utiliser le Scene Builder, vous allez créer un nouveau fichier FXML appelé playground. Dans ce fichier, nous allons coller tout le contenu du point FXML de la fenêtre principale. Mais au lieu d'utiliser des composants externes tels que le contrôleur d' onglet Recevoir, vous les intégrerez dans le fichier. Donc, dans le package resources point FXML, créez le fichier Playground point FXML. Supprimez tout son contenu. Copiez ensuite tout le contenu du point FXML de la fenêtre principale et collez-le. Nous allons maintenant remplacer le contenu de la balise Receive tab controller par le contenu du point FXML de l'onglet Recevoir. Et nous allons modifier la balise racine FX avec la balise tag. Et supprimons son attribut type. Importons la balise Insets. Maintenant, lorsque nous cliquons sur le Scene Builder, nous pouvons l'utiliser normalement. Ajoutons maintenant un nouvel onglet au composant VBox. Supprimons maintenant l'un des onglets créés. Renommons l' onglet restant en deux adresses. Donnons-lui un onglet FX ID d'adresses. présent, dans l'onglet Contenu, nous allons ajouter un composant d' affichage sous forme de tableau. Malheureusement, pour des raisons de bogues, le Scene Builder ne nous permet pas d' ajouter une vue tabulaire à un onglet. Pas de problème. Ajoutons-le à l'aide de l'éditeur de texte. Ajoutons également une table d'idées d'adresses Fx ici. Revenons au Scene Builder. Il a recommencé à fonctionner. Nous avons maintenant un tableau vide dans l'onglet des adresses. Nous allons maintenant ajouter trois colonnes au tableau. Nous allons renommer la première colonne en deux adresses, la deuxième en solde et la troisième en deux confirmations. Ensuite, nous cliquerons sur le tableau et modifierons cette configuration pour qu'elle soit redimensionnée sous contrainte. Désormais, chaque colonne a la même taille et occupe toute la surface du tableau. Maintenant, cliquons sur chaque colonne du tableau et désélectionnons-la. Ce sont des cases à cocher modifiables et triables. Maintenant, pour chaque colonne du tableau leur largeur maximale sera fixée à 100. C'est juste une astuce nécessaire pour ajuster leur taille. Maintenant, ajustons leur taille à l'aide de la souris comme ceci. La colonne des adresses doit être plus grande car les adresses occuperont un espace plus important Les colonnes de solde et de confirmation peuvent avoir la même taille. Revenons à l'éditeur de texte. Changeons l' attribut pref height du volet d' onglet à 355. Pour en revenir au Scene Builder, nous pouvons voir qu'il est plus beau. Modifions également le message d' espace réservé, qui indique lorsque le tableau est vide. Pour cela, il suffit d'ajouter une étiquette vide à l'intérieur de cette balise d'espace réservé. Maintenant que notre composant de table est prêt dans le terrain de jeu, créons un FXML pour celui-ci. Appelons-la table des adresses. Supprimons tout son code standard. Et copions tout le contenu entre la balise TableView et collez-le là-bas. Maintenant, au lieu d'utiliser la balise table view, utilisons la balise racine FX fait référence aux plantes de vue tabulaire et à l'attribut type. Importons les balises restantes. Et ajoutons cet attribut XML et S ici. Revenons maintenant au terrain de jeu FXML. Il manque un ID FX dans l'onglet Adresses. Ajoutons-y. Cette idée a déjà été utilisée par erreur dans le composant VBox. Retirons-le donc de là. Maintenant, copions ces quatre lignes et collez-les dans la fenêtre principale. Maintenant, ajoutons les balises de fermeture et les balises que nous avons copiées. Nous allons maintenant supprimer la balise d'affichage du tableau et ajouter une balise de contenu à sa place. À l'intérieur, il ajoutera une balise de contrôleur de table d'adresses. Créons maintenant ce contrôleur. Ajoutons-y une annotation de composant. Il doit étendre la classe de vue tabulaire avec la classe d'adresse comme paramètre de type. Revenons maintenant à la fenêtre principale. Importons le contrôleur récemment créé. Dans le contrôleur de table d'adresses, créons un constructeur. Il prendra un paramètre FXML avec une annotation de valeur. L'annotation de valeur fera référence à la table d' adresses FXML. Le deuxième paramètre du constructeur sera un objet contextuel d'application. Dans le corps du constructeur, vous allez créer un nouvel objet chargeur FXML, l' initialisant avec ces paramètres. Ensuite, nous allons régler son contrôleur FXML sur cette valeur. Et nous allons définir la voie à suivre pour y parvenir. Ensuite, nous appellerons Load on it. Et nous allons ajouter une instruction Throws au constructeur. Nous devons faire encore une chose pour que cela fonctionne. À l'intérieur de cette instruction if dans l'interface graphique a démarré l'écouteur ajoutez le code suivant. Cela est nécessaire pour que Java FX puisse créer correctement la balise du contrôleur d'adresses. Maintenant, lançons notre application pour voir comment elle fonctionne. Super, d'accord, la table à robes est jolie. Dans les prochaines vidéos, nous allons faire en sorte que cela fonctionne pour nos portefeuilles. 27. 25 Recevoir des bitcoin partie 2 skillshare 2: Dans cette vidéo, nous allons faire en sorte que nos portefeuilles commencent à interagir avec nos nœuds Bitcoin afin de recevoir des informations sur les transactions envoyées à nos adresses. N'oubliez pas que lorsque nous créons un portefeuille, nous générons les 20 premières adresses pour celui-ci. Mais notre nœud Bitcoin ne connaît pas encore les adresses générées. Le nœud Bitcoin doit-il connaître nos adresses pour envoyer activement des informations sur ses transactions à notre application. Par conséquent, nous devons importer les adresses de nos portefeuilles sur notre nœud. Pour cela, nous allons créer un nouveau client de nœud qui en sera responsable. Ainsi, à l'intérieur du package client node point, vous créerez une classe appelée Node Multi Import Address client. Comme les autres clients, il comportera une annotation de service et nous y injecterons le service client du nœud. Avant de créer sa méthode, vérifions la documentation du site Web Bitcoin Core car son API utilisera la multiméthode d'importation depuis l'API du nœud Bitcoin. On voit ici qu'il prend comme paramètre un tableau d'objets. Chaque objet peut avoir de nombreuses clés différentes, mais nous n'en utiliserons que trois. La clé de publication du script, qui peut prendre comme valeur et objet avec une adresse le nœud importera un horodatage, qui correspond à la date à laquelle l' adresse a été générée. Ce paramètre est important pour déterminer dans quelle mesure dans le passé le nœud recherchait les transactions avec cette adresse dans la blockchain Il définira également le paramètre watch only sur true. car notre nœud n'utilisera nos adresses que pour surveiller les transactions dans la blockchain, mais ne pourra pas signer transactions avec ces adresses. Seul notre portefeuille d'applications sera en mesure de signer les transactions sortantes, mais c'est un sujet pour les prochaines vidéos. Revenons à l'IDE, créons une méthode appelée adresses d'importation. Il prendra comme paramètres un nom de portefeuille, une liste d'adresses et une date de création du portefeuille. Nous allons maintenant créer un objet params qui modélisera le multiparamètre d'importation que nous avons vu dans la documentation Bitcoin Core. Cet objet sera une liste d'un nouvel objet que nous allons créer, appelé Node Multi Reimport Dress Params. Créons-le maintenant. Ce sera un enregistrement et nous le créerons dans le package de nœuds à points du domaine. Il aura un nouveau nœud réimporté plusieurs fois, Respire him Script Pub Key Object créera. Il disposera également d'un long champ d'horodatage et d'un champ réservé à la surveillance booléenne. Créons cette classe sous forme d'enregistrement. Il ne comportera qu' un champ d'adresse. Revenez au client à adresses d'importation multiples du nœud. Étant donné que la méthode d'importation d' adresses reçoit une liste d'adresses, nous devons utiliser le code suivant pour la convertir en une liste de robes réimportées à plusieurs nœuds par ohms. Ensuite, nous utiliserons la méthode make request depuis le client du nœud comme suit. Maintenant, testons ce code à l'aide d'une méthode de post-construction. Nous importerons les adresses dans le portefeuille de nœuds avec le nom du portefeuille de test de nom. Et nous utiliserons la date actuelle comme date de création du portefeuille. Comme les adresses. Utilisera ces trois adresses de test d'enregistrement, que vous pouvez trouver dans cette classe comme ressources. Avant d'exécuter ce code, exécutons notre nœud Bitcoin Core et chargeons le portefeuille avec le même nom que nous utiliserons. Pour le charger, vous utiliserez la CLI Bitcoin, comme nous l'avons fait dans les vidéos précédentes. D'accord, en regardant les journaux des nœuds Bitcoin, il semble que cela ait fonctionné. La dernière ligne du journal indique que la nouvelle analyse est terminée. La nouvelle analyse a lieu par défaut après l'importation des adresses dans le nœud. La nouvelle analyse recherche les transactions dans la blockchain pour les adresses récemment importées. Dans ce processus, le nœud recherche les transactions et les blocs créés jusqu'à 2 h avant la date que nous avons passée comme paramètre d' horodatage. Supprimons la méthode de construction Post. Maintenant, dans le package gooey point listeners, créons une classe appelée Created Wallet important Listener. Il comportera une annotation de composant et implémentera la classe d'écoute de l'application avec un paramètre d'événement de portefeuille créé. Mettons en œuvre sa méthode. Tout comme l'écouteur de portefeuille créé, cette méthode class is sera appelée après la création d'un portefeuille. Injectons la charge du nœud ou créons un service de portefeuille dans celui-ci. Désormais, dans la méthode d' événement hors application, la méthode load ou create wallet sera appelée à partir du service injecté passant le nom du portefeuille d'événements comme paramètre. Injectons également le client d'adresses d'importation multiple de nœuds dans celui-ci. Faisons en sorte que les deux services injectés soient définitifs. Nous allons maintenant appeler la méthode d'importation des adresses depuis le dernier service injecté. Mais d'abord, créons une variable pour le portefeuille d'événements et utilisons-la dans cette méthode. Maintenant, dans l'appel d' adresses d'importation, passons le nom du portefeuille. La méthode wallet get addresses, qui créera le portefeuille créé dans l'établissement, que nous créerons également dans l'enregistrement du portefeuille. Créons la propriété CreatedAt date, nous la créerons à l'aide de la fonctionnalité de modification de la signature IDE. Utilisons une valeur par défaut, la nouvelle date. Ce faisant, l'IDE ajoutera automatiquement ce troisième paramètre à chaque instanciation d'un portefeuille qu'il trouve dans le projet. Cliquons sur Refactor et importons la classe de date. Si nous accédons au service de création de portefeuille, nous constatons qu'il a ajouté une nouvelle date comme troisième paramètre dans l'instanciation du portefeuille. Cela donnera au portefeuille la date actuelle comme date de création. Le contrôleur de dialogue Create Wallet utilisera le portefeuille créé lors de l'appel à la méthode d'événement public. Cela déclenchera l'appel de la méthode on Application Event. Créons maintenant la méthode get addresses dans l'enregistrement du portefeuille. Il renverra une liste d' adresses en utilisant les adresses de ses clés de pub étendues, comme ceci. En appelant la méthode FlatMap sur le flux de clés de pub étendues et en renvoyant le flux d' adresses de clés de pub étendues lors de cet appel vous obtiendrez un flux de tous les objets d'adresse du portefeuille. Ensuite, nous appellerons la méthode map pour convertir le flux d'objets d'adresse en un flux de chaînes d' adresses. Enfin, nous allons appeler la méthode des deux listes sur le résultat et renvoyer une liste de toutes les adresses de portefeuille sous forme de chaîne. D'accord, maintenant, après avoir créé notre portefeuille, nous pensons que nos chargements d' applications ont créé un portefeuille portant le même nom dans notre nœud. Ensuite, notre application importera toutes les adresses générées dans notre nœud. Exécutons notre application pour la tester. Créons un nouveau portefeuille. J'ai cliqué sur le bouton OK, mais il semble que rien ne s'est passé. Vérifions les journaux des nœuds. D'accord, après un certain temps, il est indiqué que la nouvelle analyse est terminée et que le portefeuille a terminé sa création. Dans la vidéo suivante, nous allons rendre ce processus asynchrone en exécutant les appels au nœud dans un autre thread. Ce faisant, le gooey ne restera pas bloqué et la création du portefeuille sera plus fluide. Cia. 28. 26 Recevoir des bitcoin partie 3 skillshare 2: Dans la dernière vidéo, nous avons demandé à notre nœud Bitcoin de créer et charger notre portefeuille d'applications et nos adresses importantes. Mais ce processus prenait quelques secondes et bloquait l'interface utilisateur graphique. Dans cette vidéo, nous allons résoudre ce problème en faisant en sorte que la communication avec le nœud s'exécute dans un autre thread de manière asynchrone dans le package BYU OWL. Créons un nouveau package appelé Config. Dans ce package, nous allons créer une classe appelée async config. Cette classe contiendra toutes les configurations liées à l' exécution de code asynchrone dans le projet. Ajoutons-y une annotation de configuration. Et une annotation asynchrone activée pour. Cette annotation est importante pour activer les fonctionnalités asynchrones dans le projet. Créons maintenant une méthode annotée avec l'annotation Bean. Il renverra un ExecutorService. Appelons cela le service exécuteur par défaut. Il renverra un nouvel exécuteur à thread unique à partir de la classe des exécuteurs. Ce bean fournira un thread chaque fois que nous voudrons y exécuter du code. Il s'agira d'un seul thread, ce qui signifie que si deux sections de code ou plus tentent de s'exécuter simultanément dans ce fil, une section devra attendre la fin de l'exécution de l'autre. Nous avons choisi d'utiliser un fil unique car cela facilite le contrôle des processus dans notre application et nous permet d' éviter plus facilement les conditions de course. Maintenant, nous allons refactoriser un peu le code dans le package Gooey Dot Services. Créons une classe appelée import wallet service et ajoutons-y l'annotation du service. Créons une méthode appelée portefeuille d'importation. Transférera le code de l'écouteur d'importation de portefeuille créé vers le service d'importation de portefeuille. Injectons également les services requis dans cette classe. Et ajoutons le portefeuille en tant que paramètre à la méthode d'importation du portefeuille. Dans le portefeuille créé, importez le listener. Supprimons tout ce code. Injectons-y le service de portefeuille d'importation. Maintenant, dans la méthode d' événement sans application, appelons simplement la méthode du portefeuille d'importation depuis le service injecté en passant le portefeuille d'événements comme paramètre. La méthode d'importation du portefeuille contient le code que nous voulons exécuter de manière asynchrone. Pour la rendre asynchrone, il suffit d'annoter cette méthode avec l'annotation asynchrone, transmettant le nom du bean du service d'exécution que nous avons créé. Nous devons également renvoyer une valeur à partir de cette méthode, qui nous permettra de gérer cet appel asynchrone à partir de la couleur de la méthode. La valeur renvoyée sera une valeur future. Un paramètre de type void renverra un nouvel objet de résultat asynchrone transmettant la valeur null à son constructeur. Maintenant, testons la création d'un portefeuille. Mais d'abord, gérons notre nœud Bitcoin. S'il n'est pas déjà en cours d'exécution. Nous constatons que notre portefeuille a été créé immédiatement, mais lorsque nous vérifions les journaux des nœuds, le chargement et l' importation des adresses du portefeuille sont toujours en cours. Génial. Le nœud a terminé la nouvelle analyse. Nos processus de chargement et d'importation de portefeuilles sont donc asynchrones. Faisons maintenant quelques réglages. Passons à l'écouteur d'importation de portefeuille créé. Dans l' événement non lié à l'application, la méthode enregistrera le retour de la méthode d'importation du portefeuille et le stockera dans la variable de résultat. Nous allons faire de cette variable un champ privé de cette classe. Maintenant, nous allons ajouter la déclaration if suivante. Avant d'appeler Import Wallet. Si la variable de résultat n'est pas nulle, nous appellerons la méthode cancel en lui transmettant true comme argument. Cela est nécessaire car si nous essayons de créer un autre portefeuille alors que l'importation n'est pas terminée, nous devrons annuler le processus d'importation du premier portefeuille créé. Faisons un autre réglage de la classe d'application GUI qui remplacera la méthode stop. À l'intérieur, ajoutera le code suivant. Ce code garantira la fermeture du thread créé par notre ExecutorService par défaut après la fermeture notre application. Maintenant, il y a un autre problème avec notre application. Lorsque nous créons un portefeuille sans que notre nœud Bitcoin ne fonctionne, les appels visant à créer ou à charger un portefeuille et des adresses importantes échouent. Voyons comment cela fonctionne dans la pratique en fermant notre nœud Bitcoin et en exécutant notre application. Après avoir créé un portefeuille, il semble que notre application fonctionne normalement, mais c' est parce que les exceptions et autres fils de discussion ne sont pas signalés. Notre portefeuille n' aurait pas pu communiquer avec notre nœud alors que celui-ci était éteint. Lorsqu'il a essayé de le faire, une exception a été déclenchée par le thread et un thread a fini de s'exécuter. Réglons ce problème. Ce que nous voulons que notre application fasse lorsqu'elle crée un portefeuille, c'est essayer indéfiniment de communiquer avec notre note. Si, pour une raison quelconque, il ne peut pas le faire après le premier essai, faites-le, nous utiliserons une annotation Spring Boot appelée retrial. Cette annotation permet à la méthode annotée de s'exécuter à nouveau, si elle génère une exception. Pour l'utiliser, nous devons ajouter les dépendances suivantes à notre fichier POM. Le premier concerne les essais au printemps, le second concerne les aspects liés au printemps. Maintenant, dans la méthode d'importation du portefeuille, ajoutons que l'annotation de réessai lui transmettra également certains paramètres. La première sera l'expression d' exception, qui sera définie comme étant le point de service du portefeuille sur le port de connexion point doit réessayer d'ouvrir et de fermer les parenthèses. Cela fera de l'application appelée une méthode à réessayer avant chaque nouvelle tentative et à ne réessayer si cet appel de méthode renvoie la valeur true. Nous ajouterons également le paramètre max attempts, en le définissant sur la valeur maximale de la constante entière. Ce paramètre permet de réessayer cette méthode indéfiniment. Enfin, ajoutons le paramètre backoff, réglant sur l'annotation backoff, transmettant le paramètre de délai de 1 000. Cela obligera l'application à attendre 1 000 millisecondes ou 1 s avant d'exécuter la méthode à chaque tentative. Créons maintenant cette méthode devrait réessayer. Son type de retour sera un booléen. La méthode renverra la négation du résultat de cet appel de méthode interrompu depuis le thread en cours. Cet appel renverra true si le thread en cours n'est pas interrompu ou faux dans le cas contraire. Par conséquent, si l' application se ferme ou si un autre portefeuille est créé entre chaque nouvelle tentative, ce fil sera interrompu et la méthode d'importation du portefeuille ne sera plus réessayée. Encore une chose pour que l'annotation de nouvelle tentative fonctionne, nous devons ajouter l'annotation de nouvelle tentative activée dans la classe de configuration async. Allons-y. À présent. Exécutons notre application avec notre nœud fermé et faisons quelques tests. Créons un nouveau portefeuille. Maintenant, démarrons notre nœud. À partir des journaux des nœuds, nous voyons que le portefeuille créé a été chargé et que la nouvelle analyse est terminée. À présent. Créons maintenant un autre portefeuille. Les journaux des nœuds indiquent qu'il a également été créé, chargé et importé avec succès . Génial. 29. 27 Recevoir des bitcoin partie 4 skillshare 2: Dans cette vidéo, nous allons continuer à intégrer notre portefeuille à notre nœud. L'étape suivante de l'intégration consiste à écouter les messages que le nœud envoie lorsqu'il reçoit une transaction à une adresse importée. Pour cela, nous allons créer une classe appelée node task, qui comportera une méthode qui s' exécutera en boucle infinie dans un autre thread après le démarrage de l'application. Cette méthode écoutera en permanence les transactions reçues par le nœud vers l'une des adresses actuellement chargées de nos applications. Lorsqu'il en trouvera un, notre application le traitera en conséquence. Créons donc un nouveau package appelé node dans le package BYOD W. À l'intérieur, il créera une classe appelée gooey Started node Listener. Ajoutons-y une annotation de composant. Cette classe sera un écouteur déclenché par l'événement gooey Started publié au démarrage de l'application. Il implémentera donc l'écouteur de l'application avec cet événement comme paramètre de type. Mettons en œuvre sa méthode. Ajoutons le nouveau nœud que le service de tâches créera en tant que champ privé dans cette classe. Créons le nouveau service. Maintenant, injectons-le dans l'écouteur de nœud démarré par l' interface graphique. Dans le cas d'un événement non lié à l'application, la méthode la tâche du nœud appellera la méthode node task run. Créons cette méthode dans la tâche node. Ajoutons l' annotation du service à cette classe. Nous allons maintenant ajouter une dépendance dont la tâche de nœud aura besoin dans le fichier POM. Ce sera la bibliothèque Hero MQ. Cliquons sur le bouton Charger Maven Changes. Cette bibliothèque gère la communication entre l'application et Zero MQ. Zero MQ est un courtier de messages qui reçoit des messages du nœud Bitcoin. Ces messages seront envoyés à une URL locale et collectés par notre application via zéro MQ pour renvoyer la tâche du nœud. Ajoutons l' annotation asynchrone à la méthode run. Passons le service d'exécution de notes en tant que paramètre. Cela permettra à cette méthode de s'exécuter manière asynchrone dans un autre thread géré par le service d'exécution de nœuds que nous allons créer dans la classe de configuration asynchrone Créons le service d' exécution de nœuds. Comme le service d' exécution par défaut, il sera géré par un nouvel exécuteur à thread unique. Maintenant, injectons l'objet socket à partir de zéro MQ dans cette classe. Ce champ sera appelé abonnés car il gérera un abonnement au courtier de messages Zero MQ. Dans la méthode run, définissons le délai de réception des abonnés sur 1 000. Cela ajoutera un délai d'une seconde chaque fois notre application interrogera zéro et Q pour rechercher des messages. Appelons cette méthode d' abonnement des abonnés, en passant les octets de la barre de chaîne TX comme paramètre. Cela permettra à notre application d'écouter uniquement les messages liés au vol de transactions Bitcoin qui sont envoyées à zéro par un nœud. Mq appellera également la méthode de connexion des abonnés lui transmettant la variable z MQ URL. Injectons cette variable dans cette classe. Nous allons ajouter une annotation de valeur à son argument constructeur, en transmettant cette chaîne comme paramètre. Par conséquent, cette valeur de variable sera injectée dans cette classe via une propriété d'application nommée z et l'URL q point sera définie maintenant La valeur de cette variable doit correspondre à la même valeur que nous J'ai intégré notre fichier bitcoin.com. Copions donc la valeur définie pour la configuration z MQ pub rock TX bitcoin.com et collez-la ici. Maintenant, revenons à la méthode node task run pour créer notre boucle sans arrêt. Créons une boucle while. Il s'exécutera tant que le thread en cours n'est pas interrompu. À l'intérieur de la boucle, nous appellerons les abonnés Wreck la méthode STR et stockerons le résultat dans la variable topic. L'épave de la méthode STR demande zéro MQ pour n'importe quel message et renvoie une chaîne si elle en trouve une. Dans notre cas, cette chaîne contiendra le nom du sujet, qui sera égal à ra TX pour les transactions brutes. Ensuite, nous ajouterons une boucle if vérifiant la variable topic. Si son contenu est différent de celui de Ratti x, nous appellerons «  continuer relancer la boucle depuis le début. Si ce n'est pas le cas, nous appellerons la méthode Subscribers Wreck V et stockerons le contenu dans la variable contents. L'épave de la méthode est similaire à celle du rec VNTR, mais renvoie un tableau d'octets au lieu d'une chaîne. À ce stade, ce tableau d' octets contiendra la transaction brute ou le nœud envoyé à zéro MQ. Nous allons maintenant convertir le tableau d'octets dans l'objet de transaction Bitcoin Java. Pour cela, nous allons utiliser le code suivant. Nous devons ajouter une instruction throws IOException à cette signature de méthode. Dans l'interface graphique, Node Listener a démarré. Nous devons également encapsuler l'appel d'exécution dans un bloc try-catch comme celui-ci. Revenons à la méthode d'exécution. Nous allons maintenant utiliser une application , un service d'édition d'événements pour publier un événement. Injectons ce service dans cette classe. D'abord. Nous transmettrons un nouvel événement de réception de transaction à la méthode de publication de l'événement. À la transaction reçue instanciation de l' événement le transmettra ainsi l'objet de transaction avant créer la nouvelle classe d'événements Ajoutons une pièce manquante pour que cette méthode fonctionne. Créons une nouvelle classe appelée configuration des nœuds. Déplaçons-le vers un nouveau package de configuration node point. Ajoutons-y une annotation de configuration. Dans cette classe, nous allons ajouter quelques beans pour tâches de nœud injectées dans l'objet Socket fonctionnent. Le premier bean sera le contexte Z étant. Le deuxième faisceau sera la prise MQ zéro. Il sera nommé abonné. Et il prendra dans sa méthode le contexte Z créé ci-dessus. Il renverra les contextes Z pour créer un appel de méthode socket en passant la sous-constante de type socket comme paramètre. Revenons maintenant au nœud, la tâche créera l'événement de réception de la transaction le créera dans le package node point events. Transmettra la tâche du nœud au superconstructeur et nous injecterons la transaction dans un champ de transaction privé. Créons également une méthode getter pour la transaction. Créons maintenant un package Listeners dans le package node. À l'intérieur. Créons un écouteur reçu par transaction pour cet événement. Ajoutons-y une annotation de composant. Cet auditeur sera chargé de filtrer les transactions reçues en identifiant si elles possèdent des adresses appartenant à un portefeuille actuellement chargé. Il implémentera un écouteur d' application avec l' événement reçu par la transaction comme paramètre de type. Mettons en œuvre sa méthode. Dans cette méthode, nous allons récupérer la transaction événementielle et stocker dans la variable transaction. Maintenant, la première chose que nous allons faire est d'identifier les adresses de sortie de la transaction reçue. Pour ce faire, vous allez créer la variable addresses, qui sera une liste de chaînes. Ensuite, nous lui attribuerons le résultat de l'expression suivante. Mappera les sorties de transaction en passant une méthode d'analyse d'adresses . Maintenant, injectons et créons le service d'analyse d'adresses. Créons-le dans le package node point services. Ajoutons-y l' annotation du service. Maintenant, créons la méthode d'analyse. Il renverra une chaîne et prendra une sortie de transaction comme paramètre. Cette méthode sera chargée d'extraire l'adresse d'une transaction en sortie vers la transaction reçue. L'auditeur convertira le résultat en liste. Ensuite, à des fins de test toutes les adresses analysées seront imprimées. Implémentons maintenant la méthode d'analyse. La première chose que nous allons faire est d'obtenir la clé pub du script de transaction et de l'affecter à cette variable. Ne vous inquiétez pas, nous vous expliquerons ce qu'est une clé de script et vous expliquerons d'autres détails sur la transaction. Dans la vidéo suivante, nous allons renvoyer le résultat de l'instruction switch suivante. Si le type de la clé de publication du script est égal à la constante P2 WP k, h, qui est le type de nos adresses de portefeuille actuelles. Ensuite, nous allons renvoyer le script Pub Key P2, appel à la méthode d'adresse WP k h. Transmission du préfixe d'adresse factory Get method call comme paramètre lui transmettant la constante Segway. L'énoncé de majuscule par défaut sera une chaîne vide. Injectons le préfixe d'adresse factory dans cette classe. Maintenant, faisons quelques tests. Mon nœud Bitcoin fonctionne déjà. Assurez-vous que le vôtre l'est aussi. Passons à la classe de test de réception de Bitcoin et exécutons-la. Le test a échoué car nous n'avons pas encore modifié notre test d'interface graphique pour prendre en compte le contrôleur de table d'adresses. N'oubliez pas que notre listener de démarrage de l' interface graphique gère le problème de l'utilisation de cette condition if. Nous pourrions utiliser la même condition si dans notre fixe, mais faisons-le d'une manière plus nette. Passons à l'événement de démarrage de l' interface graphique. Changeons le type d'application GUI en objet. publierai simplement l'événement gooey started dans notre classe de test d'interface graphique, la même manière que nous l'avons fait ici dans la classe d'application GUI. Dans la classe de test de l'interface graphique, supprimons tout ce code. Maintenant, copions cette ligne de l'application graphique et collez-la ici. Supprimons toutes ces importations non utilisées et ce champ privé non utilisé. Maintenant, relançons le test de réception de Bitcoin. Notre test a échoué, mais nous voyons ici sur les journaux de test que l'application a imprimé deux adresses. Cela s'est produit parce que nous avons imprimé les adresses de la transaction que notre test a effectuée sur l'une de nos adresses de portefeuille. L'une de ces adresses est la nôtre, l'autre est une adresse de changement d' adresse de l'expéditeur. Génial. Nous constatons que ce que nous avons fait jusqu'à présent a porté ses fruits. Faisons quelques refactorisations dans la classe de test de l'interface graphique. Supprimons ces importations inutilisées. Dans la classe d'application GUI. Incluons cette ligne de code qui empêchera notre thread de service d'exécution de notes de s' exécuter après la fermeture de notre application. Dans la vidéo suivante, nous en apprendrons davantage sur les transactions en bitcoins afin de nous préparer à la prochaine étape. 30. Transactions Bitcoin : Entrées, sorties, Scripts et l'ensemble UTXO: Dans cette présentation, nous allons apprendre quelques concepts sur les transactions Bitcoin. Il sera utile de mieux comprendre la mise en œuvre de la réception de Bitcoins dans notre portefeuille d'applications. Récapitulons ce que nous avons appris jusqu'à présent sur les transactions en bitcoins et ajoutons progressivement de la complexité à notre compréhension de celles-ci. Ainsi, une transaction Bitcoin est couramment utilisée pour transférer des Bitcoins d'une personne a à une personne B. Une transaction Bitcoin peut être composée de nombreuses entrées et de nombreuses sorties. Une entrée de transaction indique l'ancien propriétaire du Bitcoin ou l'expéditeur de la transaction. Une sortie de transaction indique le destinataire des pièces ou le propriétaire des pièces après la publication de la transaction. Dans cette image, nous avons une transaction simple avec une entrée et deux sorties. Il est dit qu'un Bitcoin a été transféré par John, qui a signé la saisie de cette transaction. La sortie zéro indique que 0,9 Bitcoins ont été envoyés pour se marier. J'en mets un qui indique que 0,099 Bitcoins ont été renvoyés à John à titre de change. Les montants en bitcoins ne peuvent pas être divisés en entrées. Puisque John voulait envoyer 0,9 Bitcoins pour se marier, il n'avait qu'un seul Bitcoin. Il avait besoin de créer un résultat de changement pour lui-même. Mais son montant est de 0,099 Bitcoins, et non de 0,1 Bitcoins, comme on pouvait s'y attendre. La différence, qui est de 0,001 Bitcoins, correspond aux frais de transaction nécessaires pour que la transaction soit incluse dans la blockchain. À partir de cette image, nous tirons trois leçons. La somme des bitcoins en entrées ne peut pas être inférieure à la somme des bitcoins et des sorties. Le montant du Bitcoin en entrées est fixe alors qu'il peut être choisi à volonté et en sortie étant donné qu' il satisfait à la règle précédente. Enfin, les frais de transaction correspondent à la différence entre la somme des montants en bitcoins en entrées et la somme des montants et des sorties en bitcoins. Augmenter la complexité. Nous avons également découvert les champs qui font partie d' une entrée et d' une sortie de transaction. Et l'entrée fait toujours référence à la sortie d'une transaction précédente. ce faire, il utilise l'identifiant de transaction précédent et l'indice de sortie de la transaction précédente. Il serait redondant que l' entrée contienne un champ de montant. Ces deux champs sont suffisants pour identifier toute sortie de transaction dans la blockchain. Euh, l'entrée de transaction doit également contenir une signature valide produite à l'aide la même clé privée que celle utilisée pour dériver l'adresse de la sortie à laquelle l'entrée fait référence. Notez que la saisie d'une transaction ne comporte pas de champ indiquant le montant du Bitcoin. En effet, son montant est automatiquement égal au montant de sortie auquel il fait référence. La sortie d'une transaction comporte deux champs. L'une est l'adresse utilisée pour recevoir des bitcoins. Et l'adresse est une chaîne codée elle seule, ne révèle pas le propriétaire des pièces. C'est pourquoi nous considérons le Bitcoin comme un pseudonyme. L'autre champ est la quantité qui indique le montant de Bitcoin bloqué par l'adresse. Maintenant, augmentons la complexité une fois de plus expliquant ce que contiennent exactement les entrées et les sorties des transactions. L'entrée de transaction comporte les champs suivants. L'ID de transaction précédent, qui est une chaîne hexadécimale unique, est obtenu en hachant la transaction sérialisée précédente. L'indice de sortie de transaction précédent est un nombre entier. Comme une transaction peut avoir de nombreuses sorties, une sortie spécifique peut être identifiée sans équivoque par son identifiant de transaction et son indice de sortie. Le champ ScriptSig ou témoin. La signature d'entrée est ajoutée au champ ScriptSig dans les transactions non Segway. Dans les transactions Segway, la signature est ajoutée au champ témoin, ce qui n'est pas pris en compte dans la taille de la transaction. La sortie de la transaction comporte les champs suivants. La clé Script Pub. clé Script Pub contient l'adresse décodée et le champ de quantité qui détermine le montant de Bitcoin bloqué par l'adresse. Voyons maintenant comment créer une transaction Bitcoin à l' aide d'un exemple. Notre objectif dans cet exemple est d'envoyer 1,5 bitcoins à cette adresse. Avant de commencer, nous avons une transaction confirmée, ce qui signifie qu'elle est déjà stockée dans la blockchain. Il a une sortie avec deux bitcoins, je peux dépenser puisque j'ai une clé privée qui a été utilisée pour créer son adresse, et qui peut être utilisée pour signer une transaction saisie dans un nouveau transaction. Créons donc une nouvelle transaction, nous y ajouterons une entrée. L'entrée que nous ferons référence à notre transaction via le champ ID de transaction précédent. L'indice de sortie des transactions précédent est nul, puisqu'il s'agit de l' indice de sortie de notre sortie. Le champ ScriptSig est composé d'une signature produite l'aide de la même clé privée que celle utilisée pour produire l'adresse de notre sortie. Et une clé publique, qui est la même clé publique dérivée de notre clé privée. La transaction aura deux sorties. Le zéro de sortie contiendra un champ de clé de script composé, entre autres, de la clé publique hachée de l'adresse. Nous voulons envoyer nos bitcoins à. Ce hachage est obtenu en décodant l'adresse par Beck 32. Back 32 est l'algorithme utilisé pour coder le hachage d'une clé publique, produisant en une seconde quelle adresse ? base 58 est un autre algorithme utilisé pour faire de même pour les adresses non segmentées. Puisque nous envoyons des bitcoins à une adresse segmentée, nous devons utiliser Beck 32. Le champ de quantité de cette sortie sera égal à 1,5, ce qui correspond au montant en bitcoins que nous voulons envoyer Une deuxième sortie sera nécessaire pour le changement. Sa clé de pub de script contiendra une clé publique hachée obtenue par le décodage Beck 32 et une adresse qui nous appartient, dérivée d'une clé privée que nous contrôlons. Sa quantité sera de 0,49 Bitcoins, ce qui, ajouté à 1,5 du zéro de sortie, équivaut à 1,99. Nous avons donc une différence de 0,01 entre la somme des montants de Bitcoin en entrées et en sorties. Cette différence correspondra aux frais de transaction nécessaires pour la transaction soit incluse dans la blockchain par un mineur. Nous avons parlé de ScriptSig et de Script Pub Key, mais nous n'avons pas encore expliqué en quoi ils consistent réellement. Bitcoin possède un langage de contrat intelligent appelé script. Un contrat intelligent est une façon sophistiquée de faire référence à un programme écrit sur une transaction et exécuté par le réseau Bitcoin. Les champs de clé ScriptSig et Script Pub sont créés avec du code en langage de script. Ce langage est interprété en combinant le ScriptSig d'une entrée et la clé script pub d' une sortie et en vérifiant si le ScriptSig satisfait aux conditions codées par la clé de publication du script. Vous pouvez considérer ce mécanisme comme un mécanisme à clé et à verrouillage, lequel le ScriptSig est la clé permettant de déverrouiller la clé du script Pub, qui est le verrou. Si un ScriptSig est valide pour déverrouiller une clé de pub de script, vous pouvez dépenser les fonds de sortie qu'il bloque. Un ScriptSig porte ce nom car il contient généralement une signature qui répond une condition spécifique de clé de pub de script. De même, le script pub key porte ce nom car il contenait une clé publique lors des premières transactions Bitcoin. Mais en théorie, tout code de script arbitraire peut être inclus dans les deux champs. La seule contrainte pour qu'un programme de script soit valide est qu'il renvoie la valeur true à la fin de son exécution. Il existe de nombreux types de programmes de script, également appelés types de script. L'un d'entre eux est le hachage par clé publique utilisé dans de simples transactions non séquentielles. Voyons comment cela est exécuté. Dans cet exemple, tous les scripts Bitcoin sont exécutés de la même manière Qu'est-ce qui change entre eux ou le code en cours d'exécution ? Donc, en commençant par la transaction confirmée de la diapositive précédente , nous ne montrons ici que sa sortie zéro avec le contenu de sa clé de script Pub dans la case grise. Dans les transactions de hachage payantes à clé publique, le champ de clé de pub du script est composé d'opcodes et du hachage de clé publique. Et l'opcode est une instruction en langage de script. Ils sont identifiés par les lettres OP à leurs débuts. Souligner vers le haut est égal, par exemple compare deux éléments et renvoie vrai s'ils sont égaux. que par le hachage de chaque clé de pub et chaque script le hachage de chaque clé Cette séquence de code ne diffère que par le hachage de chaque clé de pub et chaque script de hachage de clé de pub. Nous avons maintenant notre nouvelle transaction, qui est identique à la diapositive précédente. Cette fois, nous ne montrons ici que ses entrées. contenu de ScriptSig se trouve dans la case grise. Dans les scripts de hachage à clé publique. Le ScriptSig possède uniquement une signature suivie d'une clé publique. Voyons maintenant comment les deux champs sont combinés et exécutés. abord, le contenu ScriptSig de l'entrée est concaténé avec le contenu de la clé de pub de script de la sortie référencée par l'entrée dans cet ordre. Chaque élément du script combiné est ensuite inséré dans une pile d'exécution de gauche à droite. Si l'élément est un opcode, il peut agir sur d'autres éléments de la pile, en les traitant et en ajoutant d'autres éléments à la pile. Voyons donc comment ce script est exécuté. La signature est le premier élément de gauche à droite. Par conséquent, il est d'abord introduit dans la pile. L'élément suivant est la clé publique, est également insérée dans la pile. L'élément suivant est l' opcode souligné vers le haut. En haut, souligné vers le haut code une instruction pour dupliquer le dernier élément ajouté à la pile et ajouter la copie à la pile. L'élément suivant est l'opcode op underscore hash 160. Il supprime le dernier élément ajouté à la pile, applique la fonction hash 160 lui applique la fonction hash 160 et ajoute le résultat haché à la pile. Nous nous retrouvons donc avec le hachage de la clé publique en haut de la pile d'exécution. L'élément suivant à ajouter à la pile est le hachage de la clé publique. Ensuite, nous avons l'opcode op underscore Equal Verify. Cet opcode supprime deux éléments du haut de la pile d' exécution et les compare s'ils sont égaux alors que le script continue à s'exécuter. cas contraire, son exécution échoue et la transaction est invalidée. Cette étape est importante car elle confirme que la clé publique du ScriptSig est égale à la clé publique utilisée pour générer l'adresse de la sortie à partir de laquelle il dépense. Le dernier élément du script est l'opcode op underscore check sig. Il supprime deux éléments du haut de la pile d'exécution et vérifie si le premier élément est une signature valide pour le second élément pour cette transaction spécifique, s'il s'agit d'une signature valide, un booléen vrai est ajouté à la pile. S'il n'est pas valide par rapport à un booléen, false est ajouté à la pile. Enfin, une fois que tous les éléments de script ont été ajoutés à la pile d' exécution, l'entrée de transaction serait considérée comme valide si le dernier élément ajouté est vrai. cas contraire, l' entrée de transaction n'est pas valide. Ce processus doit être répété pour chaque transaction saisie. Pour qu'une transaction soit considérée comme valide, toutes ses entrées doivent être valides. Il existe de nombreux types de scripts. Le script pay to public key a été le premier script Bitcoin créé, mais il est aujourd'hui obsolète et rarement utilisé. Les premières transactions Bitcoin contiennent le type de script. Au lieu d'utiliser le hachage de la clé publique, c'est la clé de publication du script, utilisez directement la clé publique. Le script de hachage pay to public key a été illustré dans la dernière diapositive. Il s'agit du type de script le plus utilisé depuis la montée en importance des transactions en Segway ces dernières années. Aujourd'hui, il est encore couramment utilisé, il est donc bon de le savoir. Le script de hachage à clé publique pay to witness est le type de script le plus utilisé actuellement dans les transactions Bitcoin. La raison en est qu'il est avantageux de l' utiliser car les transactions avec celui-ci sont plus petites et entraînent donc des frais de transaction moins élevés. Ce type de script possède une clé de publication de script plus petite et son contenu ScriptSig est déplacé vers le champ témoin, ce qui ne contribue pas à la taille de la transaction. Pour ces raisons, nous allons d'abord implémenter ce type de script dans nos portefeuilles Le hachage pay-to-script est un autre script principalement utilisé pour les transactions à signatures multiples. Les transactions à signatures multiples nécessitent plusieurs signatures pour générer un résultat. Le hachage du script pay to witness est la version témoin du script de hachage pay-to-script. Sa signature est déplacée dans le champ témoin. Il présente donc les mêmes avantages que le script de hachage à clé publique Pay to Witness. Le hachage de la clé publique Pay to Witness encapsulé dans un script de hachage pay-to-script est également connu sous le nom de segment imbriqué ou segment rap. Il est également couramment utilisé et sa fonction principale est de rendre les anciens portefeuilles qui ne sont pas compatibles avec les segments natifs, compatibles avec les transactions Segway. Nous en apprendrons davantage sur le type de script plus loin dans le cours. Enfin, un autre type de script est le script root pay to tap. Il s'agit du type de script le plus récent, ajoute plus de fonctionnalités et de confidentialité aux transactions Bitcoin. Voyons maintenant un résumé de la façon de créer entrées et des sorties de transaction du point de vue d'un portefeuille, commençant par une graine mnémotechnique et une phrase secrète. Grâce à un algorithme cryptographique, nous combinons les deux et obtenons une racine. Ensuite, grâce à une série de transformations clés principales et des clés étendues sont produites. Nous obtenons de nombreuses clés privées. Ici, nous ne montrons qu'une seule de ces clés privées. Les mêmes transformations peuvent également produire des clés publiques. Une clé publique peut également être produite à partir d'une clé privée spécifique, nous le montrons ici dans notre exemple. À partir d'une clé publique, nous obtenons une adresse en utilisant la fonction hash 160 et en codant le résultat par codage Beck 32 dans le cas d'adresses de segment ou codage en base 58 dans le cas d'adresses de segment. d'adresses non segmentées. Pour recevoir des Bitcoins, vous montrez votre adresse à quelqu'un afin que quelqu'un puisse lui envoyer des bitcoins. Lorsqu'un expéditeur met votre adresse dans son portefeuille et lui envoie un montant en bitcoins, son portefeuille décode l' adresse sous forme de clé publique. Ensuite, il créera une transaction avec une sortie contenant une clé de script de pub équivalente à cette adresse. Le type de clé de pub du script dépend du type d'adresse. Dans ce cas, le portefeuille a identifié que le type d'adresse est compatible avec un script de hachage de type « pay to public key ». Après avoir reçu des Bitcoins à cette adresse, le destinataire peut les dépenser par le biais d'une nouvelle transaction. Le contenu des champs de saisie de la nouvelle transaction dépendra du type de clé de pub de script qui sera utilisée. Dans ce cas, le portefeuille créera une transaction avec une entrée contenant un ScriptSig avec une signature générée à l'aide de la même clé privée à l' origine de la clé publique d'origine l'adresse à laquelle vous avez reçu des Bitcoins précédemment. Les détails de la signature d' une transaction seront présentés dans une prochaine vidéo. La clé publique citée précédemment sera ajoutée après la signature dans le champ ScriptSig. Enfin, l'entrée fera également référence à la sortie de transaction non dépensée en utilisant l'identifiant de transaction précédent et les champs d'index de sortie de transaction précédents comme expliqué précédemment. Découvrons maintenant le concept important du kit UTXO. N'oubliez pas que UTXO signifie une sortie de transaction non dépensée. Le Bitcoin a la caractéristique importante de ne pas permettre la double dépense. En d'autres termes, vous ne pouvez dépenser des Bitcoins qu'à partir de transactions non dépensées. L'ensemble UTXO est l'ensemble de tous les UTXO existants. Cet ensemble est stocké par les nœuds dans une base de données séparée, ce qui permet une récupération rapide par des portefeuilles. L'ensemble UTXO est constamment mis à jour chaque nouvelle transaction ajoutant et supprimant des sorties dans et depuis l'ensemble. Utxo sont des sorties qui n' ont encore jamais été référencées dans aucune entrée. Par conséquent, le set UTXO contient toutes les pièces pouvant être dépensées. Le nombre de bitcoins dans une adresse est égal à la somme de tous les Bitcoins provenant de tous les UTXO dont les clés de script font référence à l'adresse décodée. Le nœud Bitcoin Core fournit donc une méthode d'API appelée list unspent qui renvoie tous les UTXO faisant référence aux adresses que vous lui avez transmises en tant que paramètres. En utilisant la méthode de liste non dépensée, vous pouvez facilement calculer le solde d'une adresse et les informations de transaction découvertes , telles que l' identifiant et l'index de la transaction UTXO, ainsi que son clé de script Pub. Vous pouvez donc créer des entrées de transaction pour dépenser vos Bitcoins depuis l'UTXO. Une fois que vous avez dépensé l'UTXO, il est retiré du set UTXO. Voyons maintenant un schéma expliquant comment notre application détectera les transactions entrantes et nous indiquera les bitcoins que nous recevrons. Ce sera la dernière diapositive de cette présentation, qui contient de nombreuses informations complexes. Ne vous inquiétez pas si vous n'avez pas tout absorbé au début. Tout au long du cours, nous réutiliserons les informations apprises en profondeur, afin d'avoir de nombreuses occasions de mieux les saisir. Revenons maintenant au schéma. Ici, nous avons des rectangles représentant l'application : le nœud Bitcoin et le réseau Bitcoin. Les transactions sont créées et diffusées par des nœuds du réseau Bitcoin. Ces transactions, une fois confirmées, sont déjà stockées dans la blockchain. Lorsqu'elles ne sont pas confirmées, elles restent dans le temple, une base de données contenant toutes les transactions non confirmées. Chaque nœud possède une copie des transactions mentales qui sont finalement détectées par nos nœuds qui avaient déjà importé les portefeuilles et adresses de nos applications. Grâce à des notifications Zéro MQ, les transactions sont envoyées à notre application. Lorsqu'un portefeuille est chargé dans notre application, elle filtre toutes les transactions de réception ne contenant aucune de ses adresses. Ensuite, il enverra une liste d'appels non dépensés au nœud, en transmettant comme paramètres toutes les adresses des transactions de réception restées après le filtrage. Le nœud renverra tous les UTXO associés à ces adresses. Notre portefeuille analysera ensuite ces UTXO pour calculer le solde de Bitcoin pour chacune de ses adresses. Ensuite, nous afficherons les informations obtenues dans le tableau des adresses. 31. 29 Recevoir des bitcoin partie 5 skillshare 2: Dans cette vidéo, nous allons implémenter la liste des clients non dépensés qui nous permettra collecter des informations sur UTXos après réception des transactions. Donc, dans le package client node point, créons la liste des nœuds client non dépensé. Ajoutons-y une annotation de service. Injectons également le client du nœud dans celui-ci. Créons maintenant la méthode «  liste non dépensée ». Cela renverra une liste d'UTXO, qui est un enregistrement que nous allons créer. Il prendra comme paramètres une liste d'adresses et un nom de portefeuille. Créons l'enregistrement UTXO dans le package BYOD w point domains. L'UTXO contiendra les champs suivants. Le TX ID, qui est un acronyme pour ID de transaction. Le champ vout, qui représente l'index de sortie, l'adresse, l'étiquette, que nous n'utiliserons pas pour le moment. La clé Script Pub. Le montant qui représente le montant du Bitcoin, les conformations qui contiendront le nombre de conformations de la transaction utXos. Le nombre de conformations d' une transaction est le nombre de blocs ajoutés à la chaîne de blocs une fois que la transaction a été insérée dans un bloc et ce bloc a été ajouté à la chaîne de blocs. Ce numéro inclut le bloc contenant cette transaction. Ainsi, si une transaction comporte deux confirmations, cela signifie qu'elle était déjà incluse dans un bloc. Ce bloc a été ajouté à la blockchain et un autre bloc a été ajouté par la suite. Ajoutons deux autres champs. Ces champs ne seront pas utilisés pour le moment, mais ils peuvent être utiles pour d'autres types de transactions que nous verrons plus loin dans le cours. Il s'agit du script Redemption et du script Witness. Revenons maintenant à la liste des nœuds, le client non dépensé appellera la méthode make request du client nœud et stockera le résultat dans la variable de tableau utxOS et transmettra les paramètres suivants à la méthode. Les trois derniers paramètres feront partie de la liste des poèmes de l'API Bitcoin node. Le premier est le nombre minimum de conformations que doit avoir l'UTXO de retour. Le second est le maximum. Puisque nous voulons que tous les UTXO définissent zéro comme minimum et la valeur entière maximale comme valeur maximale. Le troisième paramètre est la liste des adresses. Maintenant, nous allons convertir le tableau obtenu en une liste à l'aide de ce code et le renvoyer. Revenons maintenant à l'écouteur reçu par la transaction. Supprimons cette ligne de code car c'était juste pour les tests. Nous testerons le client non dépensé de la liste des nœuds. Allons chercher les UTXO pour ces adresses. Injectons d'abord le client dans cette classe, la méthode list unspent transmettra la variable addresses. Le deuxième argument sera le nom du portefeuille obtenu lors du test Bitcoin reçu. Copions-le et utilisons-le comme deuxième paramètre. Maintenant, ajoutons cette ligne pour imprimer chaque UTXO obtenu à l'écran. Maintenant, exécutons notre nœud Bitcoin s'il ne fonctionne pas déjà. Passons maintenant au test de réception de Bitcoin et exécutons-le. Dans les journaux de test, nous voyons qu'il a imprimé un UTXO avec toutes ses données. Notez que son adresse est la même que l' adresse de réception de notre portefeuille. Revenez en arrière sur la vidéo pour la vérifier. Le montant est un, ce qui est attendu car il s'agit du même montant de Bitcoin envoyé et que le test n'a aucune conformation car aucun bloc ne rappelle après le nœud depuis la transaction. Supprimons maintenant ces lignes car elles étaient uniquement destinées aux tests. Supprimons également le client injecté de cette classe. Nous allons maintenant ajouter un filtre à ce flux. Nous souhaitons traiter uniquement les transactions provenant du portefeuille actuellement chargé par l'application. Ce filtre en sera responsable. Le filtre vérifiera si l'adresse n'est pas vide. Si le portefeuille actuel contient cette adresse. Injectons donc le portefeuille actuel dans cette classe. Ensuite, nous appellerons la méthode get addresses sous forme de chaînes. Ensuite, nous vérifierons s'il contient l'adresse. Oh, il manquait une lettre S ici. Créons maintenant la méthode get addresses sous forme de chaînes. Il renverra une liste de chaînes. La valeur renvoyée résultera de l'appel de la méthode get addresses sous forme de chaînes dans le champ d' adresses que nous allons créer. Créons donc ce champ. Il aura une nouvelle classe d'adresses comme type. Et nous allons l'initialiser ici. Créons-le dans le package observables. Créons également ses adresses get sous forme de chaînes de caractères. Tout d'abord, nous allons ajouter un champ d'adresses privées. Ce sera une carte où le type de clé sera un type d'adresse et le type des valeurs sera une autre carte. La deuxième carte sera une HashMap liée avec des chaînes comme clés et une adresse comme type de valeurs. Nous utiliserons cette structure de données pour stocker les adresses. La raison d'utiliser cette structure de données est qu'elle nous permet séparer et d'interroger les adresses des portefeuilles par type d'adresse. La deuxième carte est une HashMap liée car ce type de carte conserve l'ordre d'insertion. Enfin, la deuxième carte nous permet d'interroger la liste des objets d'adresse par leurs séquences de chaînes d'adresses. Maintenant, dans la méthode get addresses as strings, le code suivant sera renvoyé. La fonction FlatMap sera utilisée pour obtenir toutes les adresses du deuxième jeu de clés cartographiques et renvoyer un flux contenant toutes ces adresses. Ensuite, nous allons convertir la chaîne résultante en une liste. Ok, nous pouvons maintenant utiliser la méthode get addresses as strings pour obtenir toutes les adresses créées pour le portefeuille actuel. Mais il manque une chose. Nous devons également renseigner le champ d'adresses à partir de la classe d'adresses. Pour cela, nous ajouterons le code suivant dans la mise à jour. service de portefeuille actuel définira les adresses actuelles du portefeuille en transmettant les clés de pub étendues du portefeuille comme paramètre. Créons maintenant la méthode actuelle d' ensembles d'adresses de portefeuille. Il appellera la méthode set addresses du champ d'adresses, en transmettant les clés étendues comme paramètre. Nous allons ensuite créer cette méthode dans la classe d'adresses. Ajoutons-y le code suivant. Nous utiliserons la fonction de collecte pour obtenir une carte à partir des clés de pub étendues. À l'intérieur, il ajoutera un appel à la méthode to map. Son premier argument créera un type d'adresse en utilisant le champ de type de clé de pub étendu. Cet argument définit la clé de la carte résultante. Le deuxième argument définira la valeur de la carte et contiendra le code suivant. Encore une fois, en combinant les fonctions de collecte et de mappage , vous le définirez comme un Hashmap lié. Les clés seront les séquences de chaînes d'adresses de clés de pub étendues , et les valeurs se trouveront objets d'adresse correspondants. Enfin, la partie filtrante de ce flux est terminée. Dans la vidéo suivante, nous utiliserons ce que nous avons construit pour continuer à créer la fonctionnalité C de réception de Bitcoins, oui. 32. 30 Recevoir des bitcoin partie 6 skillshare 2: Dans cette vidéo, nous allons traiter les UTXO des transactions arrivant sur notre portefeuille. Donc, dans la méthode d' événement non liée à l'application, dans l'écouteur reçu par la transaction, ajoutons l'instruction if suivante. Si la liste d'adresses n'est pas vide, nous appellerons la méthode de mise à jour dans le service de mise à jour utxOS que nous allons créer. Cette méthode prendra les adresses, le nom du portefeuille actuel comme paramètres. Injectons ce service dans cette classe. Créons maintenant ce service dans le package GUI point services. Ajoutons-y l' annotation du service. Revenons à l'auditeur reçu par la transaction. Finissons d'injecter le service. Créons maintenant la méthode de mise à jour dans le service Update UtxOS. Nous allons ajouter une annotation asynchrone à cette méthode et l'exécuter dans le thread de service d' exécution par défaut. La raison de l' exécution de cette méthode et d'un autre thread est qu'elle appellera la méthode d'API de nœud non dépensé de la liste, ce qui peut être lent. Nous allons donc l'exécuter de manière asynchrone pour éviter de bloquer l'interface utilisateur. Dans la méthode de mise à jour, la méthode de liste non dépensée appellera la méthode non dépensée à partir de la liste de nœuds, le client non dépensé. Injectons le client dans cette classe. Nous transmettrons les adresses et le nom du portefeuille en tant que paramètres à la liste. La méthode non dépensée stockera le résultat de l' appel de méthode dans la variable utxOS. Nous allons maintenant injecter une nouvelle mise à jour, service actuel d'adresses de portefeuille, dans cette classe. Créons-le dans le package de services GUI dots. Finissons d'injecter le service. Ensuite, nous appellerons la méthode de mise à jour lui transmettant utxOS comme paramètre. Créons cette méthode. Ajoutons-y l' annotation des services. Nous allons maintenant ajouter le code suivant pour créer une carte où les clés sont des adresses et les valeurs sont des listes d' UTXO contenant ces adresses. Pour cela, nous appellerons la méthode de collecte sur le flux UTXO lui transmettrons l'appel MyMethod du regroupement des collecteurs. Transmettre la méthode d'adresse UTXO comme paramètre. Nous allons stocker la valeur renvoyée dans la variable de groupe utxOS. Ensuite, pour chaque groupe paire clé-valeur UTXO définira le solde d' adresses correspondant. Ce sont des confirmations et le marché est utilisé. Implémentons la méthode de l'équilibre défini. Renvoie la somme de tous les montants UTXOS en utilisant ce code. En utilisant la méthode map to double sur le flux de liste UTXO, vous obtiendrez un flux contenant tous les montants UTXO de la liste UTXO. Pour obtenir leur somme il suffit d'appeler la méthode somme sur le résultat. Maintenant, injectons le portefeuille actuel dans cette classe. Ensuite, nous appellerons la méthode équilibrée d'adresse définie par le portefeuille actuel , qui créera la transmission de l'adresse et de la somme comme paramètres. Créons-le. À l'intérieur, il appellera la méthode équilibrée d' adresses définies, en lui transmettant les mêmes paramètres. Ensuite, nous allons créer cette méthode. À l'intérieur, il appellera la méthode get addresses comme méthode cartographique, ce qui créera. Créons-le. Il renverra une carte où les clés sont des adresses, des chaînes et les valeurs sont adressées sous forme d'objets. En utilisant le code suivant, vous obtiendrez une carte contenant toutes les adresses. En appelant la méthode string sur les adresses, les valeurs obtiendront un flux contenant toutes les cartes du champ privé des adresses. Ensuite, avec cette méthode FlatMap, l'appel convertira le flux de cartes en un flux d'entrées cartographiques. Enfin, en utilisant la méthode de collecte sur le flux résultant et la méthode à deux cartes avec ces paramètres obtiendrez la carte souhaitée. Sur la base du résultat de la commande get addresses as map call appellera la méthode get pour obtenir un objet d'adresse par sa chaîne d'adresse. Ensuite, nous définirons le solde de l'adresse sur la variable somme. Maintenant, créons la méthode set balance dans l'enregistrement d'adresse. Oups, nous ne pouvons pas ajouter de setters dans un enregistrement, nous devrons donc convertir l'enregistrement d' adresse en classe. Faisons-le avec un peu d' aide grâce à notre IDE. Supprimons ces méthodes car nous n'en aurons pas besoin. Créons le centre d' équilibre maintenant. Et supprimez le dernier mot clé ici. Dans le générateur séquentiel d'adresses. Ajoutons zéro comme troisième paramètre dans l'instanciation de l' adresse ici. Changeons également le nom des getters, en les faisant commencer par get. Maintenant, dans le service de mise à jour des adresses de portefeuille actuelles, créons la méthode set confirmations. Confirmation. Dans ce cas, nous ferons référence au solde d' adresses et il sera défini comme étant égal au nombre de conformations de l'UTXO avec moins de conformations pour cette adresse. Supposons, par exemple, qu' une adresse ait un solde de deux Bitcoins, chaque Bitcoin provenant d'une transaction différente. L'une de ces transactions a deux confirmations, l'autre n'en a qu'une. Dans ce cas, nous considérerons que la balance des adresses a une conformation. Pour ce faire, nous allons utiliser le code suivant. Nous obtiendrons un flux contenant toutes les confirmations de la liste UTXos transmise. Pour obtenir ce flux, nous appellerons la méthode map too long le flux de liste UTXO, transmettant la référence de la méthode de confirmation UTXO comme paramètre. Ensuite, en utilisant la méthode Min et la méthode good is long, vous renverrez le nombre minimum de confirmations dans le flux et le stockera dans la variable confirmations. Ensuite, nous transmettrons les confirmations et les variables d'adresse à l'appel de la méthode de confirmation d'adresse définie par le portefeuille actuel. Créons maintenant cette méthode dans la classe de portefeuille actuelle. Il appellera la méthode de confirmation d'adresse définie par adresses , en transmettant les mêmes paramètres que ceux reçus. Créons cette méthode dans la classe d'adresses. Nous utiliserons la méthode get addresses comme méthode cartographique pour obtenir l'adresse et définir ses conformations. Créons maintenant la méthode set confirmations dans la classe d'adresses. Nous l'utiliserons pour définir le champ de confirmation que nous allons créer. Créons ce champ et ajoutons-le au constructeur. Ajoutons ensuite ce paramètre à la classe du générateur séquentiel d'adresses dans l'instanciation d'adresses. Enfin, créons la méthode mark is used dans le service de mise à jour des adresses de portefeuille actuelles. L'un des objectifs de notre portefeuille et de bien d'autres est d' éviter de réutiliser des adresses lors de la réception de Bitcoins. Pour des raisons de confidentialité. Pour ce faire, nous devons d'abord commercialiser les robes qui ont fait l'objet de transactions telles qu'elles ont été utilisées. La méthode « marquer comme utilisé » sera utilisée à cette fin. Il appellera le portefeuille actuel de vêtements de marché. La méthode utilisée créera la transmission de l'adresse en paramètre. Créons-le. À l'intérieur, il appellera la méthode mark is used de la classe d'adresses en lui transmettant l'adresse. Ensuite, nous allons créer cette méthode. À l'intérieur, il utilisera les adresses get comme méthode mathématique pour obtenir l' adresse et le marché sera utilisé. Enfin, créons la méthode mark is used dans la classe d'adresse. Ici, je vais simplement définir que le combustible usé est vrai. Créons ce champ dans cette classe. 33. 31 Recevoir des bitcoin partie 7 skillshare 2: Dans cette vidéo, nous allons enfin connecter tout ce que nous avons fait dans les dernières leçons pour afficher nos informations d'adresses à l'écran. Ainsi, dans le package observables la classe de lignes d' adresses sera créée. Comme son nom l'indique, cette classe modélisera une ligne dans la table d'adresses. Créons les champs suivants dans cette classe, chacun pour une colonne de la table d'adresses. Le premier champ sera une propriété de chaîne nommée balance, elle sera instanciée ici avec une nouvelle propriété de chaîne simple. Le champ suivant sera une propriété longue nommée confirmations, et elle sera instanciée avec une nouvelle propriété longue simple. Le dernier champ sera une propriété de chaîne nommée adresse. Il sera instancié avec une nouvelle propriété de chaîne simple. Maintenant, avec l'aide de l'IDE, créons des getters pour chaque propriété. Notez que lors de la création de getters pour les champs de propriété Java FX, l'IDE crée deux getters, l' un pour la propriété et l' autre pour le contenu de la propriété. Créons maintenant le constructeur suivant pour cette classe. OK, maintenant que nous avons modélisé la ligne d'adresses, allons créer un code pour la renseigner lors de la mise à jour de nos adresses. Pour ce faire, passons au service de mise à jour des adresses de portefeuille actuelles. Dans la méthode de mise à jour, après avoir marqué l' adresse comme étant utilisée, appelons la méthode set address row sur le portefeuille actuel, en transmettant l'adresse en paramètre. Créons ensuite la méthode set address row. Pour implémenter cette méthode, vous ajouterez le champ des lignes d'adresses à cette classe. Créons la classe de lignes d' adresses dans le package observables. Instancions-le ici. Nous allons maintenant appeler la méthode set address row sur la propriété address rows lui transmettra un objet d'adresse. Cet objet sera obtenu à partir du champ adresses en utilisant la méthode get addressed que nous allons créer en lui transmettant la chaîne d' adresse. Pour créer cette méthode , il suffit de sélectionner cet extrait de code et d'en extraire une méthode à l'aide de l'ID. Remplaçons toutes les occurrences de code par cette méthode, et nous rendrons publique la méthode générée. Revenons maintenant à la classe de portefeuille actuelle. Créons la méthode set address row dans la classe address rows. Pour ce faire, nous allons créer une variable de ligne d'adresse appelant la méthode sur la classe de ligne d'adresse, en transmettant l' objet d'adresse comme paramètre. Créons la méthode de formulaire dans la classe de ligne d'adresse. Il renverra une nouvelle ligne d'adresse, en l'instanciant avec ces paramètres. Créons la bonne méthode de confirmations dans la classe d'adresses. Et maintenant, nous pouvons l'utiliser ici. Notez qu'ici, nous créons simplement un objet de ligne d'adresse en convertissant les valeurs des champs d' adresse en valeurs des champs de ligne d'adresses. Revenons à la classe des lignes d'adresses. Nous allons créer le champ d' ensemble de routes d'adresses dans cette classe. Il s'agira d'un ensemble observable avec la ligne d'adresse comme paramètre de type. Je vais l'instancier ici avec un nouveau wrapper d' ensembles observable, transmettant un nouveau jeu de hachages lié à son constructeur. Cet objet publiera un événement pour chaque nouvelle adresse insérée ou supprimée et sera nécessaire pour mettre à jour le tableau des adresses au fur et à mesure que le portefeuille actuel reçoit de nouvelles transactions. Nous allons maintenant appeler la méthode remove de la ligne d'adresse set, en passant la ligne d'adresse comme paramètre. Ensuite, nous appellerons la méthode add, en transmettant la même ligne d'adresse comme paramètre. Vous vous demandez peut-être pourquoi nous supprimons et ajoutons la même ligne d'adresse dans l'ensemble. Eh bien, c'est un peu un hack. Si nous ne supprimons pas d'abord la ligne d' adresse et insérons une ligne d'adresse qui figure déjà dans l'ensemble. L'ensemble observable ne publiera pas d'événement indiquant qu'une ligne d'adresse y a été ajoutée. Il y a autre chose que nous devons faire pour que cela fonctionne. Lorsque nous supprimons une ligne d'adresses de l'ensemble à l'aide de la méthode remove, cette méthode utilise la méthode equals de la ligne d'adresse pour définir ligne d'adresses à supprimer de l'ensemble. Nous considérerons que les deux rangées « I dress sont égales si elles ont la même adresse. Par conséquent, nous devons implémenter la méthode equals dans la classe de lignes d'adresses. Allons-y. Nous ajouterons les méthodes d'égalité et de code de hachage à l'aide de cette fonctionnalité IDE. Assurez-vous que cette case est cochée pour générer des méthodes à l'aide de getters. Nous allons maintenant choisir de n'utiliser le champ d'adresse que pour générer la méthode equals. Et le même champ pour générer la méthode HashCode et sélectionner le champ d'adresse ici pour le définir comme non nul. D'accord, l'IDE a généré les méthodes d'égalité et de code de hachage. Passons maintenant au tableau des adresses. Fxml ajoutera des ID FX à chaque balise de colonne du tableau. Les adresses. Le contrôleur de table aura besoin ces ID FX pour lier et manipuler ces colonnes ultérieurement. D'abord l'adresse de la colonne, puis le solde de la colonne et enfin les conformations des colonnes. Passons maintenant au contrôleur de table des adresses ajoutera les champs suivants, chacun correspondant à une balise avec un identifiant éthique dans la table des adresses, FXML. Les noms de ces champs doivent être égaux aux ID FX des balises. Ils sont tenus de le faire. D'abord la table des adresses, puis l'adresse de la colonne, le solde et les confirmations des colonnes. Nous allons maintenant ajouter la méthode initialisée à cette classe. N'oubliez pas que les méthodes initialisées dans les contrôleurs Java FX sont appelées lorsque le framework initialise ces contrôleurs. Dans cette méthode, nous allons ajouter du code qui liera la table des adresses et ses colonnes à nos observables de rôles d' adresses. Pour cela, nous allons appeler la méthode set items dans la table des adresses car son argument transmettra une nouvelle liste filtrée. Cela est nécessaire car nous voulons afficher uniquement les adresses dont le solde est supérieur à zéro dans la table des adresses. En tant que premier paramètre de liste filtrée transmettra les lignes d'adresses observables du portefeuille actuel. Injectons donc le portefeuille actuel dans cette classe. Ensuite, nous y appellerons la méthode get observable address rows. Créons cette méthode. Il renverra une liste observable avec la ligne d'adresse comme paramètre de type. Ensuite, nous renverrons l'appel à la méthode good observable address rows dans le champ des lignes d' adresses. Créons cette méthode dans la classe des lignes d'adresse. À l'intérieur, il renverra le champ de liste de lignes d'adresses que nous allons créer. Créons-le. Ce champ sera instancié ici avec un nouveau wrapper de liste observable passant une liste liée comme paramètre. Nous devons maintenant faire en sorte que la liste observable réponde aux insertions et suppressions de lignes d' adresses dans l'ensemble de lignes d' adresses. Nous allons le faire dans le constructeur de la classe. Tout d'abord, nous allons créer une variable d'écoute Set Change. Nous allons la définir comme cette fonction lambda. Le paramètre de modification représente ici l'insertion ou la suppression d' une ligne d'adresse dans l'ensemble. S'il s'agit d'une suppression, nous supprimerons l'élément supprimé de la liste des lignes d'adresses. Si le changement était une insertion. Nous ajouterons ensuite l'élément ajouté à la liste des rôles d'adresses. Enfin, nous ajouterons cet écouteur à la ligne d'adresse définie à l'aide de cette méthode. Revenons maintenant au contrôleur de table d'adresses. Le deuxième paramètre de la liste filtrée est utilisé comme condition de filtre pour afficher les lignes. Il s'agira d'une fonction lambda avec un paramètre address rho. Le corps de la fonction sera ce code qui vérifiera si le solde des lignes d'adresses est supérieur à zéro. Ainsi, nous atteignons notre objectif de n' afficher que les adresses dont le solde est supérieur à zéro. Maintenant, pour chaque champ de colonne, nous devons définir une usine de valeurs de cellule qui sera utilisée pour remplir chaque cellule de la table des adresses. Pour cela, nous allons utiliser le code suivant. L'usine de valeurs de propriété sera utilisée pour obtenir un bien immobilier à chaque adresse et lier sa valeur à la cellule correspondante. Il sait à quelle adresse le bien immobilier nous voulons lier à la colonne en faisant correspondre le nom que nous transmettons en paramètre au nom de la propriété. Il y a encore une chose que nous devons faire pour que notre fonction de réception de Bitcoin fonctionne correctement. Passons à la classe de portefeuille actuelle dans la méthode set addresses, qui est appelée lorsqu'un nouveau portefeuille est créé Nous devons inclure ce code pour nous assurer que l' adresse provient d'une le portefeuille créé est effacé. Nous appellerons la méthode clear des lignes d'adresses , ce qui créera. Pour ce faire, créons-le. Ici. Nous appellerons simplement la méthode clear sur le jeu de lignes d'adresses et la liste des lignes d'adresses. Nous allons maintenant tester notre fonctionnalité. Assurez-vous que votre nœud principal Bitcoin fonctionne. Passons au test de réception de Bitcoin et exécutons-le. Super, ça a marché. Notez que la première ligne du tableau des adresses a été correctement remplie avec un solde d' un Bitcoin, comme prévu. Bon travail. Dans les prochaines vidéos, nous ajouterons d'autres cas de test pour nous assurer que notre fonction de réception de bitcoins fonctionne correctement dans différents scénarios. 34. 32 Recevoir des bitcoin partie 8 skillshare 2: Dans cette vidéo, nous ajouterons d'autres cas de test pour nous assurer que notre fonction de réception de bitcoins fonctionne correctement dans différents scénarios. le premier scénario supplémentaire, nous testerons si la même adresse peut recevoir des Bitcoins lors de deux transactions, un Bitcoin par transaction. Nous vérifierons que le solde de l' adresse est mis à jour à deux bitcoins. Copions donc le contenu de cette méthode et collez-le ci-dessous. Modifions le nom du test pour qu'il reçoive des Bitcoins en deux transactions à la même adresse. Maintenant, sélectionnons ce code et extrayons une méthode à l' aide de l'identifiant. Nommez-le, envoyons du Bitcoin et du poids. Nous appellerons cette méthode deux fois car nous voulons envoyer des transactions à cette adresse. Modifions la méthode d'envoi de Bitcoin en poids en incluant le code suivant. Nous vérifierons si l'adresse la première ligne du tableau présente un solde égal au paramètre de montant total attendu. Ajoutons ce paramètre à la signature de la méthode. Il aura une valeur par défaut de 1,0. Dans cet appel de méthode, ajoutons 2.0 comme deuxième paramètre, car nous nous attendons à ce que le solde d'adresses soit égal à deux. Ajoutons deux au nom du portefeuille. Notre environnement de test présente un problème. Dans le Reg Test, il n'est possible de miner 15 000 blocs avec des récompenses par blocs. Par conséquent, dans cette méthode, il est trop important de miner 1 000 blocs lorsque vous appelez la méthode generate to address. Appelons-le uniquement si le solde du portefeuille de test est inférieur 50 et ne générera que 150 blocs pour chaque appel. Ainsi, nous évitons d'avoir à réinitialiser trop souvent notre environnement de test Reg. Remplaçons également ce code par la méthode send Bitcoin and wait. Maintenant, rendons nos tests un peu plus résilients aux conditions de course. J'ai remarqué que ces tests envoient parfois bitcoins dans les portefeuilles de nos applications avant qu'ils ne soient complètement chargés. Par conséquent, ces transactions n'ont pas été capturées par l'application et les tests échouent pour cette raison. Donc, après avoir créé un portefeuille et avant de leur envoyer des Bitcoins, appelons la méthode du sommeil avec ces paramètres. L'appel à la méthode de sommeil obligera l'application à attendre 10 secondes avant d'envoyer des Bitcoins, suffisamment de temps pour le nouveau portefeuille soit complètement chargé. En fonction de votre ordinateur, il se peut que vous deviez augmenter la constante de temporisation. Maintenant, avant d'exécuter les tests, je vais réinitialiser mon environnement de test reg. Je dois le faire parce qu' elle a déjà généré 15 000 blocs et que la génération de blocs ne produit plus de Bitcoins. Je vais donc aller dans le dossier où la blockchain est stockée et supprimer le dossier reg test qu'il contient. Dans votre cas, vous pouvez trouver le dossier dans lequel il se trouve en vérifiant la valeur DIR des données dans votre fichier bitcoin.com. Maintenant, exécutons notre nœud Bitcoin et exécutons nos tests de réception de Bitcoin. Super, les tests sont réussis. Lorsque nous recevons des Bitcoins dans notre portefeuille, nous voulons que la prochaine adresse de réception soit modifiée. Ainsi, nous évitons de réutiliser des adresses. Il est important de n' utiliser qu'une seule adresse pour recevoir les transactions afin qu' un tiers puisse facilement suivre nombre de Bitcoins que vous possédez et les adresses avec lesquelles vous effectuez des transactions. Pour couvrir ce scénario, créons le test suivant. Copiez le dernier test et collez-le ci-dessous. Renommez-le pour qu'il reçoive des Bitcoins en deux transactions, deux adresses différentes. Remplaçons le nom du portefeuille créé par mon troisième portefeuille de test. Maintenant, avant le deuxième appel à la méthode d'envoi de Bitcoin et d'attente, ajoutons ce code pour interroger à nouveau le champ d'adresse de réception et stocker son contenu dans la variable d'adresse suivante. Maintenant, remplacez le premier paramètre de cette méthode par la variable d'adresse suivante. Et nous nous attendons à ce que le montant total de Bitcoin pour cette adresse soit égal à 1,0. Nous nous attendons également à ce que la taille des éléments du tableau soit égale à 21 lignes pour chaque adresse. Modifions donc cette méthode pour accepter la taille de table attendue comme paramètre. Ajoutons-y ce paramètre avec une valeur par défaut de un. Remplacera cette valeur ici pour attendre que le nombre de lignes de la table soit égal à celle-ci. Et nous allons remplacer l'indice des éléments du tableau la taille totale attendue moins un pour attendre que la dernière ligne du solde du tableau soit égale au montant total attendu pour cette ligne. Enfin, paramétrons le troisième argument de cet appel de méthode à deux. Faisons nos tests. Comme prévu. Le troisième test a échoué car nous n'avons pas encore implémenté la fonctionnalité de modification de l'adresse de réception après son utilisation. Faisons-le maintenant. Passons donc au service de mise à jour des adresses de portefeuille actuelles. À l'intérieur, pour chaque bloc, appelons la méthode d' adresse de réception des mises à jour que nous allons créer. Il prendra l'adresse comme paramètre. Créons-le. La première chose à faire est d'appeler la méthode get addresstype sur le portefeuille actuel. Le fait de transmettre l'adresse en tant que paramètre stockera le résultat de l'appel de méthode dans la variable de type d'adresse. Il est important de connaître le type d'adresse de l'adresse substituée, car elle doit être remplacée par une adresse du même type. Créons donc cette méthode sur la classe de portefeuille actuelle. Il appellera simplement la méthode de type addresses get addressed. Nous allons créer le passage de l' adresse comme paramètre. Créons-le. Maintenant. Nous appellerons la méthode get addressed et renverrons son type d'adresse. Créons la méthode get address type dans la classe d'adresses. À l'intérieur, il renverra le champ de type d'adresse que nous allons créer. Créons ce champ et ajoutons-le au constructeur. Corrigons également le générateur séquentiel d'adresses pour ajouter le dernier argument à l'instanciation de l'adresse. Nous allons ajouter ce type d'adresse en tant que paramètre à cette méthode. Et nous allons inclure le type d'adresse dans cet appel de méthode appelant la valeur de la méthode dans la classe de type d'adresse. Revenons maintenant au service Update Current wallet addresses, qui calcule la valeur du prochain index d' adresses en appelant la méthode fine next address index du portefeuille actuel, transmettant l'adresse tapez comme paramètre stocker le résultat de l'appel de méthode dans la variable d'index d' adresse suivante. Créons cette méthode. Ici. Nous appellerons l' index d'adresse suivant dans le champ adresses, en transmettant le type d'adresse comme paramètre. Créons cette méthode dans la classe d'adresses avec le code suivant, nous obtiendrons la dernière adresse utilisée pour stocker dans la variable d' adresse. Obtiendra tous ces objets habillés avec le type d'adresse donné et en tirera un stream. Ensuite, nous allons trier le flux obtenu en utilisant la méthode de tri avec les paramètres suivants. Utilisera la méthode de comparaison par points de comparaison, transmettant la méthode address get indexed comme premier paramètre et le comparateur d'ordre inverse comme second. De cette façon, nous obtiendrons un flux d' adresses inversé selon leurs index. Nous allons maintenant filtrer le flux pour obtenir une chaîne contenant uniquement les adresses utilisées. Pour ce faire, créons un getter pour le champ utilisé dans la classe d'adresse. Ils ont utilisé getter is called est utilisé parce que c'est ainsi que l'IDE nomme les getters booléens à la classe addresses et transmettra la méthode addresses utilisée tant qu'invite à l'appel de méthode de filtrage. Nous allons maintenant appeler la meilleure méthode en fonction du résultat. Pour obtenir la première adresse utilisée et le flux ordonné inversé, qui est égal à la dernière adresse utilisée. Et si aucune adresse utilisée n'est trouvée ? Dans ce cas, nous utiliserons la méthode or else pour renvoyer null. Nous ajouterons la déclaration if suivante. Si l'adresse obtenue est nulle, nous renverrons zéro comme indice suivant. cas contraire, nous vous renverrons le dernier index d'adresses plus un. Revenons maintenant au service Mettre à jour les adresses de portefeuille actuelles pour obtenir l'adresse suivante en appelant la méthode get address ID sur le portefeuille actuel. Nous transmettrons l'index d'adresse suivant et le type d'adresse en tant que paramètres. Créons cette méthode dans le portefeuille actuel. reviendront, ils recevront un appel à la méthode d'identification de l' adresse dans le champ adresses, en transmettant les mêmes arguments reçus que ses paramètres. Créons cette méthode dans la classe d'adresses. Obtiendra tous ces objets habillés avec le type d'adresse donné. Ensuite, nous le convertirons en liste. Ensuite, nous obtiendrons l' adresse par index. Pour ce faire, nous devons remplacer le type d'index d'adresse par un objet long, pas uniquement un type primitif. Ensuite, nous appellerons la valeur int, transmettant en tant que paramètre getMethod. Nous allons maintenant renvoyer la chaîne d'adresse à partir de l'adresse obtenue. Revenons maintenant au service de mise à jour des adresses de portefeuille actuelles qui définira simplement l'adresse de réception du portefeuille actuel comme adresse suivante obtenue. Faisons encore une chose avant de tester notre code. N'oubliez pas que le codon, cette classe, s'exécutera dans un nouveau thread. Dans Java FX, il est recommandé d'exécuter du code qui modifie l'interface utilisateur uniquement dans le thread principal. Pour ce faire, appelons la méthode platform point run later en lui transmettant une fonction Lambda. Déplaçons ces deux lignes vers le corps de la fonction lambda car elles entraînent des modifications qui affecteront l'interface utilisateur. Maintenant, effectuons à nouveau nos tests de réception de bitcoins. Génial. Le champ de l'adresse de réception a été mis à jour une fois les fonds reçus et les tests réussis. Dans la prochaine vidéo, nous continuerons à améliorer nos tests et ajouterons un scénario de test supplémentaire. C, oui. 35. 33 Recevoir des bitcoin partie 9 skillshare 2: Dans cette vidéo, nous continuerons à améliorer nos tests et ajouterons un autre scénario de test important pour la fonctionnalité de réception de bitcoins. Il manque une chose dans nos tests. Nous ne savons pas encore si les bonnes adresses sont générées et si elles respectent la séquence d' index du chemin de dérivation. Pour vérifier cela, créons que l'adresse est une méthode valide. Ensuite, le bloc du premier test appelé adresse est une méthode valide transmettant l'adresse, le germe mnémotechnique et l'indice d'adresse attendu, qui dans ce cas est nul comme paramètres. Créons cette méthode. Cela renverra un booléen. Définissons les bons noms de paramètres. Ici. Nous allons créer un nouvel objet de départ mnémotechnique et le stocker dans la variable de départ mnémotechnique. Renommons le paramètre de départ mnémotechnique en chaîne de départ mnémotechnique. Nous allons maintenant instancier l'objet de départ mnémotechnique en passant la chaîne de départ mnémotechnique comme paramètre du constructeur. Maintenant, créons la clé principale avec le code suivant. Appelle la méthode des deux clés principales sur l'objet source mnémotechnique, transmettant une chaîne vide comme premier paramètre et le préfixe privé net principal comme second. Créons maintenant la chaîne de clé Pub étendue avec le code suivant. Nous utiliserons le service étendu Pub Key. Injectons-le donc dans cette classe. Ensuite, nous appellerons la méthode create dessus, en passant la clé principale comme premier paramètre. Le deuxième paramètre sera une concaténation entre une partie du chemin de dérivation de l'adresse du segment et le paramètre d'index. Remplaçons le type de paramètre d' index par la classe entière, afin de pouvoir appeler la méthode toString dessus. Le troisième paramètre sera la constante Segway de type d'adresse. Ensuite, nous appellerons la méthode get key sur le résultat. Nous allons maintenant obtenir l'objet de clé pub étendue à partir de la bibliothèque Java Bitcoin en utilisant la méthode sérialisée Extended Pub Key , transmettant la chaîne de clé pub étendue comme son paramètre obtiendra l'adresse attendue à l'aide du générateur d'adresses de segment. Injectons-le dans cette classe. Nous appellerons ensuite la méthode generate, en transmettant la clé pub étendue comme paramètre. Enfin, nous allons renvoyer le résultat de la comparaison si l'adresse attendue est égale au paramètre d'adresse. Ajoutons maintenant que l'adresse est un appel de méthode valide pour vérifier les adresses dans les autres méthodes de cette classe. Dans cette méthode, ajoutons-le deux fois. La deuxième fois, nous vérifierons si l'adresse suivante est égale à l' adresse attendue avec l'index un. Faisons nos tests. Super, les tests sont réussis. Nous savons maintenant que les adresses sont générées correctement. Créons maintenant un autre test. Le prochain test tentera de transférer plus de transactions que le nombre d'adresses générées. N'oubliez pas que nous avons fixé le nombre initial d'adresses générées à 20. Nous devons donc vérifier ce qui se passe lorsque toutes les adresses initialement générées sont utilisées. Mais exécuter un test avec 20 transactions prendrait beaucoup de temps. Nous changerons donc le nombre initial d' adresses générées dans l'environnement de test à trois plus tard pour accélérer les choses. Copions donc cette méthode et collez-la ci-dessous. Changez son nom pour qu'il reçoive du Bitcoin en sept transactions à des adresses différentes, trois adresses étant générées dans notre portefeuille et sept transactions lors de ce test, notre portefeuille aurait besoin pour générer quatre adresses supplémentaires rapport au nombre initial pour que ce test réussisse. Remplaçons le nom du portefeuille créé par mon portefeuille de test. Pour l'instant, nous allons créer un fichier de propriétés pour l'environnement de test afin de modifier le nombre initial d' adresses générées pour nos tests. Créons donc un chemin de ressources dans le package de test. Sélectionnez l' option Ressources ci-dessous. À l'intérieur, il créera un fichier appelé propriétés des points de test de l'application. Nous allons copier le contenu du fichier de propriétés des points de notre application et le coller ici. Réglons maintenant le nombre initial de propriétés d'adresses générées sur trois. Passons maintenant à la classe de configuration des adresses. La méthode du nombre initial d'adresses générées renvoie actuellement 20 injectera cette valeur dans cette classe à partir du fichier de propriétés en utilisant cette annotation de valeur et ce champ privé. Maintenant, dans cette méthode, le champ créé sera simplement renvoyé. Maintenant, nous allons utiliser les propriétés des fichiers de propriétés des points de test de l'application dans nos tests. Passons à la classe de test de l'interface graphique. Ajoutez-y cette annotation. OK, maintenant, chaque fichier de test qui étend le test de l'interface graphique obtiendra ses propriétés à partir du fichier de propriétés point du test de l'application. Revenons maintenant à notre dernier test. Remplaçons le nom de cette variable par la première adresse. Le nom de la deuxième adresse de cette variable. Copions maintenant ces lignes et générons quatre transactions supplémentaires pour former davantage d'adresses nouvellement générées, modifiant leur code en conséquence. Passons à sept la taille de ligne attendue du tableau. Copions également ces lignes pour valider toutes les adresses générées lors du test. Modifions les paramètres des méthodes selon les besoins. Maintenant, faisons nos tests. Comme prévu. Le dernier test a échoué après la troisième transaction car le portefeuille n'a pas pu trouver la quatrième adresse puisqu'il n' a généré que les trois premières adresses. Dans la prochaine vidéo, nous allons corriger cela. Avant de terminer la vidéo, ajoutons la propriété du nombre initial d'adresses générées au fichier de propriétés des points de l'application. Réglons-le sur 20 pour que le portefeuille fonctionne comme avant dans un environnement non test. 36. 34 Recevoir des bitcoin partie 10 skillshare 2: Dans cette vidéo, nous allons réussir notre dernier test créé. Pour ce faire, passons au service de mise à jour des adresses de portefeuille actuelles. Dans cette méthode, ajoutons l'instruction if suivante. Après avoir calculé le prochain index d'adresses. Dans l'instruction if, nous les appellerons must import addresses, méthode passant l' index d'adresse suivant et le type d'adresse. Créons cette méthode. N'importera les adresses que si le prochain index d'adresses est égal au nombre total d'adresses du portefeuille actuel avec un type d'adresse donné. Si tel est le cas, cela signifie que nous n'avons plus d'adresses et que nous ne pouvons donc pas renseigner l'adresse suivante pour notre portefeuille sans créer d'autres adresses. À l'intérieur de cette méthode , le résultat de la vérification si le prochain index d' adresses est égal au portefeuille actuel, l'appel à la méthode get addresses count du portefeuille transmettra le type d' adresse à cette méthode. Et créons cette méthode. Cette méthode renverra un int et renverra les adresses, obtiendra l' appel à la méthode de comptage des adresses, en transmettant le type d'adresse en paramètre. Créons cette méthode. Ici, nous allons simplement obtenir toutes les adresses avec le type d'adresse donné dans une liste et renvoyer la taille de la liste au service de mise à jour des adresses de portefeuille actuelles. Dans le bloc if, vous obtiendrez d'abord les clés de pub étendues du portefeuille actuel et les stockerez les clés de pub étendues du portefeuille actuel dans une variable. Créons cette méthode. Ici. Nous allons renvoyer le champ de clés de pub étendu. Créons-le. Ajoutons également un setter pour ce champ. Nous appellerons cet ensemble ou, dans la mise à jour, la méthode de mise à jour du service de portefeuille actuel. lui passant les clés étendues du pub du portefeuille. Revenons maintenant au service de mise à jour des adresses de portefeuille actuelles. Nous appellerons la méthode d'ajout d' adresses sur le service d'adresses ADD. Transmettre les clés de pub étendues précédemment obtenues comme premier paramètre et l'index d'adresse suivant comme deuxième paramètre. Injectons ce service dans cette classe. Créons ce service et le package de services d'API. Ajoutons-y l' annotation du service. Maintenant, finissons d'injecter ce service dans cette classe. Et créons cette méthode dans le service d'adresses publicitaires. Remplaçons le nom de ce paramètre par from index. Ce que nous prévoyons de faire maintenant, c'est de générer des adresses pour les clés de pub étendues qui ont été transmises en tant que paramètres. Le nombre d' adresses générées sera égal au nombre initial d' adresses générées dans le champ. Et l'indice de dérivation généré par la première adresse sera déterminé par la variable d' indice de l'entreprise, par exemple supposons que le nombre initial d' adresses générées soit égal à 20 et que la variable d'indice from soit égale à 20. Dans ce cas, cette méthode générera une robe avec un indice de dérivation de 20 à 39. Pour ce faire, pour chaque clé de pub étendue. Nous appellerons la méthode add addresses transmettant la clé et le paramètre d'index from. Supprimons cette lettre S. Créons maintenant cette méthode privée d'ajout d'adresses. Il appellera la méthode add addresses sur la clé pub étendue en tant que paramètre. Nous utiliserons le générateur séquentiel d'adresses. Injectons-le donc dans cette classe. Nous appellerons la méthode generate sur le générateur séquentiel d'adresses, en transmettant la clé pub étendue, le type de clé de pub étendue et la variable d'index from comme paramètres. Passons à l'implémentation de la méthode generate. Le modifiera pour générer des adresses avec des index de dérivation en utilisant le paramètre from index. Ajoutons donc from index comme troisième paramètre. Ici, dans la méthode range, l' appel ajoutera la variable d'index from comme premier paramètre. Et la somme du paramètre d' index from et du nombre initial d' adresses générées comme seconde. Revenons maintenant au service d'ajout d'adresses. Créons la méthode des adresses publicitaires sur la classe de clé Pub étendue. Corrigons le nom de ce paramètre. Ici. Nous appellerons la méthode addresses add all en lui transmettant le paramètre addresses. Il y a un problème avec ce code. Le champ d'adresses est de type liste, qui est immuable. Cela signifie que lorsque nous essayons d'y ajouter des éléments via la méthode add all, une erreur apparaît. Passons donc au type ArrayList, qui est mutable. Faisons également en sorte qu'il soit définitif et instancié ici. Changeons également le getter d' adresses et la méthode des adresses pour obtenir et définir un ArrayList. Supprimons également la méthode set addresses car nous ne l'utiliserons plus. Revenez au service d'ajout d' adresses. Enveloppons le résultat de l' appel de méthode generate dans une nouvelle ArrayList, puisque la méthode ad addresses n'accepte désormais qu'une ArrayList. Examinons maintenant les facteurs qui créent un service de portefeuille. Depuis que nous avons apporté des modifications qui ont affecté. Tout d'abord, supprimons le service générateur séquentiel d'adresses de cette classe. Supprimons également cette méthode. Supprimons cette ligne de code. Nous utiliserons le service d'ajout d' adresses pour ajouter des adresses aux clés de pub étendues. Injectons-le donc dans cette classe. Et appelons-y la méthode add addresses, en transmettant les clés pub étendues et zéro comme paramètres. Finissons de l' injecter dans cette classe. Revenons maintenant au service de mise à jour des adresses de portefeuille actuelles. Nous appellerons la méthode set addresses sur le portefeuille actuel, en transmettant les clés pub étendues comme paramètre. Supprimons l'appel de méthode clear des lignes d' adresses dans les méthodes set addresses, car nous ne voulons supprimer aucune ligne de table d'adresses après avoir défini ces adresses. Créons plutôt une méthode appelée clear address rows, qui permettra de le faire. Ensuite, dans la méthode de mise à jour du service de mise à jour du portefeuille actuel, nous appellerons cette méthode pour effacer les lignes d'adresse uniquement après avoir ajouté un nouveau portefeuille. Revenons maintenant au service de mise à jour des adresses de portefeuille actuelles qui récupérera toutes les adresses nouvellement générées dans le portefeuille actuel et les stockera dans cette variable. Pour obtenir les adresses, vous appellerez la méthode get addresses sous forme de chaînes sur le portefeuille actuel. Passer l' index d'adresse suivant comme premier paramètre. Et la somme du champ d'index d'adresses suivant et du nombre initial et du nombre initial d'adresses générées comme deuxième paramètre. Injectons ce champ dans cette classe. Ajoutons l'annotation du qualificatif pour utiliser le bean défini dans la classe de configuration d'adresse afin injecter la valeur souhaitée dans ce paramètre. Maintenant, créons cette méthode. Remplaçons ces noms de paramètres par ceux de l'index 2. Cette méthode renverra les adresses, obtiendra les adresses sous forme de chaînes appellera la méthode en transmettant les mêmes paramètres que ceux reçus. Créons cette méthode dans la classe d'adresses. Cette méthode renverra toutes ses adresses avec des index entre les paramètres de l'index 2, sans compter l'échelle. Pour cela, il renverra le code suivant. Nous utiliserons la méthode FlatMap pour convertir toutes les adresses en un flux d'objets d'adresse. Ensuite, nous filtrerons le flux pour renvoyer uniquement les adresses dont l'indice est supérieur ou égal à la variable d'indice de l' entreprise et inférieur aux deux variables d'indice. Ensuite, nous appellerons une carte sur le résultat pour renvoyer un flux de chaînes d'adresses. Enfin, nous allons convertir le résultat en liste et le renvoyer. Revenons maintenant au service Update Current Wallet Addresses, qui utilisera les clients d'adresses à importation multiple du nœud pour importer les adresses nouvellement générées dans notre nœud Bitcoin. N'oubliez pas que cela est nécessaire car il est nécessaire que le nœud connaisse nos adresses afin qu'il puisse envoyer les transactions associées à notre portefeuille d'applications. Injectons-le donc dans cette classe. Nous allons maintenant appeler la méthode des adresses d'entrée qui s'y trouve, en passant le nom actuel du portefeuille , les chaînes d'adresse et une nouvelle date comme paramètres. Super, notre fonction de rotation des adresses devrait fonctionner maintenant, même après avoir utilisé toutes les adresses initialement générées. Mais abordons un autre problème ici. Nous définissons l'adresse suivante comme adresse de réception dans notre portefeuille. Même s'il s'agit d'un type adressé, il s'agit d'un changement d'adresse. Réglons ça. Puisque nous voulons uniquement des adresses de type Segway, le Segway ne change pas de type comme adresse de réception dans notre portefeuille. Nous allons donc ajouter cette déclaration if. Si le type d'adresse est égal à la constante d' adresse principale , cela la définira sur segue. Maintenant. Ensuite, nous définirons l'adresse suivante comme adresse réception suivante dans le portefeuille actuel. Encore une chose, supprimons cette plate-forme, l'appel run later appellera la méthode run later uniquement en encapsulant le code qui changera réellement l'interface utilisateur. Utilisons-la donc pour encapsuler uniquement l'appel nominal actuel défini par le portefeuille. Utilisons-le également pour encapsuler l'appel de méthode d'adresse de réception actuel de l'ensemble de portefeuille. Ainsi, nous évitons de bloquer l'interface utilisateur lors communication avec notre nœud Bitcoin appel à la méthode d'importation des adresses. Passons maintenant au contrôleur de table d' adresses. J'ai remarqué que le TableView n'est parfois pas mis à jour pour refléter l'état réel de ses lignes. Pour résoudre ce problème, ajoutons ce code à cette méthode. Ajoutera un écouteur aux lignes d'adresses observables du portefeuille actuel. Dans le corps de ce lambda, il suffira appeler la méthode d'actualisation dans la table des adresses. Ainsi, pour chaque mise à jour des adresses de nos portefeuilles, nous avons la garantie que le tableau s'affiche, que l'état sera actualisé et les informations actuelles relatives à nos adresses de portefeuille s' afficheront à l'écran. Passons maintenant au test du générateur séquentiel d'adresses et ajoutons zéro comme troisième paramètre de la méthode de génération afin que ce test continue de fonctionner. Corrigons également le test du service Create Wallet. Dans la méthode de configuration, instancions le service d'adresses ADD en passant le générateur séquentiel d'adresses comme paramètre. Et remplaçons le troisième paramètre du service de création de portefeuille par le service d'adresse ADD. Maintenant, lors du dernier test de réception de Bitcoin, apportons un petit changement. Après avoir envoyé des bitcoins à la troisième adresse. Ajoutons l'appel de la méthode sleep qui passe le délai d'attente et les secondes comme arguments. Ajoutons également le même appel après avoir envoyé des Bitcoins à la sixième adresse. La raison de ces appels est qu'avant d'envoyer des Bitcoins aux quatrième et septième adresses, nous devons les générer et les importer nos nœuds avant d'accepter des transactions. Et le processus d'importation prend un certain temps. Laissons enfin tous nos tests d'application. Super, tous les tests sont réussis. Nous avons enfin terminé les bases de la fonctionnalité de réception de bitcoins de notre portefeuille. Maintenant, nous allons commencer à mettre en œuvre l'observation de nouveaux blocs ajoutés à la blockchain afin de pouvoir mettre à jour le nombre de conformations dont les adresses ont un C, oui. 37. 35 Receiving la partie de bloc 1 de partage de compétences 2: Dans cette vidéo, nous allons effectuer des tests pour assurer que lorsqu'un bloc est extrait dans la Blockchain, notre portefeuille reçoit des transactions mises à jour avec des conformations croissantes. Déplaçons donc les méthodes auxiliaires de la classe de test Bitcoin de réception vers le test de l'interface graphique afin de pouvoir utiliser ces méthodes dans d'autres classes qui l'étendent. Maintenant, nous allons déplacer toutes ces propriétés vers la classe GUI également pour la même raison. Maintenant, coupons ces deux lignes , collons-les dans le portefeuille de chargement et ajoutons méthode équilibrée dans la classe de test de l'interface graphique. Dans la méthode de configuration de la classe de test reçue, nous appellerons simplement cette méthode. Supprimons toutes ces importations inutilisées dans cette classe. Dans la classe de test GUI, protégeons ces méthodes et propriétés. Maintenant, dans le package de test de l'interface graphique, créons la classe de test par bloc de réception. Cela étendra la classe de test de l'interface graphique. Copions la méthode de configuration et le test de réception de Bitcoin et collez-les ici. Copions également le premier test du test de réception de Bitcoin et collez-le dans la classe de test par blocs de réception. Il servira de modèle pour le prochain test que nous créerons. Remplaçons le nom du portefeuille créé par mon portefeuille d'essai 5. Changeons le nom du tube à essai qui devrait recevoir du Bitcoin et ajoutons des confirmations par hashtag, confirmations pour recevoir cette robe. Les conformations des hashtags seront interpolées par la variable de test de confirmations que nous allons créer. Maintenant, après avoir envoyé des Bitcoins , j' appellerai la méthode des blocs miniers passant la variable de confirmation comme paramètre. Créons cette méthode. Il prendra un int comme paramètre. Avec cette méthode, nous utiliserons le nœud generate pour adresser le client aux blocs de mine. Alors, collons-y un peu de code. Dans la classe de test de l'interface graphique, copiez cette ligne de code et collez-la ici. Modifiez le nom de la variable d'adresse pour noter l'adresse. Faites de même avec cette autre ligne. Changez le deuxième paramètre de la méthode de génération en blocs. Il utilisera donc cette variable pour définir le nombre de blocs qu'il exploitera et remplacera ce paramètre par une adresse de note. Maintenant, copions ce poids pour un appel de méthode et collez-le ici. Supprimez ces parties de code. Cette méthode attend que la valeur de la cellule de confirmation de la première ligne de la table d'adresses soit égale à la variable blocks. Dans le bloc Venn, vous vérifierez si la valeur de la cellule de confirmation de la première ligne du tableau est égale à la variable de confirmation. Incluons une clause where. Ici. Nous allons définir la confirmation comme variable pour certaines valeurs de test. Nous allons ajouter un espace réservé pour la deuxième colonne de la WhereClause, car elle ne fonctionne apparemment que si elle comporte deux colonnes ou plus. Réglons les valeurs de confirmation sur 12,3. Maintenant, exécutons notre nœud Bitcoin et lançons notre nouveau test. Super, les tests sont réussis. Faisons maintenant un autre test pour le scénario suivant. Nous voulons savoir ce qui se passe lorsqu' une adresse reçoit deux transactions. Et la deuxième transaction comporte moins de conformations que la première. Dans ce cas, nous nous attendons à ce que le nombre d'adresses de conformations soit égal au nombre de conformations de la transaction avec moins de conformations à cette adresse. Dupliquons donc le premier test. Changeons son nom pour qu'il devrait recevoir du Bitcoin et considérons la transaction avec moins de conformations comme confirmations d'adresse. Remplaçons le nom de création du portefeuille mon portefeuille de test 6. Maintenant, dupliquons ces lignes de code pour envoyer à nouveau des bitcoins et des blocs de mines. Dans la deuxième mine, les blocs appellent « ajouter moins un » dans son paramètre pour extraire moins de blocs après la deuxième transaction. Dans le bloc, nous nous attendons à des confirmations moins un comme nombre de confirmations dans la première ligne du tableau. Supprimons cette ligne car nous ne voulons pas ce scénario de test, car il essaierait de supprimer zéro bloc lors du deuxième appel à mines, ce qui échouerait. Faisons à nouveau nos tests. Super, les tests sont réussis. Nous en concluons donc que notre portefeuille est déjà prêt à mettre à jour le nombre de conformations de nos adresses. En effet, après chaque bloc de mine, le nœud envoie un message via zéro MQ à notre application contenant les transactions précédemment importées, mais avec un nombre de confirmations mis à jour. 38. 36 Recevoir la transaction partie 1 de la combinaison de compétences 2: Dans cette vidéo, nous allons commencer à créer le tableau des transactions. Ce tableau sera similaire au tableau des adresses, mais au lieu de lignes contenant informations sur les adresses, ce tableau contiendra des informations sur chaque transaction envoyée ou reçue par notre portefeuille. Commençons donc par créer un test d' interface graphique pour cette table. Dans le package GUI, créez une classe appelée Receiving Transaction Test. Copiez ces méthodes à partir du test de bloc de réception et collez-les ici. Cette classe étendra la classe de test de l'interface graphique. Modifiez le nom de ce test pour avoir dû recevoir la transaction. Formatons cette méthode. Supprimez it's where block, changez le nom de création du portefeuille pour mon test pendant qu'il est sept. Supprimez cette ligne. Maintenant, après avoir mis la méthode en veille, faisons en sorte que le test clique sur un composant avec un onglet d'identification éthique des transactions. Ajoutons maintenant un autre paramètre facultatif à la méthode send Bitcoin and wait. Ce paramètre sera une chaîne et sera appelé composant de recherche. Sa valeur par défaut sera la table des adresses des hashtags. Remplaçons ce paramètre dans l'appel de méthode de recherche par la variable du composant de recherche. Maintenant, dans le test, ajoutons ces paramètres à la méthode send Bitcoin and wait. Le quatrième paramètre sera la table des transactions par hashtag. Ainsi, après avoir envoyé une transaction, cet appel de méthode attendra que la table des transactions soit remplie avec une ligne contenant un solde de 1,0 Bitcoin. Maintenant, changeons également le paramètre de la méthode de recherche en table des transactions par hashtag. Dans le bloc then, laissons simplement l'assertion selon laquelle la taille de la ligne du tableau est égale à un pour le moment. Maintenant, concevons notre table. Passons au point FXML du terrain de jeu. Copions tout ce contenu entre la balise tab et collez-le ci-dessous. Changez maintenant sa propriété de texte en transactions et son identifiant éthique en onglet transactions. Changez également l'identifiant éthique de la balise d' affichage du tableau un tableau des transactions. Nous allons maintenant remplacer le champ de texte de la première colonne par l'ID de transaction. Le tableau comportera également une colonne équilibrée et une colonne de confirmations. Nous conserverons donc ces balises telles quelles. Dupliquons la dernière balise, changeons son texte à ce jour. Cette colonne contiendra la date de création de ces transactions. Cliquons maintenant sur le Scene Builder pour voir à quoi ressemblent notre nouvel onglet et notre nouveau tableau. OK, ça a l'air sympa. Nous allons maintenant créer un nouveau FXML pour ce composant. Appelons cela un tableau de soulignement des transactions. Supprimons le code standard. Copions ce contenu depuis le point FXML du terrain de jeu et collez-le ici. Importons ces balises. Changez cette balise pour corriger la route entre deux points. Supprimez ce contenu en tant que type. Définissons le chemin du composant de la vue tabulaire et définissons cette URL en tant que champ XML NS tant que table des transactions de l' ensemble de propriétés Ethics ID. Supprimez maintenant ces balises, que nous n'avons pas eu besoin de copier. Ajoutons maintenant ces identifiants éthiques à ces balises de colonne. Ils seront utiles plus tard lorsque nous créerons le contrôleur de la table des transactions. Maintenant, dans le point FXML de la fenêtre principale, dupliquons le contenu entre ces balises. Changons le texte de l'onglet en transactions et son identifiant FX en onglet transactions. Maintenant, changez cette balise en contrôleur de table des transactions. Créons ce contrôleur dans le package GUI Dot Controllers. Importons le point FXML dans la fenêtre principale. Ajoutons maintenant l' annotation du composant au contrôleur de table des transactions. Cela étendra la classe d'affichage tabulaire paramétrée avec la classe de ligne de transaction que nous allons créer. Créons la classe réelle de transaction dans le package observables. Passons maintenant au contrôleur de l' onglet Receive, copions son constructeur et collez-le ici, en y apportant les modifications appropriées. Modifions son annotation de valeur pour qu'elle pointe vers le point FXML de la table de soulignement des transactions. Injectons également le portefeuille actuel dans cette classe. Il sera utile plus tard. Maintenant, nous devons inclure le contrôleur de table des transactions dans la liste des composants personnalisés de l'écouteur de démarrage de l'interface graphique Nous pouvons simplement ajouter une autre clause or dans l'instruction if de l' initialize Méthode FXML. Mais refactorisons cette classe en procédant comme suit. Créons ici un ensemble statique privé d'objets de classe appelés composants personnalisés. Instancions-le ici avec la classe de méthode set. Incluons ces classes de contrôleurs dans l'ensemble. Maintenant, dans l'instruction if, il suffit de vérifier si l'ensemble de composants personnalisés contient le type donné. Passons maintenant au test de la transaction de réception. Passons maintenant au nettoyage et à la compilation des objectifs Maven en matière de cycle de vie. Cela est parfois nécessaire pour inclure de nouveaux fichiers FXML dans le projet compilé. Maintenant, exécutons notre nœud principal Bitcoin s'il ne fonctionne pas déjà. Enfin, lançons le test. Le test a échoué car il n'a pas trouvé de ligne contenant les informations de transaction dans le tableau des transactions continuerons à implémenter cette fonctionnalité dans la vidéo suivante. revoit. 39. 37 Recevoir la transaction partie 2 de la combinaison de compétences 2: Dans cette vidéo, nous allons terminer l'implémentation de la table des transactions et réussir ce test. Passons donc au service de mise à jour UTXO. Si vous vous en souvenez, cette méthode de mise à jour est appelée fois que nous recevons une transaction de notre nœud La classe de tâches du nœud surveille notre nœud pour détecter les messages de transaction. Notre application publie ensuite un événement de réception de transaction qui est écouté par notre écouteur de transactions. L'écouteur de transactions analyse et filtre le message et appelle la méthode de mise à jour du service UTXO update. Ainsi, après avoir récupéré UTXOS et mis à jour les adresses actuelles des portefeuilles, mettons à jour les transactions de portefeuille actuelles l'aide de ce service. Injectons-le dans cette classe. Créons-le dans le package GUI point services. Ajoutons-y l' annotation du service. Maintenant, finissons de l' injecter dans cette classe. Appelons maintenant la méthode de mise à jour sur ce service en passant la variable utxOS comme paramètre. Créons cette méthode. Cette méthode s' exécutera de manière asynchrone. Ajoutons-y donc l' annotation asynchrone en utilisant le service d'exécution par défaut comme paramètre. Faisons de même avec la méthode de mise à jour du service de mise à jour des adresses de portefeuille actuelles. Implémentons maintenant la méthode de mise à jour et le service de transaction Wallet actuel convertira la liste des UTXO en une liste de lignes de transactions et stockera le résultat dans les lignes de transaction. Une variable utilisant le code suivant filtrera le flux d'utxOS en ne conservant dans le flux que les UTXO avec des adresses dans le portefeuille actuel. Injectons donc le portefeuille actuel dans cette classe. Maintenant, dans le corps lambda, vous obtiendrez toutes les adresses sous forme chaînes et vérifierez s'il contient l'adresse UTXO. Nous allons maintenant appeler la méthode map sur le flux résultant, transmettant la ligne de transaction from method comme paramètre. Créons cette méthode. Ce sera une méthode statique qui renverra un objet de ligne de transaction. Similaire à la classe de lignes d' adresses. La classe de lignes de transactions représentera une ligne et la table des transactions. Ajoutons donc les propriétés suivantes à cette classe. Chaque propriété représentera une colonne dans le tableau des transactions. Supprimons le dernier mot clé de chaque propriété car l'IDE le fait, il permet de créer automatiquement des setters pour ces propriétés, si elles sont définitives. À l'aide de cette fonction d'identification, ajoutez maintenant des getters et des setters pour chaque propriété. Nous pouvons maintenant réajouter le mot clé final à ces propriétés. Maintenant, créons un constructeur. Le constructeur prendra chaque propriété de classe comme paramètres. Et nous utiliserons les ensembles de propriétés pour définir les propriétés dans le corps du constructeur. Nous pouvons maintenant continuer à mettre en œuvre la méthode. Il renverra une nouvelle ligne de transaction avec les paramètres suivants. Revenez au service de transaction Update Current Wallet. Nous allons maintenant convertir la chaîne résultante en une liste. Nous allons maintenant ajouter la rose de transaction obtenue au portefeuille actuel en utilisant la méthode add transaction rows. Créons cette méthode. Il utilisera le champ des lignes de transaction. Créons-le donc maintenant. Son type sera le type de transactions Rose Class. Créons-le dans le package observables. Revenons au portefeuille actuel. Faisons en sorte qu'il soit définitif et instancions-le ici. Faisons également en sorte que le champ des lignes d' adresses soit définitif. Dans la méthode ED transaction rows, appelons la méthode add transaction rows le champ des lignes de transaction. Transmettre les lignes de transaction données en tant que paramètre. Créons cette méthode. Tout comme la classe des lignes d'adresses est chargée gérer la liste des lignes d'adresses affichée dans le tableau des adresses. Cette classe fera de même pour les lignes de transactions et la table des transactions. Ainsi, pour chaque ligne de transaction, nous vérifierons si le champ de feuille de route de la transaction la contient déjà. Créons donc ce champ. Ce sera une carte observable où la clé est une chaîne et la valeur est une ligne de transaction. Instancions-le ici avec un wrapper de carte observable, en passant un nouveau HashMap lié comme constructeur. Ainsi, si la feuille la transaction contient l'identifiant de la ligne de transaction dans ses clés, nous définirons la rotation de la transaction à la date de la transaction présente dans la feuille de route des transactions de route de la transaction contient l'identifiant de la ligne de transaction dans ses clés, nous définirons la rotation de la transaction à la date de la transaction présente dans la feuille de route des transactions. cela pour préserver la date de création de la transaction. Ensuite, après l'instruction if, la ligne de transaction sera supprimée de la carte par son identifiant et replacera la ligne de transaction donnée dans la feuille de route des transactions en utilisant son identifiant comme clé. Encore une fois, nous supprimons et ajoutons la même ligne de transactions afin de forcer la carte observable à publier des événements de changement qui seront écoutés ultérieurement. Créons maintenant le champ de liste observable qui sera utilisé pour lier les modifications apportées à la feuille de route des transactions au contrôleur de table. Instancions-le ici en utilisant un wrapper de liste observable instancié avec une nouvelle liste liée. Créons maintenant la méthode get observable transaction row list. Il renverra la liste des rôles dans les transactions. allons maintenant lier la feuille des transactions à la liste des rôles de transaction dans le constructeur, comme nous l'avons fait pour le jeu de lignes d'adresses et la liste de lignes d'adresses dans la classe des lignes d'adresses. Donc, pour accélérer les choses, copions le constructeur des lignes d'adresses et le collons ici. Corrigons son nom. Maintenant, au lieu d'appeler les méthodes figurant dans la liste des rôles d'adresses, nous allons le faire dans la liste des rôles de transaction. Au lieu d'utiliser un écouteur de changement de carte, vous utiliserez un écouteur de changement paramétré par une chaîne et une ligne de transaction. De plus, au lieu d'utiliser l'élément get supprimé ici, nous utiliserons le getValue removed. Ici. Nous utiliserons la valeur ajoutée. Et ici, nous allons ajouter un auditeur à la feuille de route des transactions. Encore une chose pour que cela fonctionne, nous devons implémenter la méthode equals dans la classe de lignes de transaction. Cela est dû au fait que la liste des lignes de transactions sera utilisée pour décider quelle ligne de transaction supprimer elle-même. Mettons-le donc en œuvre à l'aide de cette fonctionnalité IDE. Assurez-vous de cocher la case use getters dans cette fenêtre pour utiliser uniquement la propriété ID pour définir l'égalité dans cette classe. Cliquez également sur la case ID ici pour qu'elle ne soit pas nulle. D'accord, l'IDE a généré ces méthodes comme prévu. Revenons à la classe des lignes de transaction. Créons la méthode clear, qui sera appelée lors de la création d'un nouveau portefeuille. À l'intérieur, il appellera la méthode clear sur la feuille de route des transactions et sur la liste des rôles de transaction. Dans la classe de portefeuille actuelle, créons la méthode good observable transaction rows. Cela renverra qu'ils obtiennent un appel à la méthode de liste de lignes de transactions observable appel à la méthode de liste de lignes de transactions dans le champ des lignes de transactions. Créons également la méthode des transactions claires ici. Cela appellera la méthode clear des lignes de transaction que nous venons de créer. Passons maintenant à la mise à jour du service de portefeuille actuel. Ici, nous appellerons la méthode des transactions claires du portefeuille actuel . Ce faisant, nous veillons à effacer les lignes de transaction après avoir créé un portefeuille. Passons maintenant au contrôleur de table des transactions. Ajoutons les champs suivants. Il sera utilisé ultérieurement dans la méthode initialisée pour lier la table et ses colonnes aux lignes de transaction observables. Créons maintenant la méthode initialisée. Ici, nous allons d'abord définir les éléments de la table des transactions sur les lignes de transactions observables du portefeuille actuel. Nous allons maintenant ajouter un écouteur aux lignes de transactions observables du portefeuille actuel. Nous appellerons la méthode d' actualisation de la table des transactions dans le corps de la table afin que chaque modification apportée à l' observable déclenche un nouveau dessin de la table. Liera également chaque champ de colonne au champ de ligne de transaction en utilisant la fabrique de valeurs de cellule définies, comme nous l'avons fait dans le contrôleur de table des adresses. En tant que paramètre d'usine de valeur de propriété, nous devons utiliser les mêmes noms de propriété que ceux que nous avons utilisés dans la classe transaction real pour effectuer correctement la liaison. Dupliquons cette ligne trois fois et changeons les colonnes que nous relions. Passons maintenant à la classe de test des transactions réceptrices. Assurez-vous d'exécuter le nœud Bitcoin Core et lancez le test. Oups, le test a échoué. Voyons pourquoi. Il y a un problème avec le champ d' équilibre des transactions de la colonne dans le contrôleur de table des transactions. Pour résoudre ce problème, passons au point FXML de la table de soulignement des transactions. Le problème est que nous avons mal nommé le solde, confirmations et les identifiants de date FX. n'y a pas le mot transaction après la colonne dans les trois cas. Corrigeons-les donc et relançons le test. Super, le test est passé. Dans la vidéo suivante, nous ajouterons d'autres tests pour nous assurer que la table des transactions fonctionne comme prévu. C, oui. 40. 38 Recevoir la transaction partie 3 de la combinaison de compétences 2: Dans cette vidéo, nous allons ajouter d'autres tests pour vérifier si notre tableau des transactions fonctionne pour d'autres scénarios. Passons donc à la classe de test par blocs de réception. Dans chaque méthode, un code sera ajouté pour tester si le tableau des transactions contient les informations attendues sur les transactions réceptrices. Renommons donc la vue tabulaire dans ce test pour répondre à sa vue tabulaire, afin de clarifier sa signification. Nous allons maintenant appeler la méthode click on passant comme paramètre, la chaîne de transactions. Copions maintenant la ligne avec la variable d'affichage du tableau des adresses et collez-la ci-dessous. Remplaçons le nom de cette variable en vue tabulaire des transactions. Dans la méthode de recherche, remplaçons ce paramètre tableau des transactions par hashtag. Copions maintenant ces deux lignes, collons-les ci-dessous et modifions-les pour appeler ces méthodes dans la vue de la table des transactions. Faisons de même avec l'autre méthode de test. Mais dans ce cas, nous nous attendons à ce que le tableau des transactions contienne deux lignes, une pour chaque transaction. Et pour la deuxième ligne, nous nous attendons à ce que le nombre de confirmations soit égal à la variable total des confirmations, ce qui créera la valeur totale des confirmations égale au nombre des blocs miens jusqu'à présent, ce nombre sera égal à confirmations plus confirmations moins un. Comme nous nous attendons à ce que la deuxième ligne contienne des informations sur la première transaction, elle sera confirmée ce nombre de fois. Apportons une petite correction à la méthode des blocs miniers. Parfois, cette ligne de code déclenche une exception NullPointerException car TableView possède une propriété null items. Pour éviter cela, utilisons l' opérateur sécurisé null avant chaque propriété dans la vue tabulaire. Maintenant, faisons nos tests. Tout d'abord, assurez-vous de faire fonctionner votre nœud Bitcoin. Faisons les tests. Les deux derniers tests ont échoué. Cela s'est produit parce que les transactions figurant dans le tableau ne sont pas ordonnées, leur ordre est apparemment aléatoire. Parfois, ces tests peuvent réussir car ils peuvent être correctement commandés par hasard. Alors, réglons ce problème. Notre objectif est de trier les transactions par date avec les transactions les plus récentes dans les premières lignes. Passons donc à la classe de lignes de transactions. Dans la méthode du formulaire. Changeons la façon dont nous transmettons les données à l'instanciation des lignes de transaction. Au lieu d'utiliser une nouvelle date, utilisons la méthode de l' instant présent. Nous le faisons parce que la classe instantanée est plus précise et plus facile à trier par Parson. Passons maintenant au contrôleur de table des transactions. Dans la table des transactions, définir les éléments (appel à la méthode). Passons une nouvelle liste triée comme paramètre. Les lignes de transactions observables du portefeuille actuel seront le premier paramètre instanciant la liste triée. Le deuxième paramètre sera l'appel à la méthode de comparaison du comparateur. Cette méthode transmettra un lambda comme premier paramètre ou une ligne de transaction sera le paramètre dans le corps du lambda. Appelons la méthode d'analyse instantanée en passant la rotation de la transaction comme paramètre. La méthode parse générera un objet d'instance à partir de la chaîne de date. Le deuxième paramètre de la méthode de comparaison sera l'appel à la méthode d' ordre inverse du comparateur. De cette façon, nous nous attendons à ce que le tableau des transactions soit trié par date de transaction, les dernières transactions en premier. Maintenant, relançons nos tests. Cette fois, seuls ceux qui ont échoué. Nous allons le faire en cliquant sur ce bouton. Super, les tests sont réussis. Ajoutons maintenant les tests de table des transactions à la classe de test de réception de Bitcoin. Nous ferons la même chose que dans la classe de test par blocs de réception. Pour chaque méthode, nous allons refactoriser le nom de la vue tabulaire, faire en sorte que le test clique sur l'onglet transaction et formuler des assertions concernant le contenu attendu dans le tableau des transactions. Allons-y. OK, maintenant, faisons ces tests. Super, les tests sont réussis. Nous allons maintenant exécuter notre portefeuille sur l'environnement de test du réseau pour la première fois. L'environnement du réseau de test est similaire à celui du réseau principal, mais leurs pièces ne valent rien. C'est beaucoup plus facile à comprendre et leur temps de blocage est plus court. Cela nous oblige à faire fonctionner et à couler notre nœud Bitcoin dans cet environnement. Nous avons expliqué comment procéder dans le guide de configuration du cours. Modifions donc notre bitcoin.com pour exécuter notre nœud dans l'environnement de test du réseau. Changez simplement cette clé de reg test en test net. Arrêtons d'exécuter notre nœud lors du test reg. Et relançons notre note pour commencer à couler notre note sur le filet de test. Ma note est presque nulle, il me faudra donc quelques minutes pour la rattraper. Mais selon la dernière fois que vous l'avez exécutée, synchronisation peut prendre plus de temps car le téléchargement des derniers blocs prendra un certain temps. Quoi qu'il en soit, pendant qu'il coule, modifions nos projets afin de pouvoir exécuter avec succès notre application sur le réseau de test. Dans le chemin des ressources, créons le fichier de test net point properties de l'application. Ce fichier contiendra les propriétés utilisées dans notre projet lorsque nous exécuterons l'application sur l'environnement réseau de test. Copions le contenu du fichier de propriétés des points de l'application propriétés des points de l'application et collez-le ici. Maintenant, changez l' environnement Bitcoin pour tester le net. Et le port URI sans point RPC 218332. Il s'agit du port par défaut de notre nœud lorsqu'il s'exécute sur l'environnement réseau de test. Maintenant, apportons une petite amélioration. Dans notre portefeuille, ce serait bien de pouvoir copier le numéro de transaction indiqué dans le tableau des transactions en cliquant simplement dessus avec le bouton droit de la souris et en cliquant sur Copier. Implémentons cette fonctionnalité. Pour ce faire, passons au FXML du tableau des points de soulignement des transactions. Ajoutons maintenant le code suivant ici. Tout d'abord, ajoutons ces balises de menu contextuel à l'intérieur. Ajoutons le tag items. Ensuite, la balise des éléments de menu. Dans la propriété de texte de cette balise, ajoutez la copie de chaîne et identifiant de transaction hashtag coffee, car il s'agit d'une propriété d'action. Cela indique à l' application d'appeler la méthode copy transaction ID dans le contrôleur de table des transactions. Après avoir cliqué sur l'élément Copier du menu contextuel. Le menu contextuel est un menu qui apparaît lorsque nous cliquons avec le bouton droit sur quelque chose à l'écran. Passons maintenant au contrôleur de table des transactions. Créons la méthode de copie de l'identifiant de transaction ici. Nous allons d'abord obtenir la ligne de transaction laquelle vous avez cliqué avec le bouton droit de la souris à l'aide de ce code. Maintenant, nous allons simplement appeler la méthode de copie. Nous allons créer la transmission de l' ID de ligne de transaction comme paramètre. Pour créer cette méthode, vous devez d'abord créer un package utils dans le package BYOD W. À l'intérieur, créons une classe appelée Copy. Maintenant, créons la méthode de copie ici. En tant que méthode statique. Instanciera un objet de contenu de presse-papiers, en le stockant dans la variable content. Ensuite, nous appellerons la méthode put string dessus, en passant le texte de la variable comme paramètre. Ajoutons cette variable en tant que paramètre de méthode de copie. Enfin, nous appellerons la méthode get system clipboard et définirons son contenu sur le contenu variable du contrôleur de table des transactions. Importons cette méthode. Encore une chose. Lors de l'exécution du nœud Bitcoin sur l'environnement réseau de test, notre nœud peut recevoir différents types de transactions que la bibliothèque Java Bitcoin ne peut pas encore analyser et générer des erreurs en essayant de le faire . Bien que le fait de ne pas analyser ces transactions affectera nos portefeuilles, l'erreur est bien signalée. Pour éviter cela, dans la classe de tâches node, encapsulez la méthode de transaction à partir du flux d' octets dans un bloc try-catch. Dans le bloc de capture, utilisons un enregistreur pour nous avertir de l'erreur. Dans la première méthode, l'appel transmettra une phrase indiquant l'erreur et une paire d'accolades à la fin. Ces accolades seront interpolées par le deuxième argument, qui sera la variable de contenu codée en hexadécimal interpolées par le deuxième argument, . Le troisième paramètre sera l'objet d'exception. Nous pouvons ainsi accéder à la trace complète de l'erreur dans les journaux. Après la journalisation, l'erreur passe directement à la prochaine itération de la boucle while en utilisant le mot clé continue. Créons le champ d'enregistrement. Ce sera une propriété statique. Instancions-le ici en utilisant la Logger Factory. Corrigons l'importation de la classe d'enregistreur. En fait, nous devons l'importer depuis le package 4D point SELF pour J. Exécutons maintenant notre application sur l' environnement du réseau de test. Commençons par vérifier si notre nœud est lié à l'environnement du réseau de test. OK, c'est déjà coulé car sa progression est égale à 1,00. Passons maintenant à la classe d'application BYOD W. Cliquez avec le bouton droit sur ce symbole et cliquez sur Modifier les configurations d'exécution. Cliquez maintenant sur Modifier les options et assurez-vous que les options de la machine virtuelle publicitaire sont sélectionnées. Réglez-le maintenant sur moins d profils à points à ressort, point actif, égal à test net. Cliquez sur OK, puis sur le bouton Exécuter. Créons maintenant un portefeuille. Notez que l' adresse de réception commence par TB, ce qui indique qu'il s'agit d'une adresse réseau test. Maintenant, copions cette adresse. Utilisera un robinet de test pour obtenir des Bitcoins nets de test. Un robinet Bitcoin est un site Web ou API qui propose des Bitcoins gratuitement. Ils étaient très populaires dans les premières années du Bitcoin, lorsqu'un Bitcoin était très bon marché. De nos jours, il existe un moyen rapide d' obtenir des pièces nettes de test. Allons sur le site Web à l'écran. C'est un robinet à filet d'essai. Collons l' adresse copiée dans ce champ. Choisissez un montant et cliquez sur ce bouton pour nous envoyer des bitcoins. Attendons un peu. OK, l'alerte indique qu'elle envoie des Satoshi dans notre portefeuille. Vérifions si nous l'avons bien reçu. Génial. Notre portefeuille a identifié notre transaction et notre transaction et notre adresse ont déjà une conformation. Mais il y a une chose étrange. La balance est formatée en notation scientifique. Nous corrigerons cela plus tard. Pour l'instant, copions notre numéro de transaction en cliquant dessus avec le bouton droit de la souris et en cliquant sur Copier. Nous vérifierons la transaction dans un explorateur de blockchain tiers. Un explorateur de blockchain est un site Web qui affiche des informations sur les adresses, les blocs et les transactions Bitcoin d'une manière agréable et organisée. Si votre vie privée est concernée, rechercher vos robes rouges et vos transactions sur n'est pas conseillé de rechercher vos robes rouges et vos transactions sur un explorateur de blockchain tiers , car cela leur permet de vous relier aux données de votre portefeuille. Mais comme nous ne l'utilisons qu'à des fins de test, ce n'est pas grave. Cela dit, allons sur le site Web affiché à l'écran, qui est un explorateur de blockchain Bitcoin Test Net, collons l'identifiant de transaction copié le champ de recherche et cliquez sur le bouton Rechercher. Nous obtiendrons ici des informations sur notre transaction. Notez qu'il possède déjà deux confirmations, mais notre portefeuille indique qu'il n' a qu'une seule conformation. Il s'avère que dans l'environnement du réseau de test, notre nœud Bitcoin envoie uniquement des notifications de transaction via Zero MQ lorsque les transactions sont envoyées et lorsqu'ils reçoivent une confirmation. Après cela, quel que soit le nombre de confirmations supplémentaires reçues, le nœud n'en informe pas notre application. Nous devons faire en sorte que notre application commence à écouter les notifications de blocage afin de résoudre ce problème. Nous allons commencer à le faire dans la prochaine vidéo. revoit. 41. 39 Receiving la partie 2 de la partie 2 de la compétence 2: Dans cette vidéo, nous allons faire en sorte que notre application commence à écouter les messages bloqués provenant du nœud Bitcoin. Ainsi, nous serons en mesure de mettre à jour correctement les confirmations de nos transactions dans l'environnement de test net. modifiera également le formatage des adresses et des soldes de transactions, car ils ne s' affichent plus correctement sur les tableaux. Passons donc au fichier bitcoin.com. Changeons cette clé en reg test. Pour commencer à écouter les messages bloqués, ajoutons la propriété Z MQ pub hash block ici. Sa valeur sera la même URL que dans la propriété ci-dessus. Alors, collons-le ici. Cette configuration obligera les nœuds à envoyer le bloc de hachage à notre application une fois qu'elle aura détecté un nouveau bloc, étendant ainsi la blockchain. Après cela, le code sera créé enverra une liste de requêtes non dépensées au nœud contenant toutes les adresses de portefeuille actuelles. En réponse, vous recevrez une liste des UTXO mis à jour qui seront analysées et utilisées pour mettre à jour nos robes rouges et nos tables de transactions. Sauvegardons le fichier bitcoin.com. Passons maintenant à la classe de tâches node. Dupliquons cette ligne. Changeons la chaîne en bloc de hachage. De cette façon, nous commencerons à recevoir des messages de hachage en provenance du nœud. Maintenant, dans cette instruction if, ajoutons le code suivant. Si le sujet est égal à zéro, ou si la liste contenant ces sujets ne contient pas le sujet reçu. Nous passerons ensuite à la prochaine itération de la boucle while. Maintenant, ajoutons une instruction switch ici. Si la variable topic est égale à ra t x. Ensuite, nous exécutons le code pour analyser et traiter la transaction reçue. Déplaçons la ligne qui publie l' événement reçu par la transaction vers cet emplacement. De cette façon, nous pouvons supprimer cette instruction continue redondante si la variable topic est égale à un bloc de hachage. Nous utiliserons ensuite l'éditeur d'événements de l'application pour publier un nouveau bloc d'événements reçus. Créons cet événement dans le package BYU w dot no doubt events. Créons maintenant un écouteur pour cet événement dans le package BYOD w point, point listeners. Ajoutons-y une annotation de composant. Faisons en sorte qu'il implémente l'interface d' écoute de l'application, en transmettant l' événement reçu par le bloc comme paramètre de type. Mettons en œuvre sa méthode. D'abord. Nous allons obtenir toutes les adresses de portefeuille actuelles à l'aide cette méthode et les stocker dans la variable addresses. Injectons le portefeuille actuel dans cette classe. Ensuite, l'utilisation d'une instruction if permet de vérifier si la variable d'adresses est vide. Si ce n'est pas le cas, nous utiliserons le service de mise à jour utxOS pour mettre à jour nos adresses et transactions. Injectons-le dans cette classe. Nous appellerons la méthode de mise à jour dessus, en transmettant l'adresse est variable et le nom du portefeuille actuel comme paramètres. Passons maintenant à la transaction reçue auditeur optimisera notre code. N'oubliez pas qu'après avoir reçu une confirmation dans l'environnement de test net et toutes les confirmations dans l'environnement de test reg, le nœud envoie un message de transaction à notre application via zéro MQ. Étant donné qu'à partir de maintenant, notre écouteur bloqué mettra à jour toutes les adresses de portefeuille actuelles lorsqu'il recevra des confirmations, il n'est pas logique de mettre à jour le tableau des adresses et des transactions dans la transaction a reçu la classe d'écoute après avoir reçu des messages de transaction répétés. Par conséquent, nous allons modifier cette classe pour traiter uniquement les transactions si le portefeuille actuel ne les contient pas. Ajoutons donc cette déclaration if. Si les identifiants de transaction actuels du portefeuille contiennent l'identifiant de transaction reçu, nous vous renvoyons simplement. Créons cette méthode. Il renverra une liste de chaînes, et il renverra les lignes de transaction, la méthode Get Transaction IDs. Créons cette méthode. Ici. Nous allons renvoyer le code suivant à partir d'un flux de la liste des rôles de transaction. Nous appellerons la méthode map en transmettant une référence à la méthode getID de la ligne de transaction. Ensuite, nous convertirons le résultat en liste et le renverrons à l'auditeur ayant reçu la transaction. Nous devons encapsuler ce code dans un bloc try catch car la méthode d'identification de la transaction renvoie une exception cochée dans le bloc catch utilisera un enregistreur pour imprimer un message d'avertissement. Injectons l'enregistreur dans cette classe, comme nous l'avons fait dans la classe de tâches node. Ajoutons également une déclaration de retour au bloc catch. Maintenant, résolvons le problème de formatage équilibré des lignes d'adresses. Au lieu d'utiliser la méthode de double classe à deux chaînes, nous utiliserons le format Bitcoin ou la méthode de format en passant le solde d'adresses comme paramètre. Créons cette classe dans le package utils. Maintenant, créons la méthode de mise en forme. Ici, nous allons instancier un nouvel objet de symboles au format décimal en passant la route locale à son constructeur. Ensuite, nous définirons le point comme séparateur décimal et la virgule comme séparateur de regroupement. Ensuite, nous instancierons un nouvel objet au format décimal car son paramètre constructeur transmettra ce modèle. Et les symboles sont variables. Ensuite, nous définirons le format ou le regroupement utilisé comme faux. Ensuite, nous définirons ses fractions minimales à huit. Et c'est une fraction maximale de 282 chiffres. Enfin, nous appellerons la méthode de format sur le formateur, en passant le numéro reçu comme paramètre et en le renvoyant. L'utilisation de cette méthode permet de formater n'importe quel nombre de passes avec un chiffre décimal et sans séparateurs de groupe. Ce type de formatage est utile car un bitcoin peut comporter au maximum huit fractions de chiffres. Cette mise en forme facilite également la visualisation du nombre de Satoshi qu'un équilibre contient. Passons maintenant à la classe de lignes de transactions. Utilisons le formateur Bitcoin ici pour formater la balance UTXO selon la méthode frame. Maintenant, ajustons nos tests pour couvrir cette nouvelle mise en forme de balance. Passons à la classe de test de l'interface graphique la méthode send Bitcoin in weight, changeons le deuxième type de paramètre pour doubler et ajustons sa valeur par défaut en conséquence. Ajoutons également ce paramètre de montant facultatif avec une valeur par défaut de 1,0. Maintenant, substituons ce paramètre la variable de montant. Et ici, encapsulons la variable de montant total attendu dans le format Bitcoin ou la méthode de format. Passons maintenant au test de réception de Bitcoin. Modifions ceci et appelons la méthode Bitcoin et attendons pour envoyer 0,00 001 Bitcoin. Nous pouvons donc tester le nouveau formatage lorsque notre portefeuille reçoit des fractions de Bitcoin. Nous allons maintenant vérifier chaque utilisation de cette méthode et modifier leur paramétrage du paramètre de montant total attendu pour transmettre un double au lieu d'une chaîne. Ajoutons maintenant ces vérifications nulles aux propriétés de la vue tabulaire dans cette méthode pour éviter les exceptions de pointeur nul. Maintenant, exécutons notre nœud et exécutons tous les tests du projet. Super, les tests sont réussis. Maintenant, exécutons notre application sur l' environnement du réseau de test. Pour ce faire, ajustons notre fichier bitcoin.com. Maintenant, redémarrons notre nœud. Au bout de quelques minutes, ma note est complètement coulée. Maintenant, exécutons notre application dans l' environnement du réseau de test en utilisant notre configuration d' exécution précédemment modifiée. Créons un nouveau portefeuille. Maintenant, copions notre adresse et utilisons un robinet à filet d'essai pour recevoir celui de Satoshi, comme nous l'avons fait dans une vidéo précédente. D'accord, nos portefeuilles ont réussi à identifier la transaction et elle est équilibrée comme prévu. Maintenant, mangeons un sandwich et laissons notre portefeuille fonctionner pendant un moment. Après quelques minutes , la transaction a déjà reçu quatre confirmations. Génial. 42. 40 Total équilibre de la partie 1 de l'ensemble de l'ensemble: Dans cette vidéo, nous allons commencer à développer la fonctionnalité d' équilibre total. En gros, il s'agira d'un texte au-dessus l'onglet Transactions et adresses indiquant que le solde du portefeuille actuellement chargé affichera le solde confirmé, le solde non confirmé et le solde total. Le solde confirmé indiquera le montant de tous les UTXO confirmés. Le solde non confirmé est la somme de tous les UTXO non confirmés. Le solde total sera la somme des soldes non confirmés et confirmés. Passons donc au point FXML du terrain de jeu pour esquisser quelque chose. Après la première fermeture du volet d'onglets. Ajoutons cette étiquette d'étiquette. Maintenant, ajoutons cette balise de marge à points VBox. À l'intérieur. Ajoutez cette balise insets. Nous allons ajouter quelques propriétés de marge ici. Réglons la marge inférieure à 10,0, la marge gauche à 10,0 et la marge supérieure à zéro. Maintenant, à des fins de test, définissons la propriété text de cette étiquette comme test. Voyons à quoi cela ressemble dans le Scene Builder. D'accord, nous voyons que les textes équilibrés seront situés ici. Supprimons cette propriété de texte. Créons un nouveau fichier FXML appelé solde de soulignement total. Enlevons cette plaque standard. Maintenant, copions tout le contenu et la balise d'étiquette que nous venons de créer dans le terrain de jeu. Et collez-le ici. Copions également ces deux lignes d'importation et les collons dans le FXML à points équilibrés avec un trait de soulignement total. Remplaçons maintenant les balises label par la balise racine FX deux-points. Il aura un identifiant FX indiquant le solde total et un type de point Java FX, point de contrôle. Incluons également cette propriété XML et S. Maintenant, dans la fenêtre principale, ajoutons la balise Total Balance Controller après le premier onglet de fermeture. Créons maintenant ce contrôleur dans le package des contrôleurs. Et nous allons le réimporter ici dans la manette. Faisons en sorte d'étendre la classe d'étiquettes et d'y ajouter l'annotation du composant. Maintenant, copions ce constructeur et collez-le ici, en le modifiant en conséquence. La valeur de la ressource FXML sera l'emplacement du FXML à points équilibrés total. Injectons également le portefeuille actuel dans cette classe. Maintenant, dans l'écouteur démarré dans l'interface graphique, ajoutons la classe totale du contrôleur d' équilibre à l'ensemble de composants personnalisés. Dans le contrôleur de balance totale. Ajoutons la méthode initialisée. Nous utiliserons la méthode setText héritée pour définir le texte de l'étiquette de manière dynamique. Configurons-le pour qu'il soit testé à des fins de test pour le moment. Maintenant, créons le test d'équilibre total dans le package GUI. Cela étendra la classe de test de l'interface graphique. Copions ces deux méthodes et collons-les dans le nouveau test. Renommons cette méthode, deux devrait calculer le solde total. Maintenant, faisons quelques ajustements au corps. Le nom du portefeuille créé sera validé par mon test. Supprimons cette ligne car nous n'en aurons pas besoin. Supprimons également ces lignes. Ce code permet d' obtenir le texte présent dans étiquette du solde total et stocker dans la variable de texte de l' étiquette. Ensuite, block vérifiera si la variable de texte de l'étiquette est égale à la phrase suivante. Après réception de la transaction, nous nous attendons à ce que le contenu de l'étiquette indique que nos soldes totaux et non confirmés sont d'un Bitcoin. Nous nous attendons à ce que le solde confirmé soit nul puisque notre transaction ne sera pas incluse dans un bloc et un esprit lors du test. Avant d'exécuter notre nœud, assurons-nous que notre environnement de configuration Bitcoin point est configuré pour le test reg. Maintenant, exécutons notre nœud. Et lançons ce test. Cela a échoué comme prévu car l'étiquette de balance totale contient le test de chaîne au lieu de ce que nous voulions. Dans la vidéo suivante, nous allons implémenter cette fonctionnalité et faire en sorte que ce test soit réussi. revoit. 43. 41 Total équilibre de la partie 2 de l'ensemble de l'ensemble: Dans cette vidéo, nous allons terminer la mise en œuvre de la fonctionnalité d' équilibre total. Passons donc à la mise à jour du service UtxOS. Dans la méthode de mise à jour, un nouvel appel de méthode sera ajouté pour mettre à jour le solde du portefeuille. Pour cela, nous appellerons la méthode de mise à jour associée à la mise à jour que le service actuel du solde du portefeuille créera. Injectons ce service dans cette classe. Créons cette classe dans le package GUI point services. Et finissons de l'injecter ici. Maintenant, créons sa méthode de mise à jour. Ici, nous allons d'abord calculer le solde non confirmé et le stocker dans la variable de solde non confirmé. Pour cela, nous devrons injecter le portefeuille actuel dans cette classe. Ensuite, nous obtiendrons ses lignes de transactions observables et les convertirons en flux. Ensuite, nous utiliserons la méthode de filtrage sur le résultat pour exclure les lignes de transaction dont les confirmations sont différentes de zéro. Nous utiliserons ensuite la méthode map pour convertir le flux obtenu en un flux de soldes de lignes de transactions. Nous utiliserons la méthode parse double pour convertir chaque chaîne équilibrée en une chaîne double. Nous allons maintenant utiliser la méthode réduite, en lui transmettant la méthode de la double somme, à chaque solde obtenu dans le flux. Enfin, nous utiliserons la méthode or else en lui transmettant 0.0. Par conséquent, si le flux obtenu est vide, la variable équilibrée non confirmée sera mise à zéro. Maintenant, dupliquons ce bloc de code. Modifions-le pour calculer le solde confirmé et le stocker dans la variable équilibrée confirmée. Il suffit de remplacer le signe égal et la méthode de filtrage par ce signe supérieur à. Avec cette simple modification, nous obtiendrons la somme des soldes de toutes les transactions avec au moins une conformation. Enfin, nous appellerons la méthode des soldes fixes sur le portefeuille actuel, en passant le solde non confirmé et le solde confirmé comme paramètres. Étant donné que ce code modifiera l'interface utilisateur, encapsulons-le dans un appel à la méthode run later de la plateforme. Et créons la méthode set balances dans la classe de portefeuille actuelle. Pour cela, ajoutons le champ des soldes à cette classe. Son type sera la classe de balances que nous allons créer. Créons-le dans le package observables. Et instancions-le ici. Ici, nous appellerons cette méthode des soldes fixes dans le champ des soldes, en utilisant les soldes non confirmés et non confirmés comme paramètres. Créons cette méthode. D'abord. Ajoutons des champs privés à cette classe. Nous allons ajouter le champ équilibré non confirmé de la propriété de type string. Instancions-le ici avec une nouvelle propriété de chaîne simple. Dupliquons cette ligne deux fois. Changeons les noms de ces champs pour confirmer le solde et le solde total. Maintenant, dans la méthode set balances, j'appellerai la méthode set sur les propriétés injectées pour définir leurs valeurs. Utilisera le format Bitcoin ou la méthode de formatage pour formater les soldes au format souhaité. La somme des soldes non confirmés et confirmés sera transférée au solde total. Nous allons maintenant créer des getters pour ces champs. Créons également la méthode claire. Cette méthode mettra le solde de chaque propriété à zéro. Nous appellerons cette méthode après avoir créé un portefeuille pour effacer les valeurs du portefeuille précédemment chargé. Maintenant, dans le portefeuille actuel, créons la méthode des bons soldes. Cela renverra le champ des soldes. Et créons la méthode des balances claires. Cela appellera la méthode Balances Clear. Dans le service de mise à jour du portefeuille actuel, qui est appelé après la création d' un portefeuille, appelons ici la méthode clear balances du portefeuille actuel. Passons maintenant au contrôleur de balance totale. Supprimons cette ligne. Nous obtiendrons la propriété équilibrée non confirmée à partir des soldes actuels du portefeuille. Nous appellerons la méthode Ad Listener à ce sujet. Nous allons passer un lambda comme paramètre, où, dans le corps, nous appellerons la méthode de texte de mise à jour. Créons cette méthode. y appellerons la méthode setText, et nous passerons un appel de méthode de format de chaîne en tant que paramètre. Le premier paramètre de la méthode de format sera cette phrase. Chaque signe de pourcentage suivi de la lettre S sera interpolé par les paramètres suivants de cet appel de méthode. Les paramètres suivants seront le solde total actuel du portefeuille. Le solde du portefeuille actuel a été confirmé. Et enfin, le solde non confirmé du portefeuille actuel. Maintenant, dans la méthode initialisée, dupliquons cette ligne deux fois. Nous ajouterons le même auditeur à la propriété d'équilibre confirmée et à la propriété d'équilibre total. Modifions donc ces lignes en conséquence. Refactorisons cette chaîne, en l' incluant dans une constante de cette classe. Disons que c'est du texte équilibré et rendons-le privé. Maintenant, apportons une petite modification au service de mise à jour UtxOS. Notez que nous avons déjà une annotation asynchrone sur la méthode de mise à jour. L'ajout de la même annotation dans la méthode appelée it est donc redondant. Par conséquent, supprimons-les. Tout d'abord dans le service de mise à jour des adresses de portefeuille actuelles. Ensuite, dans la mise à jour du service de transaction Wallet actuel. Une autre chose que j'ai remarquée, c'est que nous devons encapsuler l'appel à la méthode des lignes de transaction publicitaire et un appel de méthode d'apprentissage ultérieur de la plateforme , car cela modifie des éléments de l'interface utilisateur. Passons maintenant au test d'équilibre total. Assurons-nous que notre nœud Bitcoin fonctionne. Et organisons nos groupes de test . Le test a échoué. Voyons pourquoi. Il s'avère que j'ai oublié d'ajouter l'annotation des services au service de mise à jour du solde actuel du portefeuille. Réglons ça. Et recommençons notre test. Super, le test est passé. Dans la vidéo suivante, nous ajouterons d'autres tests équilibrés à nos autres tests pour nous assurer que tout fonctionne comme prévu. 44. 42 Total balance partie 3 skillshare 2: Dans cette vidéo, nous allons implémenter d'autres tests pour assurer que la fonction d'équilibrage fonctionne correctement. Copions donc cette ligne et le test d'équilibre total Nous allons d'abord ajouter quelques assertions de test concernant la balance et le test du bloc de réception. Collons donc la ligne ici. Copions également cette ligne et collez-la dans le bloc then de ce test. Dans ce test, nous nous attendons à ce que le solde total soit égal à un Bitcoin. Ajustons donc cette phrase en conséquence. Nous nous attendons également à ce que tout le solde soit confirmé. Faisons de même pour cet autre test. Dans ce cas, nous nous attendons à ce que le solde total soit égal à deux bitcoins, également confirmé. Nous allons maintenant vérifier si notre nœud fonctionne et lancer le test. Les tests sont réussis. Ajoutons maintenant quelques assertions d' équilibre à la classe de test Bitcoin réceptrice. Dans ces tests, on ne s'attend qu'à des soldes non confirmés. Faisons ces tests. Super, les tests sont réussis. 45. 43 Envoyer des bitcoin partie 1 skillshare 2: D'accord, jusqu'à présent, avec notre portefeuille, nous pouvons recevoir des Bitcoins en utilisant des adresses générées. Nous pouvons également inspecter le solde reçu par chaque adresse et vérifier les informations relatives à nos transactions. Nous allons maintenant commencer à mettre en œuvre la possibilité de dépenser ces bitcoins en envoyant transactions à d'autres adresses que nous souhaitons. Commençons donc à créer un test appelé send Bitcoin test dans le package de test de l'interface graphique. Cela étendra la classe de test de l'interface graphique. Nous allons ajouter la même méthode de configuration. Nous avons ajouté deux autres tests, en appelant le portefeuille de chargement et en ajoutant une méthode équilibrée. Créons un test appelé devrait envoyer du Bitcoin. Maintenant, dans le vent, créera un nouveau portefeuille et enverra un Bitcoin à sa première adresse. Le code suivant sera très similaire au code des autres tests. Après avoir envoyé un Bitcoin à l'adresse de notre portefeuille, nous cliquons sur l'onglet Envoyer. Ensuite, nous cliquerons sur le champ du montant pour définir le montant que nous voulons envoyer. Envoyons 0,5 Bitcoin, soit la moitié de notre solde à ce stade. Maintenant, nous allons cliquer sur le champ adresse à envoyer. Dans ce test, vous enverrez des bitcoins à une autre adresse. Utilisons donc le client Node get new address pour obtenir une nouvelle adresse de nœud. Ensuite, nous écrirons l'adresse obtenue sur l'entrée sur laquelle vous avez cliqué. Maintenant, nous allons cliquer sur le bouton Envoyer. Ensuite, nous nous attendons à ce qu' un modal s'ouvre avec des informations sur la transaction et un bouton OK pour confirmer et envoyer la transaction. Appelons donc la méthode click on en passant « okay » comme paramètre. Nous allons maintenant cliquer sur l'onglet Transactions. Et avec le code suivant, nous vérifierons si le tableau des transactions comporte deux lignes, l'une pour la transaction réceptrice et l'autre pour la transaction que nous venons d'envoyer. Passons maintenant au point FXML du terrain pour concevoir notre onglet Envoyer. Dupliquons le code de l'onglet Recevoir. Et changeons le texte à envoyer. Supprimons ces lignes pour commencer par un nouvel onglet sur lequel travailler. Passons maintenant au Scene Builder. Cliquons sur l'onglet Envoyer. Cliquons sur le corps de l'onglet pour sélectionner le composant du volet quadrillé qu'il contient. Réglons sa hauteur préférée sur 130, et sa largeur préférée sur 600. Ajoutons maintenant un contrôle d'étiquette au volet de la grille dans l'onglet Envoyer. Mettons dix sur ses marges supérieure, droite et gauche. Changeons son nom pour répondre à cette fin. Maintenant, ajoutons un champ de texte à ce volet de grille. Remplaçons l'index de colonne de son volet de grille par un. Cela ne nous permet pas de le faire. Tout d'abord, nous devons ajouter une colonne dans le volet de la grille. Cliquez ici avec le bouton droit de la souris et ajoutons deux lignes et une colonne au volet de la grille. Nous pouvons maintenant remplacer l'index de colonne TextField par un. Mettons dix sur ses marges supérieure, droite et gauche. Changeons sa largeur préférée à 350. Changeons également cette largeur préférée de Collins à 600. Ajoutons une autre étiquette au volet de la grille. Remplaçons son index de ligne par un, et définissons dix sur ses marges supérieure, droite et gauche. Modifions également son texte en montant à envoyer. Ajoutons un autre champ de texte au volet de la grille. Et définissons son index de ligne sur un et son index de colonne sur un. Réglons sa hauteur préférée sur 26. Et la largeur est préférable à 100. Mettons dix sur ses marges supérieure, droite et gauche. Nous allons maintenant encapsuler le dernier champ de texte inséré dans une zone H. Ajoutons donc une boîte H au volet de la grille. Et ses index de ligne et de colonne ne font qu'un. Déplaçons ce champ de texte vers la zone H. Fixons également dix sur les huit dollars en haut, droite et à gauche. Ajoutons maintenant une étiquette à la case H. Réglons également ces marges sur dix et changeons son texte en BTC. En fait, remettons ces marges à zéro. Nous allons plutôt en mettre cinq sur ces rembourrages. Maintenant, ajoutons un bouton OK au volet de la grille. Et définissons son indice de ligne sur deux. Fixons également ces marges à dix. Et définissons son texte à envoyer. Copions maintenant tout le contenu de l'onglet Envoyer que nous avons créé dans le FXML Playground Point. Créons l'onglet Envoyer le trait de soulignement FXML dans le package FXML. Et collons le contenu copié dans ce fichier. Remplaçons la balise tab par la racine du deux-points éthique. Définissons son type avec effets Java, points vus, contrôle par points, onglet à points. Importons maintenant toutes les balises restantes. Oups, nous avons mal défini la propriété type sur label. Réglons le problème. Maintenant, définissons l'identifiant FX de ces balises. Tout d'abord, définissons cet ID de fax comme onglet d'envoi. Cet identifiant FX à l'adresse, pour envoyer cet identifiant FX au montant à envoyer, cet identifiant FX à envoyer. Passons maintenant au point FXML de la fenêtre de soulignement principale. Dupliquons cette ligne et changeons cette balise pour envoyer le contrôleur de tabulation. Créons ce contrôleur dans le package Controllers. Et nous allons l'importer ici. Cela étendra la classe d'onglets et ajoutera l' annotation du composant à celle-ci. Copions le constructeur de l'onglet Receive et collez-le ici, en l' ajustant en conséquence. Injectons le portefeuille actuel dans cette classe. Ajoutons maintenant la classe de contrôleur Send tab à l'ensemble des composants personnalisés du module d'écoute lancé par l'interface graphique. Et changeons la valeur de ce paramètre pour envoyer un point de soulignement sous forme de point FXML. Maintenant, assurons-nous que notre nœud Bitcoin fonctionne. Et lançons notre test d' envoi de Bitcoin. Comme prévu, le test a échoué. Dans les prochaines vidéos, nous continuerons à implémenter cette fonctionnalité. C, ouais. 46. 44 transactions Bitcoin partie 2 skillshare 2: Dans cette vidéo, nous en apprendrons davantage sur les transactions en Bitcoin. Plus précisément, nous en apprendrons davantage sur taille des transactions et les frais de transaction. Ces connaissances seront nécessaires plus tard lorsque nous commencerons à établir des transactions pour transférer des Bitcoins de nos portefeuilles vers d'autres adresses. Lors de la présentation précédente, nous avons appris que les frais de transaction sont égaux à la somme des Bitcoins en entrées moins la somme des Bitcoins et des sorties d'une transaction. N'oubliez pas que les frais de transaction sont le prix que vous payez pour qu'un mineur choisisse votre transaction parmi les informations incluses dans un bloc et la mine. Plus les frais de transaction sont élevés, plus la transaction sera rapidement incluse dans un bloc. Avec des frais de transaction minimes, votre transaction restera gravée dans la mémoire pendant plus longtemps. Il est donc important de choisir les bons frais pour vous assurer que votre transaction soit confirmée dans un délai raisonnable sans la payer trop cher. Les frais de transaction varient beaucoup avec le temps. Sa valeur suit la logique de l'offre et de la demande. Plus le nombre de transactions envoyées est élevé, plus les frais de transaction ont tendance à être élevés. Et plus le nombre de mineurs est élevé, plus les frais de transaction ont tendance à être faibles. Ce graphique montre les frais de transaction moyens en dollars au cours des deux dernières années. Notez qu'au cours de cette période, les frais de transaction variaient de quelques dollars à plus de 60 dollars par transaction. Alors, comment calculons-nous les frais de transaction ? Étant donné que les blocs de transactions ont espace limité mais une demande illimitée, il est logique que les frais soient calculés en fonction de la taille de la transaction. Il existe différentes manières d'obtenir le taux de frais de transaction recommandé. Par exemple, vous pouvez utiliser des sites Web tels que Bitcoin Fees, earned.com. Nous pouvons voir ici le nombre de transactions soumises à un taux de frais au cours des dernières 24 heures. Dans la colonne de droite, nous voyons une estimation du temps qu'il faudrait pour confirmer une transaction avec ces frais, par blocs et minutes. Si vous faites défiler la page vers le bas, obtiendrez un taux de redevance recommandé à utiliser. Cela garantit presque que votre transaction sera confirmée dans le bloc suivant. Men pull point space est un autre site qui, avec des graphismes intéressants, indiquant le taux de frais moyen pour chaque bloc, indique également le taux de frais recommandé à utiliser pour les transactions de faible, moyenne et haute priorité. Plus leur priorité est élevée, plus la transaction devrait être confirmée rapidement. Nous pouvons également utiliser notre méthode d' estimation intelligente du Bitcoin Core Note RPC . Selon sa documentation, il prend comme paramètre un objectif de confirmation, c' est-à-dire le nombre de blocs que nous prévoyons de négocier avec le taux de frais de retour pour être confirmé. Un paramètre optionnel est également nécessaire pour définir le mode d'estimation, qui peut être indéfini, économique ou prudent. Le taux de commission est indiqué en Bitcoin par kilo d'octet virtuel ou KV. Ces exemples montrent que les taux de frais recommandés peuvent varier considérablement d'un outil à l'autre. Pour plus de simplicité, dans notre portefeuille, nous utiliserons l'appel RPC du smartphone Bitcoin Core, car cela ne nous obligera pas à interroger des outils externes moyennant des frais. Nous pouvons donc calculer les frais de transaction en multipliant la taille de la transaction en v octets par le taux de commission dans Satoshi is private bit. Mais attendez, qu'est-ce qu' un octet virtuel ? Pour calculer les frais de transaction, il faut d'abord comprendre deux concepts importants taille virtuelle et l'octet virtuel. La taille virtuelle, ou taille V, est la taille de la transaction en bits virtuels ou v octets. Ce sont des concepts inventés pour tenir compte la petite taille des transactions en Segway. La taille V est calculée de manière rétrocompatible afin de prédéfinir les tailles de transaction égales ou de prédéfinir les tailles de transaction V. Pour les transactions Segway, la taille V est égale à la taille de la partie non témoin d' une transaction plus sa taille témoin divisée par quatre. Le témoin est un champ présent uniquement dans les transactions en Segway. Il contient les champs qui, lors transactions pré-segmentées, se trouvaient dans le champ ScriptSig de chaque entrée. Cette méthode différente de calcul de la taille des transactions se traduit tailles de transaction V plus petites pour les transactions Segway par rapport aux transactions traditionnelles. Par exemple, pour les transactions avec une entrée et une sortie, les transactions Segway ont une taille de 110 V octets, tandis que les transactions traditionnelles ont une taille de 192 octets de V. Pour les transactions avec une entrée et deux sorties, les transactions Segway ont une taille de 141 octets, tandis que les transactions traditionnelles ont une taille de 226 octets de V. Enfin, pour les transactions comportant deux entrées dans des sorties, les transactions Segway ont une taille de 209 V octets, tandis que les transactions traditionnelles ont une taille de 374 octets. Supposons donc que nous voulions calculer les frais pour une transaction Segue avec une entrée et deux sorties avec un taux de commission de 19. Satoshi est au courant. Pour ce faire, nous multiplierions la taille v de sa transaction, qui est de 141 octets de v, par le taux de commission, qui est de 19 Satoshi par v octets. Cela rapporterait 2 679 Satoshi en frais pour cette transaction. Donc, en résumé, pour construire une transaction, nous aurions besoin de créer les éléments suivants. Pour une sortie, nous aurions besoin d'une adresse et d'un montant à envoyer à cette adresse. Si une modification est nécessaire, comme c'est le cas pour la plupart des transactions, nous devons créer une deuxième sortie contenant une adresse de modification et un montant. Nous aurions également besoin d'un nombre variable d'entrées dont le montant en bitcoins doit être supérieur au montant à envoyer plus les frais de transaction. N'oubliez pas qu'une entrée fera référence à une sortie non dépensée d'une transaction précédente envoyée à l'une de vos adresses. Une modification sera nécessaire si la somme des montants saisis est supérieure au montant à envoyer plus les frais de transaction. Si, par hasard ou par dessein, la somme des montants saisis est égale au montant à envoyer plus les frais de transaction la transaction n' aura pas de résultat de modification. Et l'expéditeur bénéficiera de payer moins de frais de transaction pour une transaction ne comportant qu'un seul résultat. Encore une fois, pour calculer les frais de transaction il faudra utiliser le taux de commission en Satoshi par v octets. Nous obtiendrons cette valeur en utilisant l'API gRPC estimée pour smartphone de Bitcoin Core et en convertissant le résultat en par V de Satoshi. Nous aurons également besoin de la taille de la transaction en v octets. Dans la vidéo suivante, nous implémenterons la note qui estime les frais intelligents, client et un service pour calculer le montant de la transaction. Plus tard, nous combinerons les deux pour calculer les frais de transaction. Tu vois, oui. 47. 45 Envoyer des bitcoin partie 2 skillshare 2: Dans cette vidéo, nous allons créer un calculateur de la taille des transactions et créer le client de nœud pour la méthode RPC d'estimation intelligente des nœuds Bitcoin. Dans le package api point services, créons la classe de calcul de la taille des transactions. Cette classe sera chargée de calculer la taille des transactions en fonction de leurs types et du nombre d'entrées et de sorties. Ces tailles seront utilisées ultérieurement pour calculer le montant des frais que nous devons inclure dans nos transactions. Ajoutons-y une annotation sur les services. Nous allons d'abord définir certaines constantes dans cette classe. Ces constantes contiendront les tailles de chaque partie d'une transaction. Comme nous travaillons uniquement avec transactions Segway pour le moment, ces constantes ne feront référence qu' à certaines parties des transactions Segway. Commençons donc par définir le montant des frais généraux de transaction. La surcharge est la partie de la transaction dont la taille ne change pas avec le nombre d'entrées ou de sorties. La première constante sera appelée inversion, ce qui fait partie de la surcharge. Il code la version de la transaction. Il a une taille de quatre octets. Ensuite, nous avons le nombre d'entrées qui, comme son nom l' indique, indique le nombre d' entrées dans la transaction. Il possède un nombre variable d'octets, mais pour un maximum de 252 entrées, sa taille est d'un octet. Ensuite, nous avons le champ de comptage en sortie, qui a la même taille et les mêmes règles que le nombre d'entrées. Comme son nom l'indique, il indique le nombre de sorties de la transaction. Ensuite, nous avons le champ N lots temporels, qui contient quatre octets. Ce champ est parfois utilisé pour coder le temps après lequel la transaction peut être effectuée. Ensuite, nous avons le marqueur et le drapeau Segway, qui ne sont présents que pour les transactions en Segway. Il a une taille de deux octets. Réglons maintenant les tailles des champs d'entrée, commençant par le point de sortie, qui a une taille de 36 octets. Le point est la combinaison de l' identifiant de transaction précédent et de l'indice de sortie. Il indique l'UTXO utilisé pour cette entrée. Ensuite, nous avons le champ de longueur ScriptSig, dont la taille maximale est de 252 octets, qui comporte un octet. Il indique la taille du ScriptSig pour l'entrée. Ensuite, nous avons le champ ScriptSig. Pour les transactions en Segway. Sa taille est nulle. N'oubliez pas que pour les entrées de segments, le contenu du ScriptSig est déplacé vers le champ témoin. Ajoutons maintenant le champ de séquence de fin. Il a une taille de quatre octets et est utilisé pour définir si la transaction est remplaçable au cas où l'expéditeur souhaiterait modifier ses frais. Ajoutons ensuite le champ de dénombrement des témoins pour un maximum de 250 aux objets témoins. Il a une taille d'un octet. Ensuite, nous avons le champ des éléments témoins, qui a une taille de 107 octets pour les entrées P2, WP k, h. Ce champ comprend la signature, qui peut avoir une taille de 71 ou 72 octets, et la clé publique, taille de 33 octets , 72 octets, est choisie comme taille pour les signatures, car nous préférons surestimer un peu la taille de la transaction. La valeur F0 calculée est donc garantie pour la transaction. Les deux octets restants qui codent la taille de la signature et de la clé publique. Expliquez la valeur constante de 107 de l'élément témoin. Réglons maintenant les constantes avec les tailles de sortie. La valeur n est la quantité de bitcoins envoyée dans cette sortie. Il a une taille de huit octets. Ensuite, nous avons la longueur de la clé de pub de script, qui a une taille d'un octet pour longueur maximale de 252 octets. Ensuite, nous avons la clé de pub du script, qui a une taille de 22 octets pendant une seconde. Quelles adresses ? Maintenant, avant de continuer à implémenter le calcul de la taille des transactions, créons le test du calculateur de taille de transaction dans le package de test de l'API. Cela étendra la classe de spécification. Ajoutons un champ de calcul de la taille des transactions dans cette classe. Et utilisons une méthode de configuration pour l'instancier. Maintenant, créons un nom de test qui devrait calculer la taille de la transaction pour les sorties et entrées de transaction P2, WP k, h. Dans le bloc unique, nous appellerons la méthode de calcul du service de calcul de la taille des transactions et enregistrerons le rendement dans la variable de résultat. En tant que paramètres, les entrées et les sorties seront transmises, que nous définirons dans le bloc where. Dans le bloc, vous vérifierez si le résultat est égal à la variable de taille attendue. Dans le bloc where, vous ajouterez les cas de test suivants. Pour les entrées et les sorties, les variables établiront des listes avec un nombre variable d'adresses. Comme pour l'instant, peu importe le type d'adresse, il suffira d'ajouter une lettre représentant chaque adresse. Les valeurs de taille attendues ici ont été précédemment calculées pour chaque combinaison d' entrées et de sorties et validées à l'aide de la CLI Bitcoin Core. Créons maintenant la méthode de calcul dans la classe de calculateur de taille de transaction. Il renverra un grand entier et recevra comme paramètres une liste d'adresses d' entrée et une liste d'adresses de sortie. Maintenant, calculons d'abord la taille des frais généraux. Elle est égale à la somme de ces constantes. N'oubliez pas que la valeur que nous voulons calculer ici est la taille V. Les éléments des transactions en Segway, tels que le Segway, le marqueur et le drapeau, doivent donc être divisés par quatre. Divisons donc cette constante par quatre. Calculons maintenant la taille d'entrée. Ce sera la somme de ces constantes. Calculons maintenant la taille de toutes les entrées en multipliant la variable d'entrée par le nombre d'adresses d'entrée. Calculons maintenant la taille des témoins en ajoutant le nombre de témoins et les constantes des éléments témoins. En tant que suite, quels éléments ? Divisons leur somme par quatre. La taille totale du témoin est égale à la variable témoin multipliée par la taille des adresses d'entrée. Calculons maintenant la taille de sortie. Il sera égal à la somme de ces constantes. La variable toutes sorties sera égale à la taille de la sortie multipliée par le nombre de sorties. Enfin, le résultat de la taille de la transaction sera égal au BigDecimal, certaines des valeurs précédemment calculées. Réglons également l' échelle du résultat à zéro avec le mode arrondi à moitié supérieur. Cela fera en sorte que le résultat ait zéro décimale arrondi à l'entier le plus proche. Si la valeur décimale du résultat est cinq, elle sera arrondie à l'entier ci-dessus. Maintenant, nous renvoyons le résultat converti en grand entier. Maintenant, nous allons exécuter le test du calculateur de taille de transaction. Super, le test est passé. Créons maintenant le client Node Estimate Smart Fee dans le package client Node Dot. Injectons le client du nœud dedans. Et créons la méthode des frais intelligents pour les estimations. Il renverra un nouveau nœud que l'objet FI créera, et il prendra un entier comme paramètre. Revenons maintenant à appel de la méthode de demande sur le client du nœud. Le nom de la méthode sera Estimations Smart Fee. Son deuxième paramètre sera un nouvel objet de référence de type paramétré. Son troisième sera une chaîne vide et son dernier paramètre, la variable blocks. Créons maintenant l'enregistrement du nœud V dans le package de nœuds à points du domaine. Ses champs comporteront un double tarif et une liste d'erreurs. Maintenant, dans le package api point services, créons une interface appelée estimate fee service. Ajoutons-y la méthode d'estimation. Cela renverra une grande décimale. Créons maintenant une implémentation de cette interface. Note des noms, estimation des frais de service dans le même package. Mettons en œuvre sa méthode. Cette classe sera utilisée ultérieurement pour estimer les frais à l'aide du client Node Estimates Smart Fee. Si nous voulons modifier la méthode d'estimation des frais ou ajouter d'autres options pour le faire ultérieurement, nous créons simplement une autre implémentation de l'interface de service d'estimation des frais. Tout d'abord, nous appellerons la méthode d'estimation sur smartphone à partir du client créé précédemment et stockée dans la variable node V. Injectons ce client dans cette classe et passons à cette méthode afin d' essayer d'obtenir un taux de frais qui confirmera notre transaction dans le bloc suivant. Si, pour une raison quelconque, le taux de remboursement s' avère égal à nul, nous vous rembourserons s' avère égal à nul, le taux de frais de remplacement. Injectons cette variable dans cette classe. L'injectera à partir des fichiers de propriétés. Ajoutons donc cette annotation de valeur avant celle-ci. Après l' instruction if, la grande valeur décimale du taux de commission sera renvoyée. Ajoutons maintenant la propriété de taux de repli Bitcoin Dot à tous les fichiers de propriétés du projet. Faisons en sorte qu'il soit égal à 0,0 002. 48. Sélection de pièces et de la poussière: Dans cette présentation, nous continuerons à expliquer les concepts importants pour comprendre les transactions Bitcoin et pour continuer à développer notre fonctionnalité de transaction par péché. Parlons donc de la sélection des pièces. La sélection des pièces est le processus de sélection des UTXO pour créer une transaction. La règle générale pour cette sélection est que la somme des montants en bitcoins d'UtxOS doit être supérieure à la quantité de sable plus les frais de transaction plus la modification si nécessaire. Il existe de nombreuses méthodes de sélection de pièces. Chacune présente des avantages et des inconvénients. L'algorithme que nous allons choisir pour notre portefeuille s'appelle tirage aléatoire unique. C'est probablement l'algorithme de sélection de pièces le plus simple et suffisamment bon pour nos besoins. Cet algorithme a été présenté pour la première fois dans un mémoire de master intitulé Évaluation des stratégies de sélection de pièces par Mark Earhart. Je vous recommande de lire cette thèse si vous souhaitez en savoir plus sur les stratégies de sélection des pièces. Cette méthode de sélection de pièces a été ajoutée à Bitcoin Core en septembre 2021 en tant que stratégie de sélection de pièces de rechange. Cela consiste à mélanger les dépenses ou les UTXO, puis à sélectionner les UTXO un par un jusqu'à ce que la somme des montants UTXO sélectionnés soit supérieure ou égale au montant à envoyer plus les frais de transaction plus le à modifier si nécessaire. Si le montant de la modification est inférieur à la limite de poussière, le résultat de la modification est supprimé de la transaction et son montant est ajouté aux frais de transaction. Mais attendez un instant, qu'est-ce que la poussière ? Une émission de poussière est une production dont le montant en bitcoins est inférieur au coût de sa dépense. L'exemple suivant montre à quel point émissions de poussière ne sont pas rentables. Supposons que vous ayez un UTXO contenant 50 Satoshi et que vous souhaitiez envoyer ces 50 Satoshi à un ami. Lors de la création de la transaction, vous découvrez que les frais de transaction requis pour l'envoyer sont égaux à 100 Satoshi. Par conséquent, cela n'a aucun sens pour vous de dépenser l'UTXO avec 50 Satoshi, car vous paierez plus de frais que le montant envoyé. De plus, votre ami n'aura aucun avantage à recevoir un UTXO contenant 50 Satoshi car il aurait le même problème si vous le dépensez. Cet exemple montre qu'il est préjudiciable au réseau Bitcoin de créer des émissions de poussière, car personne sur le réseau n'en profite. Par conséquent, la plupart des nœuds Bitcoin ne relient pas les transactions contenant de la poussière. Cela permet de protéger le réseau contre les attaques de poussière. Une attaque à la poussière consiste à envoyer de manière malveillante de la poussière sur des adresses de portefeuille pour suivre leurs transactions. Cette attaque est illustrée dans cet exemple. Supposons que l' agence gouvernementale envoie la poussière à l'adresse X qui appartient à la personne. Pourquoi ? Lorsque le portefeuille électronique crée naïvement une transaction, il inclut la sortie de poussière et cinq autres comme entrées. Maintenant, l'agence gouvernementale sait pourquoi cinq adresses précédentes et toutes leurs transactions précédentes. De plus, le gouvernement connaît désormais le changement d'adresse de cette transaction et conclut d'autres transactions avec lui. Mais quels sont les critères permettant de considérer un produit comme de la poussière ? La limite de poussière est utilisée à cet effet. Toute sortie dont la quantité de bitcoins est inférieure à la limite de poussière est considérée comme de la poussière. Bitcoin Core utilise la formule suivante pour calculer la limite de poussière. La limite de poussière en Satoshi de la sortie d'une transaction est égale à la taille de la sortie de la transaction plus la taille d'entrée nécessaire pour la dépenser, à la fois en v octets, multipliée par la feuille industrielle en KV octets divisés par 1 000. Le résultat représente le coût de sortie de la transaction auquel le montant d'une transaction en bitcoins doit être égal ou supérieur pour ne pas être considéré comme de la poussière. Les frais de relais de poussière sont une propriété de configuration du nœud Bitcoin. Il s'agit des frais de transaction utilisés pour calculer la limite de poussière. Les frais de relais de poussière par défaut sont fixés à 3 000 Satoshi par KV octets ou trois Satoshi par bit V. Cela rend la limite de poussière par défaut pour les sorties Ségue égale à 294. De Satoshi. La limite de poussière par défaut pour les sorties non segmentées doit être égale à 546 Satoshi. Pour plus de détails sur le calcul de la limite de poussière, ce lien du code Bitcoin Core contient un commentaire expliquant comment la limite de poussière est calculée. Résumons maintenant les étapes générales de l'algorithme de tirage aléatoire unique. La première étape consiste à mélanger tous les porte-monnaie UTXO dans une liste. Ensuite, pour chaque UTXO disponible dans la liste remaniée, ajoutez cet UTXO à la liste des UTXO sélectionnés. Calculez l'objectif ajusté, qui est égal à la quantité de sable plus les frais de transaction plus la modification si nécessaire. Si le montant total de Bitcoin dans la liste UTXO sélectionnée est supérieur ou égal à la cible ajustée. Arrête. Enfin, utilisez les UTXO sélectionnés comme entrées de la transaction souhaitée. Quelques points d'attention concernant cet algorithme cibles ajustées avec et sans modification du résultat doivent être calculées pour meilleure précision, car les frais de transaction diffèrent selon les transactions. avec les sorties 1.2, si le changement généré se situe entre zéro et la limite de poussière, nous arrêtons l'itération car nous n'inclurons aucune modification à la transaction et n'avons donc pas besoin de plus d'UTXO. Cela est nécessaire pour ne pas générer de poussière lors du changement accidentel. L'inconvénient de l'algorithme de tirage aléatoire unique apparaît dans certains cas pathologiques, par exemple lorsque vous avez un seul gros UTXO et un grand nombre de petits UTXO. Une transaction comportant un grand nombre d' entrées et des frais de transaction élevés peut être créée au lieu d'utiliser le gros UTXO pour éviter d' avoir besoin de nombreuses entrées. ce cas, une approche différente est recommandée pour construire une transaction. Par exemple, choisissez manuellement les UTXO qui feront partie de certaines transactions spécifiques. Dans la vidéo suivante, nous allons implémenter un calculateur de poussière et l' algorithme de tirage aléatoire unique, C, oui. 49. 47 Envoyer des bitcoin partie 3 skillshare 2: Dans cette vidéo, nous allons commencer à implémenter un calculateur de poussière et l'algorithme de tirage aléatoire unique. Mais d'abord, refactorisons le record UTXO. Puisque nous allons faire de nombreux calculs avec le champ de montant UTXO. Et il vaut mieux faire les calculs avec de grandes décimales plutôt que des doubles, cela changera le type de montant deux grandes décimales. Nous devons maintenant refactoriser toutes les utilisations du champ montant dans le projet. Alors allons-y. Changeons le format ou le paramètre de format Bitcoin en BigDecimal et ajustons ce paramètre en conséquence. Faisons de même pour toutes les méthodes que l'IDE a signalées comme des erreurs dans le projet. Ici, nous allons ajouter de grandes décimales en utilisant la méthode add. Et passons la grande valeur décimale zéro au lieu de la primitive zéro à ces appels de méthode. Maintenant, nous devons changer le type de ce champ équilibré et tous ses usages. Refactorisons cette méthode pour obtenir la somme en utilisant de grandes valeurs décimales. Ajustons également ce code pour faire la même chose, mais avec de grandes valeurs décimales. OK, le refactoring est terminé. Maintenant dans le package api point services. Créons la classe de calcul de la poussière. Ajoutons-y l' annotation du service. Créons-y cette méthode de traitement de la poussière. Comme son nom l'indique, elle renverra true si une quantité est considérée comme fausse, sinon, elle renverra un booléen et prendra un grand entier comme paramètre représentant la quantité en De Satoshi. Cette méthode permet d'évaluer si le montant en Satoshi d'une production est inférieur au coût de sa dépense. Le coût des dépenses est égal à la taille en V de la sortie plus la taille en V de l'entrée nécessaire pour la dépenser, ce qui stockera à cette constante le nombre de pieds du relais de poussière en pieds de Satoshi par kilo d' octets divisé par 1 000. Comme nous ne travaillerons qu'avec des sorties sigmoïdes pour le moment, nous nous intéresserons uniquement à la limite de poussière pour les sorties Ségue. Créons donc cette constante qui sera égale à 98. Cette valeur est extraite directement du fichier point cpp de politique Bitcoin Core mentionné dans la dernière présentation. Injectons également les frais de relais de poussière dans cette classe. Il sera long et sa valeur sera injectée depuis le fichier de propriétés. Ajoutons l'annotation de valeur suivante avant celle-ci. Ajoutons maintenant cette valeur à tous les fichiers de propriétés. Définissons-la sur 3 000, la même valeur par défaut utilisée dans le nœud Bitcoin Core. Maintenant, dans le package api point services, créons l'interface Coin Selector. Créera cette interface afin qu'elle offre plus de flexibilité. Si nous voulons créer d'autres implémentations de coin Selector ultérieurement. Ajoutons-y la méthode de sélection. Il renverra une liste des UTXO sélectionnés. Et il nous faudra des paramètres, une liste d'UTXO, un grand entier pour le montant à envoyer, une grande décimale pour le taux de frais, adresse à envoyer et un changement d'adresse. Maintenant, dans le même package, créons le sélecteur de pièces à tirage aléatoire unique, qui implémentera cette interface. Implémentons sa méthode et ajoutons-y une annotation de service. Injectons le calculateur de taille de transaction dans cette classe. Et injectons-y le calculateur de poussière. Avant de continuer à implémenter la méthode de sélection, créons la classe de test Single Random Draw a Coin Selector. Dans la classe de test API. Cela étendra la classe de spécification. Injectons le tirage au sort unique dans cette classe. Et utilisons la méthode de configuration pour l'instancier. Passons le calculateur de la taille des transactions et le calculateur de poussière avec des frais de relais de 3 000 dollars comme paramètres. Maintenant, créons un test. Tidal devrait sélectionner les n entrées attendues, les pièces pour la transaction avec les sorties attendues et les sorties. Créons maintenant une classe utilitaire qui nous aidera à tester et à implémenter le sélecteur de pièces à tirage aléatoire unique. Appelons-le Satoshi et créé dans le package utils. Maintenant, créons les deux méthodes de Satoshi. Il prendra une grande décimale comme paramètre et renverra un grand entier. Cette méthode convertira un montant en Bitcoin en un montant identique en Satoshi. Pour ce faire, nous renvoyons simplement le montant en Bitcoin multiplié par 100 millions et convertissons le résultat en un grand entier. Créons également une méthode pour effectuer l'opération inverse, qui consiste à convertir Satoshi en Bitcoin. Pour cela, nous allons simplement renvoyer le montant enveloppé dans une nouvelle grande décimale divisée par 100 millions. Dans la méthode de division, huit sera utilisé comme deuxième paramètre pour que le résultat ait huit décimales. Nous passerons également le mode arrondi inutile comme troisième paramètre. Créons maintenant une méthode pour convertir un taux de commission en Bitcoins par vélo KV en taux de Satoshi par octet V. Il sera nommé BTC par Ko en Satoshi par octet. Il renverra un grand entier et prendra comme paramètre une grande décimale. Tout d'abord, nous multiplierons le taux des frais par 100 millions. Ensuite, nous diviserons le résultat par 1024 avec deux décimales et en arrondissant le plancher. Convertissons ensuite le résultat en un grand entier et stockons-le dans la bonne variable. Si le résultat est inférieur à un, nous le rendons égal à un. Enfin, nous renvoyons le taux converti. Dans la vidéo suivante, nous finirons de tester et d'implémenter le sélecteur de pièces à tirage aléatoire unique C. Oui. 50. 48 Envoyer du bitcoin partie 4 Skillshare 2: Dans cette vidéo, nous allons terminer la mise en œuvre de l'algorithme de tirage aléatoire unique. Lors du test de sélection de pièces à tirage aléatoire unique dans un bloc donné, nous allons d'abord créer des UTXO à l'aide cette méthode et stocker le résultat dans la variable utxOS. Ce seront les UTXO disponibles qui seront transmis comme premier paramètre à la méthode testée. Créons donc cette méthode. Il prendra comme paramètre une liste de grands entiers, qui définira le montant de chaque UTXO. Ainsi, pour chaque élément de la liste, nous appellerons la méthode create UTXO pour créer un UTXO unique. Créons cette méthode. Instancions un UTXO avec ces paramètres. Vous pouvez copier ces valeurs à partir des ressources de cette leçon. Créons maintenant un UTXO supplémentaire et ajoutons-le à la liste des UTXO à l'aide de ce code. La raison pour laquelle nous ajoutons un UTXO supplémentaire à la liste est que nous voulons autoriser la méthode select à l'ajouter à la liste UTXO sélectionnée. Si tel est le cas, nous saurons que la méthode testée ne fonctionne pas comme prévu. Définissons ces deux adresses. L'une doit être l'adresse à envoyer et l'autre l'adresse de changement. Vous pouvez les copier depuis la page Projet et ressources. Fixons le taux de frais à 0,0 002. Dans le bloc éolien, nous appellerons la méthode de sélection par tirage aléatoire unique avec ces paramètres. Dans le bloc then, vous vérifierez si la taille UtxOS sélectionnée est égale au nombre attendu de variables d'entrées dans le bloc where. Ajoutons ces cas de test. Vous pouvez les trouver sur la page Projet et ressources. Ces scénarios de test couvraient des transactions avec 12,3 entrées et 1,2 sorties. Les montants d'entrée pour les transactions comportant un seul résultat ne devraient pas générer changement ou générer des changements dont la valeur est ajoutée aux frais. Les montants d'entrée pour les transactions à deux sorties devraient générer une valeur inchangée, qui sera renvoyée à l'expéditeur via une deuxième sortie. Faisons le test. Il a échoué comme prévu. Maintenant, implémentons la méthode de sélection par tirage aléatoire unique. Tout d'abord, nous allons filtrer tous les UTXO reçus afin de créer une liste contenant uniquement les UTXO présentant une ou plusieurs conformations. Créons donc cette méthode. Pour ce faire. Nous appellerons la méthode de filtrage sur le flux UTXos, renvoyant une liste contenant uniquement les UTXO confirmés. Créons maintenant cette variable pour stocker le taux de commission par octet V de Satoshi. Pour cela, nous utiliserons la méthode BTC par Ko et Satoshi par vélo de la classe Satoshi. Maintenant, stockons les UTXO mélangés dans cette variable, lui attribuant le retour de cet appel de méthode. Créons cette méthode. Tout d'abord, nous allons instancier une nouvelle ArrayList contenant le contenu de la liste UTXos. Ensuite, nous appellerons la méthode de collecte shuffle, en passant la nouvelle liste comme paramètre. Ensuite, nous vous renverrons la liste des pièces mélangées. Instancions maintenant une ArrayList qui stockera les UTXO sélectionnés. Et créons cette variable pour stocker le solde total des entrées. Maintenant, pour chaque UTXO de la liste des pièces mélangées, nous allons ajouter l'UTXO à la liste UTXO sélectionnée. Et nous ajouterons son montant en Satoshi à la variable équilibrée totale des entrées. Si le solde total des entrées est inférieur au montant ascend, nous poursuivons l'exécution à partir de l'itération de boucle suivante. Après l'instruction if, lorsque le solde total des entrées dépasse le montant à envoyer, une ArrayList instanciera une ArrayList avec les adresses de sortie et ajoutera l'adresse à envoyer à cette liste. Et nous allons créer une liste avec les adresses des entrées sélectionnées à l'aide de cette cartographie des flux. Calculons maintenant les frais totaux dans Satoshi et stockés dans cette variable. Pour cela, appelons la méthode des frais totaux, paramètres le taux de redevance exprimé en octets de Satoshi par V bit les adresses d'entrée et , les adresses d'entrée et les adresses de sortie. Créons cette méthode. À l'intérieur, il renverra l'appel de méthode de calcul du calculateur de la taille de la transaction en passant les adresses d'entrée et les adresses de sortie comme paramètres. Ensuite, nous multiplierons le résultat par le taux de frais exprimé par bouchée V pour Satoshi. Nous allons maintenant créer la variable cible ajustée, qui sera égale à la somme du montant à envoyer et du montant total des frais. Ajoutons maintenant l' adresse de modification à la liste des adresses de sortie. Nous calculerons les frais totaux en fonction de la modification, en utilisant la méthode des frais totaux, en passant ces paramètres. Et nous calculerons l'objectif ajusté en fonction du changement, qui sera égal à la somme de la quantité de sable et de la redevance totale avec variation. Maintenant, si le résultat de la méthode de transaction exécutée équilibrée en entrée avec ces paramètres est vrai, nous quitterons la boucle en utilisant le mot clé break. Créons cette méthode. Il renverra le résultat de l'instruction suivante. Si le solde d'entrée total est égal ou supérieur à la cible ajustée et que les modifications générées sont réduites en poussière, cela signifie que les UTXO sélectionnés sont suffisants pour effectuer cette transaction. Une autre condition pour que les UTXO sélectionnés puissent effectuer la transaction est que la somme de leurs montants soit égale ou supérieure à la cible ajustée avec modification. Créons le changement, la méthode «  poussière » renverra le calculateur de poussière est un appel à la méthode de la poussière, en transmettant la grande différence entière entre le solde d'entrée total et la cible ajustée comme paramètre. Enfin, nous allons simplement renvoyer les UTXO sélectionnés à l' aide de cette méthode. Passons maintenant au test de sélection de pièces à tirage aléatoire unique test de sélection de pièces à tirage aléatoire et exécutons ce test. Grade. Les tests sont réussis. 51. Comment les transactions Segwit sont élaborées et validées: Dans cette présentation, nous verrons plus de détails sur la façon de créer une transaction. Supposons donc que nous ayons déjà utilisé le sélecteur de pièces pour sélectionner des UTXO à dépenser comme entrées dans une transaction. Dans notre portefeuille, nous avons également la possibilité de récupérer les clés privées nécessaires pour dépenser ces UTXO. Ces clés privées seront nécessaires pour signer la transaction ultérieurement. Nous avons déjà choisi une adresse pour envoyer des Bitcoins. Et nous avons l'adresse du changement laquelle le changement sera envoyé. Après avoir défini ces éléments, il est temps de construire notre transaction. Voyons les champs qui font partie d'une transaction Bitcoin. Tout d'abord, le champ de version. Il est utilisé pour définir les règles que suit la transaction. Actuellement, la première version, que nous utiliserons , concerne les transactions courantes. La deuxième version concerne les transactions suivant le BIP 68, qui met en œuvre des règles pour valider une transaction uniquement après un certain temps. Le champ de durée de vie est utilisé dans un but similaire. Sa valeur peut représenter un certain temps pour ajouter une transaction à un bloc ou zéro pour ignorer cette règle, alors nous avons le set qui indiquerait le drapeau et le marqueur. Il n'est présent que dans les transactions Segway. Si sa valeur est 0001, alors il marque cette transaction comme ayant indiqué quelles entrées, chaque transaction possède une ou plusieurs entrées de transaction. Chaque entrée de transaction possède un identifiant de transaction qui définit une transaction précédente à partir de laquelle l'entrée actuelle dépense des Bitcoins. L'indice de sortie indique sortie de la transaction précédente. L'entrée actuelle consiste à dépenser des Bitcoins à partir de. Ensemble, l'ID de transaction et l'indice de sortie sont appelés point de sortie. Vous pouvez voir le point de sortie sous forme de coordonnée pour identifier à quel UTXO et à quelle entrée se réfèrent. Ensuite, pour chaque entrée, nous avons le champ ScriptSig. Dans les entrées segmentées. Ce champ est vide et son contenu est déplacé vers le champ témoin. Dans les transactions non segmentées, son contenu est nécessaire pour débloquer les dépenses de l'UTXO. L'entrée fait référence à. Le champ de séquence n définit le moment où l'entrée est valide pour être dépensée. Lorsque la valeur de ce champ est égale à la valeur hexadécimale maximale pour sa taille, ce champ est ignoré. Une transaction possède également une ou plusieurs sorties. Chaque sortie contient une clé de script, dont le code de script définit les règles à utiliser pour utiliser cette sortie lors d'une transaction future. Chaque sortie contient également un champ de quantité qui définit le nombre de Satoshi bloqués dans cette sortie. Enfin, les transactions contiennent également un champ témoin. Pour les transactions autres que Segway, ce champ est vide. Pour les transactions Segway, le témoin contient tout le contenu qui, dans les transactions non séquentielles, se trouve dans le ScriptSig de chaque entrée. Parlons maintenant de la façon de créer des entrées de transaction et du champ témoin pour les entrées segmentées. Pour chaque UTXO sélectionné, nous devons créer une entrée de transaction. Le champ ID de transaction de l' entrée de transaction sera égal à l'ID de transaction UTXO. Le champ d'index de sortie sera égal à l'indice de sortie UTXO, également connu sous le nom de Vout dans la documentation de l' API RPC Bitcoin Core. Le ScriptSig sera vide et la séquence de fin sera égale à cette valeur hexadécimale, qui est la valeur maximale autorisée pour ce champ. Nous devons également créer un témoin pour chaque entrée, le champ témoin contiendra une signature obtenue l'aide de la clé privée utilisée pour obtenir l'adresse UTXO. Et une clé publique qui a été dérivée à l'aide de la clé privée précédente et qui peut également générer la même adresse UTXO mentionnée. Nous verrons plus de détails sur le processus de signature lors d'une prochaine présentation. Notez que les signatures factices et les bupkis, dont les valeurs peuvent être un tas de zéros, peuvent être utilisés comme espaces réservés pour créer et signer des transactions. Cette astuce facilite le calcul de la taille de la transaction par rapport à la taille avant de signer les transactions. Parlons maintenant de la façon de créer des sorties Segue What. D'abord. En passant, il est possible de créer une transaction avec différents types d' entrées et de sorties. Par exemple, dans une même transaction, vous pouvez avoir des entrées et des sorties segmentées et non segmentées. Revenons au sujet principal. En général, nous voulons créer une sortie pour l' adresse à laquelle nous voulons envoyer des bitcoins et une sortie pour le changement d'adresse. Si la transaction nécessite une modification. Chaque sortie de transaction possède un champ de clé de script Pub. Chaque clé de pub de script de segment, également connue sous le nom de pay to witness pub key hash ou P2, WP k H possède une version témoin de zéro. La version témoin est destinée aux scripts Taproot. De nouvelles versions peuvent être ajoutées pour les futurs scripts si nécessaire. Le deuxième élément clé de pub de script pour les sorties sigmoïdes est un hachage de clé publique, obtenu par Beck 32 décodant l'adresse de cette sortie. La sortie de la transaction comporte également un champ de montant dans Satoshi représentant le montant envoyé à cette adresse de sortie. Terminons maintenant cette présentation en parlant de l' exécution et de la validation du script de segment. Lorsqu'un nœud reçoit une transaction, il commence à la valider. Pour chaque entrée d'une transaction, le nœud combine le témoin d' une entrée avec la clé de script pub de l'UTXO référencée par le point de sortie et l'entrée réseau exécute le script combiné et le valide. . Voyons comment cela se fait. Voici la clé de pub de script d' un UTXO et le champ témoin qui souhaite dépenser cet UTXO génèrent tous deux le script combiné suivant. Vous vous demandez peut-être d' où proviennent les opcodes du script combiné. Il s'avère que lorsqu' un nœud identifie la version zéro sur la clé pub du script de segment, il déclenche une règle spéciale qui génère une partie du code combiné ci-dessous. Ensuite, le script combiné est exécuté de la même manière que les scripts non-sequiturs. À partir du script combiné, la signature et les clés publiques sont ajoutées à une pile d'exécution. Ensuite, l'opcode OPT up duplique la clé pub dans la pile d'exécution. Jusqu'à 160 hachages, la dernière clé de pub ajoutée à la pile. Ensuite, à partir du script combiné, le hachage de la clé pub est ajouté à la pile. opcode Up equal verify supprime les deux derniers éléments de la pile d'exécution et les compare. S'ils sont égaux, le script continue de s'exécuter. Enfin, l'opcode object sig vérifie si la signature est valide pour la clé pub restant dans la pile. S'il est valide, il renvoie true à la pile d'exécution. Une fois que tous les éléments de script ont été ajoutés à la pile d' exécution, l'entrée de transaction est considérée comme valide si le dernier élément ajouté est vrai. Ce processus doit être répété pour chaque transaction saisie. Pour qu'une transaction soit considérée comme valide, toutes ses entrées doivent être valides. À titre de rappel visuel, passons en revue l' origine de chaque élément du script, de la clé et du témoin lors de la construction de la transaction. Le hachage de la clé pub présent dans le script Pub Key provient décodage de l'adresse de l'UTXO dépensé. La signature du témoin a été obtenue en appliquant l'algorithme ECDSA, qui nécessite une clé privée valide. La clé publique et le témoin provenaient de la clé publique dérivée de la clé privée mentionnée. La même clé publique était utilisée dans le passé pour générer l'adresse de l'UTXO dépensé en appliquant séquentiellement l'algorithme de hachage 160 et le codage retour 32. 52. 50 Envoyer des bitcoin partie 5 skillshare 2: Dans cette vidéo, nous allons créer un service de création de transactions. Dans un premier temps, ce service ne traitera que des entrées et sorties segmentées, mais nous l'améliorerons plus tard dans le cours. Donc, dans le package api point services, créons le service Transaction Creators. Ajoutons-y l' annotation du service. Injectons-y également le calculateur de poussière. Maintenant, dans le package de test de l'API, créons la classe de test du service Transaction Creators. Cela étendra la classe de spécification. Injectons-y le service Transaction Creators et instancions-le dans la méthode de configuration. Il faudra l'instancier avec un nouveau calculateur de poussière dépassant 3 000 comme paramètre de frais de relais de poussière. Avant de faire ce test, passons au test de sélection de pièces à tirage aléatoire unique pour effectuer une petite refactorisation. Supprimons ces deux méthodes de cette classe et collons-les dans la nouvelle classe utils que nous allons créer dans le package de test BYOD W. Rendons ces deux méthodes statiques. Maintenant, réparons la seule pièce de drogue aléatoire. Sélectionnez votre test pour utiliser les méthodes de cette classe. Passons maintenant au test du service Transaction Creators. Créons un test appelé devrait créer transaction avec le hashtag n entrées, entrées et hashtag attendu n sorties, sorties. Dans le corps donné. Créons d'abord cette variable utxOS et affectons l' appel de méthode utils point create utxOS qui lui est renvoyé, transmettant la variable des montants en entrée comme paramètre. Maintenant, créons cette adresse pour envoyer une variable. Son contenu sera égal à la variable portant le même nom lors du test de sélection de pièces à tirage aléatoire unique . Créons également la variable de changement d'adresse, qui sera égale à la variable portant le même nom. Lors d'un tirage au sort, sélectionnez votre test. Créons la variable de taux de frais, qui sera égale à 0,000 à. Définissons également la variable de frais totaux attendus, qui sera égale à la variable de taille attendue multipliée par le taux de frais exprimé par bouchée V de Satoshi. Maintenant, créons la quantité totale d'entrée variable. Sa valeur sera égale au résultat de cette expression, qui renverra la somme de chaque montant UTXO en Satoshi. Le montant à envoyer à la variable sera égal à 100 millions de Satoshi. Calculons également le montant du changement attendu. Il sera égal à la quantité d'entrée moins la quantité de sable moins les frais totaux attendus. Dans le bloc unique, nous appellerons créateur de la transaction, la méthode create transmettra les paramètres suivants à cette méthode. Le résultat sera enregistré dans la variable transaction. Dans le bloc then, vous vérifierez si la taille v de la transaction est égale à la variable de taille attendue. Mais d'abord, mettons à jour la version Java de Bitcoin à 0.4, 0.2 pour rendre la méthode get v size disponible. Nous allons maintenant vérifier si le nombre de sorties de transaction est égal à la variable attendue et aux sorties. Nous vérifierons également si le premier montant de sortie est égal au montant à envoyer variable. Maintenant, si le nombre de sorties attendu est supérieur à un, nous vérifierons si le montant de la modification est égal au deuxième montant de sortie de la transaction. Dans le bloc Where. Ajoutons les cas de test suivants. Vous pouvez les copier depuis la page Projet et ressources. Ces scénarios de test couvrent des scénarios avec et sans sortie de changement et avec des quantités d'entrées qui génèrent des changements ou non. Ils couvraient également les transactions comportant 12,3 entrées. Créons maintenant la méthode de création du service Transaction Creators. Renommons ces paramètres. Avant d'implémenter cette méthode, créons la classe fee dans le package utils. Nous allons créer ici une méthode pour calculer les frais totaux des transactions chez Satoshi's, appelons-les frais totaux calculés. Il recevra une transaction au taux de frais en Bitcoin par tranche KV et créera le code suivant dans un bloc Try Catch. Tout d'abord, nous allons convertir le taux de frais de Bitcoins par vélo KV en Satoshi is Privy byte. Ensuite, nous renverrons le résultat en multipliant la taille v de la transaction par le taux de frais en fonction de la taille V de Satoshi. Nous obtiendrons une IOException qui peut être déclenchée par la bonne méthode de taille V et rapide dans une nouvelle exception d'exécution. Revenons au service des créateurs de transactions. Dans cette méthode, vous allez d'abord créer les entrées de transaction en utilisant cette méthode, en transmettant les UTXO reçus comme paramètre. Créons cette méthode. Nous renverrons le résultat de la transformation du flux UTXOS suivante. Le flux ne sera pas transformé en une nouvelle transaction. L'entrée transmettra l' ID UTXO reçu comme premier paramètre. La grande valeur entière de l'UTXO jurée comme deuxième paramètre. Ces deux paramètres définissent le point de sortie d'entrée de la transaction. Ensuite, nous passerons un nouveau script instancié avec une liste vide. Ce paramètre est le ScriptSig d'entrée de transaction, qui est vide pour les entrées de segment. Ensuite, nous allons transmettre un grand entier instancié avec ces paramètres, qui définit l' entrée dans l'ordre. Cette valeur est la valeur maximale autorisée pour ce champ, ce qui fait que les nœuds l'ignorent. Maintenant, pour chaque transaction saisie dans le flux, j'utiliserai la méthode peak pour définir le témoin instancier le témoin avec une liste contenant des constantes pour une signature factice et une clé pub factice. Créons maintenant ces constantes. La signature factice sera égale à la chaîne hexadécimale zéro répétée 144 fois, dont la taille en octets est égale à 72. La clé pub factice sera égale à la chaîne hexadécimale zéro répétée 66 fois, dont la taille en octets est égale à 33, définira ces valeurs factices car elles seront nécessaires pour exécuter correctement calcul de la taille de la transaction v, qui fera en sorte que, dans la méthode create , le processus de signature soit effectué séparément. Plus tard, lorsque les valeurs réelles seront remplacées par des valeurs factices. Enfin, nous allons convertir le flux en ArrayList et le renvoyer. Nous allons maintenant créer la sortie de transaction pour l'adresse à envoyer en utilisant la méthode buildup PUT, en transmettant l'adresse à envoyer et le montant à envoyer comme paramètres. Créons cette méthode. Tout d'abord, nous allons analyser le préfixe d'adresse à l'aide de la méthode parse prefix, qui créera. Cette méthode vérifie si l'adresse commence par l'un des préfixes de segment valides et renvoie le préfixe d'adresse ou une chaîne vide si aucun préfixe valide n'a été trouvé. Nous allons maintenant créer un objet de script en utilisant la classe de script P2, méthode de script WP k h. En tant que paramètre, il transmettra le résultat de l'appel à la méthode back 30 pour décoder, en transmettant le préfixe et l' adresse à cette dernière. Le retour de la méthode back 30 to decode est un tableau d'objets dont le deuxième élément est le hachage de la clé pub, qui sera transmis à la méthode de script P2 WP k h. Cette méthode renverra l'équivalent de la clé pub du script, où le premier paramètre est zéro et le second est le hachage de la clé de pub, comme nous l'avons expliqué dans la dernière présentation. Enfin, nous allons renvoyer une nouvelle sortie de transaction instanciée avec le montant et le script créé. Maintenant, nous allons créer une ArrayList pour stocker les sorties des transactions, instancier , en y ajoutant l'adresse d' envoi de la sortie que nous venons de créer. Ensuite, nous allons créer la transaction sera transmise comme paramètre, le grand entier, qui est la version de la transaction. Les entrées de transaction, les sorties de transaction. Le grand entier zéro est le temps de verrouillage qui sera ignoré. Et le booléen true pour définir cette transaction comme une transaction secondaire. Ce paramètre donnera la transaction le marqueur et le drapeau Segway. Calculons maintenant le total des frais de transaction en utilisant la méthode F0 calculée précédemment dans la classe FI. Nous utiliserons la transaction et le taux de frais comme paramètres. Calculons également la zone d'entrée pour laquelle le flux UTXO sera mappé en un flux de montants UTXO. Ensuite, nous utiliserons la méthode réduite pour les additionner. Enfin, nous convertirons le résultat en ptose ou zéro si les UTXO n'existent pas. Ensuite, nous calculerons la variation qui sera égale à la somme d'entrée moins la quantité de sable moins les frais totaux. Ensuite, nous ajouterons l'instruction if suivante. L'utilisation du calculateur de poussière permet de vérifier si le changement est dû à de la poussière. Si c'est le cas, nous vous rembourserons la transaction telle quelle. Si ce n'est pas le cas, nous ajouterons une autre sortie à la transaction en utilisant la méthode build output, transmettant l'adresse de modification et le grand entier comme paramètres, en transmettrons une au montant de sortie simplement en tant que valeur d'espace réservé, car nous devrons recalculer les frais de transaction pour la transaction qui comporte désormais deux sorties, ce qui implique des frais plus élevés. Recalculons donc les frais totaux en utilisant la méthode F0 totale calculée. Encore une fois, recalculons la variation qui sera égale à la somme d'entrée moins le montant à envoyer moins les nouveaux frais totaux calculés. Maintenant, supprimons la dernière sortie de transaction ajoutée des sorties de transaction ArrayList. Vérifions à nouveau si le nouveau changement calculé est dû à la poussière. Si c'est le cas, il renverra la transaction sans modification. Si ce n'est pas le cas, nous ajouterons une nouvelle sortie à la transaction en utilisant la méthode build output. Cette fois, nous allons transmettre la valeur de variation réelle de la transaction avec deux sorties à cette méthode. Enfin, nous vous rembourserons la transaction. Passons maintenant au test du service Transaction Creators et exécutons ce test. Super, les tests sont réussis puisque nous avons précédemment modifié le test de sélection de pièces à tirage aléatoire unique. Réexécutons-le également pour nous assurer que nous n'avons rien cassé. Ils sont géniaux. Il fonctionne comme d'habitude. 53. 51 Envoyer des bitcoin partie 6 skillshare 2: Dans cette vidéo, nous allons commencer à créer la fenêtre qui apparaîtra lorsque nous cliquerons sur le bouton Envoyer. Cette fenêtre contiendra des informations sur la transaction. Nous envoyons un champ de mot de passe et un bouton OK pour confirmer la diffusion de la transaction. Donc, dans le package FXML, créons le fichier FXML à points de soulignement de la transaction send underscore. Effacons le standard généré. Maintenant, créons une balise de dialogue. Passons maintenant au Scene Builder. Réglons la hauteur préférée de la douleur du dialogue sur 300. Et sa largeur est préférée à 650. Et définissons la hauteur minimale par la largeur minimale pour utiliser la taille de la presse. Ajoutons maintenant une grille au contenu de la boîte de dialogue. Ajoutons quatre lignes supplémentaires à ce volet de grille. Ajoutons maintenant une étiquette à la première ligne. Modifions son texte pour envoyer un point d'interrogation sur la transaction. Augmentons sa taille de police à 16 pixels. Pour les lignes suivantes, l' idée est d'ajouter des étiquettes et des données pour la transaction d'envoi. Ajoutons une étiquette à la deuxième ligne et changeons son texte en deux points. Dans la deuxième colonne de la même ligne. Ajoutons une autre étiquette. Cette fois, le texte sera vide et nous y ajouterons un Fx ID afin de pouvoir modifier son contenu dynamiquement ultérieurement. Ajoutons une autre étiquette dans la troisième ligne, cette fois avec le texte «  frais totaux » dans la cellule de droite. Ajoutons une étiquette vide avec un autre identifiant FX. Dans la rangée ci-dessous. Ajoutons une autre paire d' étiquettes pour le champ total. Au rang suivant. Ajoutons ces étiquettes pour le taux de redevance. Maintenant, faisons de même pour l'adresse à envoyer. Au dernier rang. Ajoutons une étiquette pour le mot de passe du portefeuille. Dans la cellule de gauche. Ajoutons un champ de mot de passe. Il aura un identifiant FX ou un mot de passe de portefeuille. Soudainement, il manque un deux-points à la fin des étiquettes . Réparons-les. Maintenant. Passons à la configuration du dialogue et ajoutons un bouton OK ici. Ajoutons également un bouton d'annulation. Le texte du bouton Annuler est dans ma langue maternelle. Si tel est également votre cas, vous pouvez le modifier en procédant comme suit. Passons à la vue de l'éditeur. Tout d'abord, ajoutons une idée Fx de OK au bouton OK. Et ajoutons une idée Fx d' annulation à la balise du bouton d'annulation. Maintenant, supprimons cette propriété. Réglons la propriété de données du bouton sur cette valeur, puis définissons son texte pour qu'il soit annulé. Maintenant, dans le Scene Builder, nous pouvons voir que le changement a pris effet. Passons maintenant à l'onglet Envoyer FXML. Dans le bouton Envoyer, définissons la propriété de l'action Envoyer par hashtag » afin que, lorsque nous cliquons sur ce bouton, la méthode d'envoi du contrôleur de l'onglet Envoyer soit appelée. Créons donc cette méthode. Avant de l' implémenter, créons un enregistrement DTL de transaction dans le package de domaines. Ttl signifie objet de transfert de données Il s'agit d'un modèle de conception courant à utiliser pour les objets dont l'objectif principal est de transférer des données entre des classes et des méthodes. ce titre, le DTO de transaction sera utilisé pour transférer les données de transaction entre nos services. Ajoutons-y les champs suivants. À ce stade, vous vous demandez peut-être quelle est la différence entre le total des frais réels et le total calculé v ? Nous y reviendrons sous peu. Passons maintenant au contrôleur de l'onglet Envoyer. Ajoutons-y les champs suivants. Ces champs seront liés aux balises correspondantes dans le fichier FXML de l'onglet Envoyer. Implémentons maintenant la méthode send. D'abord. Nous allons convertir le montant à envoyer du texte en une grande quantité décimale. Nous allons maintenant créer une transaction que l'objet DTO créera à l'aide de la commande create transaction que le service créera. Injectons ce service dans cette classe. Créons-le dans le package de services GUI dots. Maintenant, finissons de l' injecter dans cette classe. Ici, nous allons appeler la méthode create qui s'y trouve, en transmettant l'adresse pour envoyer le texte et la variable de montant. Créons cette méthode. Nous allons maintenant utiliser cette méthode pour ouvrir la fenêtre de dialogue passant le DTO de la transaction comme paramètre. Créons-le. Après avoir ouvert la fenêtre de dialogue, nous appellerons la méthode clear en fonction l'adresse à envoyer et du montant à envoyer, des variables pour effacer le contenu de ces entrées. Passons maintenant au service de création de transactions. Ajoutons-y l' annotation du service. Nous allons implémenter la méthode create. Maintenant, l'idée est d'utiliser de nombreux services que nous avons créés dans les vidéos précédentes pour créer une transaction et quelques données supplémentaires pour la transaction DTO. Pour cela, la première chose que nous ferons est d'utiliser le service d'estimation des frais pour obtenir le taux de frais et de le stocker dans la variable de taux de frais. Injectons donc ce service dans cette classe. Et appelons-y la méthode d' estimation. Nous allons maintenant obtenir les adresses de portefeuille actuellement chargées en utilisant l'objet du portefeuille actuel. Injectons-le donc dans cette classe. Ensuite, nous appellerons la méthode get addresses sous forme de chaînes. Ensuite, nous aurons tous nos portefeuilles UTXO. Pour cela, nous utiliserons le client non dépensé de la liste des nœuds. Injectons-le donc dans cette classe. Nous appellerons la méthode « liste non dépensée », en transmettant les adresses et le nom du portefeuille actuel comme paramètres. Nous allons maintenant utiliser le sélecteur de pièces pour sélectionner les UTXO qui seront utilisés comme entrées dans notre transaction. Injectons donc le sélecteur de pièces dans cette classe. Maintenant, nous allons appeler la méthode de sélection s'y trouve, en passant les UTXO, le montant converti en Satoshi, le taux de frais, l'adresse à envoyer et le portefeuille actuel, changer d'adresse, appelant le méthode de changement d'adresse du portefeuille actuel, qui créera. Créons donc cette méthode. Il renverra simplement la propriété de changement d'adresse. Créons cette propriété sous forme de chaîne. Déplaçons-le ici. Créons également un setter pour cela. Nous l'utiliserons plus tard. Utilisons maintenant le service Transaction Creators pour créer une transaction. Injectons donc ce service dans cette classe. Appelons la méthode create dessus transmettant les paramètres suivants. Maintenant que nous avons notre transaction, nous allons créer des données supplémentaires à inclure dans le DTL de la transaction. Prochaine. Tout d'abord, utilisons la méthode des frais réels totaux de la classe FI pour obtenir le montant total des frais réels qui seront répercutés la transaction et les UTXO sélectionnés comme paramètres. Créons cette méthode. La différence entre le total des pieds calculés et le total des frais réels est que pour ce dernier, nous utilisons la différence entre les montants des entrées et des sorties pour le calculer. Dans le premier cas, nous avons fait une estimation en utilisant la taille de la transaction et le taux de frais. En théorie, on s'attend à ce que les deux valeurs soient identiques, mais utilisons par défaut le nombre total de pieds réels lorsque cela est possible, afin de garantir que nous montrons l'utilisateur la transaction réelle gratuit et pour permettre à l'utilisateur de repérer d' éventuelles valeurs boguées. Nous allons donc calculer ici les montants d'entrée, certains en Bitcoin en utilisant la transformation de flux suivante. Nous allons cartographier le flux UtxOS sélectionné pour produire un flux de quantités d'UTXO. Utilisez ensuite la méthode réduite pour additionner toutes les valeurs du flux. Et utilisez la méthode or else pour renvoyer zéro si la chaîne est vide. Maintenant, calculons que la sortie parmi certaines valeurs Satoshi effectuera la même transformation que nous avons faite pour les entrées, mais avec les sorties de transaction cette fois. Nous allons maintenant renvoyer l' entrée, une partie en BTC est convertie en Satoshi moins une partie en sortie. Revenez au service Créer une transaction. Créons maintenant la variable F0 totale calculée et attribuons-lui le résultat de l'appel total de la méthode F0 calculée à cette variable. Cette fois, nous utiliserons la transaction et le taux de frais comme paramètres. Calculons maintenant le total dépensé, qui, comme son nom l'indique, est le montant total en Satoshi que l'expéditeur a dépensé pour cette transaction. Pour cela, utilisons la méthode du total dépensé en transmettant la transaction, le total des frais réels et l' adresse comme paramètres. Créons cette méthode. Avec cette déclaration if. Vérifions si l'adresse à envoyer appartient à notre portefeuille. cas contraire, nous vous rembourserons le montant total des frais réels plus le montant de la première transaction. Si notre portefeuille en contient, cela signifie que nous nous transférons des bitcoins et que nous ne dépensons donc que les frais de transaction. Enfin, nous allons renvoyer une nouvelle transaction (objet DTO instancié avec ces paramètres continuerons à implémenter la fonction de fenêtre de dialogue dans la vidéo suivante. voit. 54. 52 Envoyer des bitcoin partie 7 skillshare 2: Dans cette vidéo, nous allons terminer l' implémentation de la fenêtre de dialogue des transactions. Passons donc au contrôleur de l'onglet Envoyer. Dans la méthode du dialogue ouvert, instancions un nouvel objet de dialogue comme celui-ci. Appelons ensuite la méthode du propriétaire de l'unité dessus, en passant l'objet de la fenêtre comme paramètre, comme ceci. Définissons le titre du dialogue pour envoyer la transaction. Maintenant, avec le code suivant, nous allons définir que lorsque nous cliquons sur le bouton Fermer de la fenêtre de dialogue, la fenêtre de dialogue se ferme. Ensuite, nous allons créer un objet chargeur FXML dans un bloc try catch. Pour l'instancier, il faudra injecter la ressource FXML du dialogue dans cette classe. Allons-y. Ajoutons une annotation de valeur à ce champ indiquant le chemin du dialogue de transaction sin FXML. Ici, nous appellerons la méthode get URL. Ensuite, nous utiliserons null dans ces paramètres. Et le contexte obtient la référence de la méthode Beam ici. Tout d'abord, créons l'objet contextuel du champ dans cette classe et affectons-le ici. Nous allons maintenant définir le contenu du dialogue en fonction du résultat de l'appel de la méthode de chargement du chargeur FXML. Maintenant, avec le code suivant, vous obtiendrez le contrôleur de dialogue de transaction syn à partir du chargeur FXML. Créons ce contrôleur dans la classe Controllers. Enfin, nous allons transmettre l'objet DTO de transaction au contrôleur de dialogue sin transaction en utilisant la méthode de transaction set. Créons cette méthode. Ici, nous allons détecter une IOException que le chargeur FXML peut lancer et l'encapsuler dans une nouvelle exception d'exécution. Ensuite, nous afficherons le dialogue en utilisant cette méthode. Maintenant, avant d'implémenter le deuxième contrôleur de dialogue des transactions, passons à la mise à jour du service de portefeuille actuel. Lorsque nous mettons à jour le portefeuille actuel, nous devons définir son adresse de changement, qui sera utilisée lors de l'envoi d'une transaction. Alors allons-y. Nous allons le faire en obtenant la deuxième clé publique étendue à partir du portefeuille créé. N'oubliez pas que cette clé étendue a été dérivée pour générer des adresses de changement. Ensuite, nous obtiendrons sa première adresse et définirons comme adresse de changement d'adresse actuelle du portefeuille. Passons maintenant au deuxième contrôleur de dialogue transactionnel. Configurons l' annotation du composant sur celle-ci. Passons maintenant au deuxième dialogue de transaction FXML. Réglons le dialogue Pain FX ID. Et définissons la propriété du contrôleur FX sur le chemin du contrôleur récemment créé ici. Nous allons maintenant attribuer à chaque tag un identifiant éthique dans ce fichier, champs dans le deuxième contrôleur de dialogue de transaction utilisant cette fonctionnalité intéressante de l'IDE. Maintenant, définissons que chaque champ est privé. Ajoutons l'annotation FXML au-dessus de chacune d'entre elles. Avant d'implémenter la méthode Set Transaction, créons le domaine de dialogue des transactions dans le package domains. J'aurai bientôt besoin de ce record. Il modélisera les champs qui apparaîtront dans la boîte de dialogue de transaction. Créons donc ces champs. Créons également cette méthode à partir de la méthode. Cela créera un nouveau dialogue de transaction à partir d'un DTO de transaction. Nous utiliserons le format ou la méthode de formatage Bitcoin pour analyser correctement le montant à envoyer le total des frais réels. Le montant total dépensé sera également répercuté sur le taux de frais et l'adresse de la transaction. DTO vers l'instanciation du dialogue transactionnel. Revenons au deuxième contrôleur de dialogue transactionnel. Dans la méthode set transaction, définissons le champ D TO de transaction sur le DTO de transaction reçue. Créons ce champ dans cette classe. Maintenant, créons l' objet de dialogue de transaction en utilisant sa méthode from en passant le DTO de transaction comme paramètre. Ensuite, nous définirons le montant à envoyer texte à la boîte de dialogue de transaction. Le montant à envoyer définira le texte du champ des frais totaux le dialogue de transaction, frais totaux. Le texte total du champ du dialogue de transaction totalise le texte du champ de taux de frais dans le dialogue de transaction. Taux de commission concaténé avec la chaîne BTC slash KV. Morsure. Configurons l'adresse pour envoyer les textes de champ à l' adresse de dialogue de transaction à envoyer. Créons maintenant la méthode initialisée dans cette classe. Ici, le bouton d' annulation sera lié à une action qui fermera la fenêtre de dialogue. Pour ce faire, appelons la méthode Lookup Button sur la boîte de dialogue en lui passant le champ d'annulation. Ensuite, nous appellerons cette méthode pour ajouter un gestionnaire d'événements au bouton d'annulation. Le gestionnaire recevra un événement d'action et un événement comme paramètres. Et le corps du gestionnaire utilisera cette instruction pour fermer la fenêtre de dialogue. Passons maintenant au test d' envoi de Bitcoin. Il manque quelque chose dans ce test. Après avoir appelé la méthode send Bitcoin and wait, nous devons demander au nœud de miner un bloc afin que notre UTXO soit confirmé et puisse être utilisé pour créer une transaction. Pour gérer cela, appelons la méthode generate to address sur le nœud generate pour adresser le client en lui transmettant ces paramètres. Et déplaçons cette ligne de code ici. Maintenant, exécutons notre nœud. Et faisons ce test. Comme prévu, le test a échoué, mais le dialogue de transaction s'est ouvert et a été rempli avec les données de transaction. Maintenant, améliorons ce test. Vérifiera si les valeurs du dialogue de transaction sont correctes. Mais d'abord, rendons ce test plus résilient. Après avoir cliqué sur le bouton d'envoi code sera ajouté pour nous assurer que nous attendons le dialogue de transaction apparaisse avant d'agir sur la fenêtre de dialogue. Créons donc le poids pour la méthode du dialogue. Ici, nous appellerons le poids par méthode. transmettre ces paramètres à un délai d'attente fait de transmettre ces paramètres à un délai d'attente de secondes dans le corps du lambda compliquera le dialogue et ne reviendra qu'une fois qu' il n'est pas nul. Maintenant, obtenons la valeur de chaque étiquette dans le dialogue de transaction et stockons-la dans les variables suivantes. Ajoutons le type de ligne de transaction ici. Et changeons le nom de la vue tabulaire en table des transactions. Dans le bloc then, ajoutons les assertions suivantes pour vérifier si les étiquettes du dialogue de transaction sont correctes. Maintenant, dans le bloc where, ajoutons un scénario de test pour renseigner les variables que nous venons de référencer dans le bloc then. Il manque un signe d' égalité ici. Réglons ça. Ajoutons un autre scénario de test. Maintenant, supprimons ces lignes. Adaptera le code pour créer les transactions précédentes en fonction de la variable numérique UtxOS précédente. Ainsi, pour chaque UTXO défini dans cette variable, l'adresse de réception sera recherchée. Ensuite, nous appellerons la méthode send Bitcoin and wait avec ces paramètres. Maintenant, remplaçons le paramètre dans l'appel de méthode approprié par la variable montant à envoyer. Maintenant, nous devons nous assurer que le taux de frais est égal à 0,0 002 pour que le test fonctionne. Pour ce faire, nous allons injecter le service de frais d'estimation des nœuds dans cette classe et y ajouter la fausse annotation Bean. Ensuite, dans la méthode de configuration, ajoutons le code suivant. Il s'assurera que lorsque la méthode d'estimation du service sera appelée, il renverra la méthode d'estimation du service sera appelée, le taux de frais que nous voulons. périmètre de cette méthode de recherche ne contient pas la lettre S à la fin. C'est le total des frais. Maintenant, faisons le test. Cela échoue, mais pour une mauvaise raison, notez que l'étiquette du montant à envoyer est vide. C'est parce qu'il existe une autre étiquette avec le même ID FX dans le contrôleur d'onglet Envoyer. Il existe également un champ d'adresse à envoyer avec le même identifiant FX. Passons au deuxième contrôleur de dialogue des transactions pour résoudre ce problème. Renommons ce champ pour qu'il revienne à envoyer un dialogue. Et renommons l'adresse à envoyer champ en adresse pour envoyer le dialogue. Passons à la boîte de dialogue d'envoi de transaction FXML pour modifier les étiquettes FX IDs. D'accord, nous n'avons pas à le faire, car l'IDE a fait ce travail pour nous. Revenons au test d'envoi de Bitcoin. Mettons à jour ces paramètres pour rechercher les étiquettes correctes. Maintenant, faisons notre test. D'accord, les tests ont échoué, mais uniquement parce que la table des transactions ne contient pas le nombre de transactions attendu. Cela signifie que les libellés des dialogues de transaction sont corrects. Génial. 55. Comment fonctionnent les signatures des transactions: Dans cette présentation, nous allons montrer comment fonctionnent les signatures de transactions. Examinons d'abord les champs d'une entrée de transaction. Les entrées de transaction comportent un champ d'identification de transaction dont le contenu indique de quelle transaction provient l' UTXO dépensé dans cette entrée. Le champ d'index de sortie indique quel UTXO de la transaction précédente est dépensé. Ensemble, les deux champs forment un point de sortie qui indique sans équivoque quel UTXO, l'entrée dépense. Le champ ScriptSig est vide pour les entrées de transaction Segue et contient des scripts de déverrouillage pour les entrées de transaction non séquentielles. Ce script de déverrouillage est une signature et une clé publique pour les transactions courantes. Enfin, l'entrée de transaction contient le champ de séquence de fin. Le champ de fin de séquence définit le moment où l'entrée est valide pour être dépensée. Ce champ est ignoré lorsque sa valeur est égale à la valeur hexadécimale maximale pour sa taille. Pour les entrées de transaction Segue, le contenu qui, pour les transactions non Segway se trouve dans le ScriptSig est déplacé vers le champ témoin. La signature dans ce champ est une signature ECDSA obtenue à l'aide de la clé privée utilisée pour obtenir l' adresse de l'UTXO. L'intrant, c'est la dépense. L'autre champ du témoin est la clé publique, qui est dérivée de la clé privée nous venons de faire référence. Mais attendez, qu'est-ce qu' une signature ECDSA ? Ecdsa est l'abréviation Elliptic Curve Digital Signature algorithm. Il s'agit d'un algorithme de signature qui combine une clé privée et un message pour produire une signature. Et la signature ECDSA possède une propriété qui permet de vérifier si elle est valide, c'est-à-dire vérifier si une signature donnée a été produite par une clé privée donnée et un message à l'aide la clé publique dérivé de cette clé privée, du message et de la signature. Ainsi, nous pouvons vérifier si une signature est valide sans révéler la clé privée utilisée pour la générer. Vous pouvez utiliser l'ECDSA pour signer le message de votre choix. Dans le cas d'une signature de transaction, le message en cours de signature est une version modifiée de la transaction sérialisée. Voyons donc comment les transactions Bitcoin sont signées. Pour signer une transaction, vous devez signer chaque transaction saisie séparément. Pour chaque transaction, entrez commençant par une transaction insensée, c'est-à-dire une transaction dont les entrées contiennent un script vide, des CIGS et des témoins. Vous créez un hachage de signature, qui correspond au hachage d' une version modifiée de la transaction sérialisée. Pour ce faire, vous utilisez un algorithme de hachage de signature, que nous expliquerons dans la diapositive suivante. Le hachage de signature sera le message à signer avec une clé privée valide pour cette entrée et le hachage de signature utilisera l'ECDSA pour générer la signature. N'oubliez pas que la clé privée valide pour une entrée est la même que celle utilisée pour générer l'adresse à partir de l'UTXO que l'entrée dépense. Si l'entrée est une entrée segmentée, ajoutez la signature et la clé publique dérivées de la clé privée référencée au témoin. Sinon, ajoutez ces éléments au champ ScriptSig en entrée. Lorsque les nœuds reçoivent une transaction, ils vérifient si les signatures de transaction sont valides. Pour ce faire, ils utilisent l'algorithme de vérification de signature cité dans la diapositive précédente. Ils le font lors de l'exécution du script , comme expliqué dans la dernière présentation. Voyons maintenant comment le hachage de la signature est généré. Il existe différents algorithmes de hachage de signature pour les entrées de transaction segmentées, non segmentées et tap-root. Cependant, les trois algorithmes modifient la transaction d'une manière ou d'une autre et produisent un hachage, qui est le message qui sera signé. Voyons l'algorithme de hachage de signature pour les entrées d'un segment. Pour créer un hachage de signature pour une entrée de transaction donnée, commencez par une chaîne vide, puis ajoutez la version de la transaction à la chaîne, concaténez tous les points de sortie à partir des entrées de transaction. Hachez les résultats à l'aide de l'algorithme de hachage 256, ajoutez le hachage obtenu à la chaîne, puis concaténez toutes les entrées et séquences. Hachez 256 le résultat et ajoutez le hachage à la chaîne. Ajoutez maintenant le point de sortie de l'entrée à signer à la chaîne. Ajoutez à la chaîne la clé de pub du script UTXO dépensé par l'entrée signée. Ajoutez le montant des UTXO dépensés par l'entrée à signer à la chaîne. Ajoutez la séquence de fin de l'entrée à signer à la chaîne, concaténez toutes les sorties de transaction. Hash 256, le résultat, ajoute le hachage résultant à la chaîne, ajoute le temps de verrouillage de la transaction à la chaîne. Ajoutez le type de hachage, qui correspond au sig hash pour les transactions courantes, à la chaîne. Il existe d'autres types de hachage, mais ils sont rarement utilisés. Ils définissent les entrées et les sorties. L'entrée en cours de signature peut figurer dans une transaction. Signez Hash. Tout signifie que la signature produite n'est valide que dans une transaction avec toutes les entrées et sorties de la transaction donnée. Enfin, hachez 256, la chaîne obtenue. Le résultat est le hachage de signature pour l'entrée à signer. Un hachage de signature doit être obtenu pour chaque transaction saisie. Le processus est répliqué par les nœuds lorsqu'ils vérifient les signatures de transaction. 56. Comment notre portefeuille et notre nœud vont gérer les transactions envoyées: Cette présentation expliquera ce qui se passe lorsque nous envoyons une transaction à un nœud Bitcoin. Nous verrons ensuite comment notre portefeuille gère actuellement les transactions reçues et comment nous prévoyons de le modifier pour calculer correctement adresses des transactions et le solde total du portefeuille après l'envoi d'une transaction. Voyons donc comment un nœud Bitcoin gère les transactions envoyées par notre portefeuille. Notre portefeuille enverra les transactions à notre nœud via la méthode note RPC appelée send raw transaction. Notre application enverra la transaction de signe au format hexadécimal à notre nœud. Après avoir reçu la transaction, le nœud la valide. Si la validation est réussie, le nœud diffuse la transaction aux autres nœuds du réseau Bitcoin. Les autres nœuds font de même jusqu'à ce que tous les nœuds du réseau aient accusé réception de la transaction. La transaction reste gravée dans l'esprit pendant un certain temps, en attendant qu'un mineur l'inclue dans un bloc et qu'il mine le bloc avec celui-ci. Finalement, un mineur diffuse le bloc mental associé à la transaction aux autres nœuds du réseau. Lorsque les nœuds reçoivent le bloc mental associé à la transaction, la transaction est exclue du mental et est considérée comme confirmée. Chaque bloc ajouté après le bloc contenant la transaction ajoute une confirmation à la transaction. Il est recommandé d'attendre six conformations pour qu'une transaction soit considérée comme irréversible. Voyons maintenant un modèle naïf de la façon dont notre portefeuille peut gérer les transactions d' envoi. Une fois que notre portefeuille a envoyé une transaction à notre nœud, le nœud renverra via zéro MQ, la même transaction à notre application. Notre service de tâches de nœud détectera la transaction et l'enverra à notre écouteur recevant la transaction. Comme la plupart des transactions auront un résultat de modification, l' auditeur recevant la transaction vérifiera généralement que le changement d' adresse provient de notre portefeuille. Et nous utiliserons le service de mise à jour utxOS pour mettre à jour les adresses, les transactions et les soldes de nos portefeuilles , mais en nous basant uniquement sur la transaction reçue par l'auditeur, tel qu'il est actuellement pour mettre à jour notre le portefeuille soulèvera quelques problèmes. Tout d'abord, le calcul du solde du service UtxOS de mise à jour ne prend pas en compte les soldes d'entrée. Nous devrons donc modifier la façon dont notre portefeuille calcule une robe et les soldes des transactions afin d' actualiser les montants saisis par rapport aux montants de change. Mais nous devrons faire face à un problème plus important avec ce modèle. Qu'en est-il des transactions sans changement ? Dans ce cas, la transaction reçue auditeur ne considérera pas que la transaction de réception est la nôtre, car elle vérifie uniquement les adresses de sortie et le parfum ne proviendra pas de notre portefeuille. Ainsi, notre application ne serait pas mise à jour. Il est équilibré dans ces cas et adoptera la stratégie suivante pour surmonter ces problèmes lors de la mise à jour notre portefeuille après l'envoi de transactions. Après avoir envoyé la transaction à notre nœud, publiera un événement envoyé qui sera capturé par un écouteur de transaction envoyé. Ensuite, l'auditeur de l' envoi de la transaction utilisera le service de mise à jour utxOS pour mettre à jour le portefeuille avec la transaction afin d'éliminer le problème de ne pas mettre à jour les transactions sans modification, la fois la transaction l' écouteur reçu et le module d'écoute de réception du bloc utiliseront un client de transactions de liste de nœuds pour rechercher toutes les transactions liées à notre portefeuille dans le nœud, ce client enverra une liste de transactions RPC appelez notre nœud, qui renverra toutes les transactions pertinentes au client. Ensuite, en utilisant les transactions de retour, le service de mise à jour utxOS mettra correctement à jour toutes les transactions de notre portefeuille toutes les transactions de notre portefeuille et leurs soldes. 57. 55 Envoyer des bitcoin partie 8 skillshare 2: Dans cette vidéo, nous allons créer des classes et des services qui nous permettront de signer et d'envoyer des transactions. Commençons donc par créer une classe appelée transactions signer service dans le package api point services. Ajoutons l' annotation du service ici. Créons maintenant la méthode de signature ici. Il faudra un objet de transaction sur une base mnémotechnique, un mot de passe et une liste de DTL UTXO qu'une classe créera. Créons-le donc dans le package de domaines. Nous allons maintenant utiliser la méthode de plage de flux pour parcourir en boucle chaque UTXO DTO. Pour chaque DTO UTXO, nous appellerons la méthode de signe en passant le paramètre a, qui est l'indice de l'entrée à signer, la méthode UTXO DTO, qui sera obtenue en utilisant le paramètre i, la transaction, la graine mnémotechnique et le mot de passe du portefeuille. Créons cette méthode. Changeons le nom de ce paramètre en chaîne de départ mnémotechnique pour signer une entrée de transaction. Nous devons d'abord obtenir la clé privée valide pour déverrouiller l'UTXO dépensé par l' entrée. Si vous souhaitez vous rappeler comment cela se fait plus en détail, revoyez la présentation des portefeuilles HD et des adresses Bitcoin. Donc, d'abord, nous allons instancier un objet de départ mnémotechnique ici, en transmettant la chaîne de départ mnémotechnique et l'instanciation. Nous allons maintenant obtenir une clé principale en utilisant la méthode mnémotechnique seed to master key, car ses paramètres transmettront le mot de passe. Et ce préfixe. notre cas d'utilisation, il est possible de transmettre le préfixe privé réseau principal même si nous utilisons dans un autre environnement, car cela n' affecte que la sérialisation de la clé principale, non le processus de dérivation. Au cours du processus de dérivation de la clé principale méthode de la clé principale permet d' obtenir d'abord la graine de racine, qui est mentionnée dans la présentation mentionnée précédemment. Nous allons maintenant obtenir la clé privée étendue à l'aide la méthode CKD à clé principale, car son premier paramètre transmettra le chemin de dérivation UTXO DTO. Commençons par créer ce champ dans l'UTXO DTO. Et profitons de l' occasion pour ajouter le champ de montant qui sera ensuite nécessaire. Le paramètre suivant sera vrai, ce qui indique que nous voulons obtenir une clé privée étendue, une clé publique étendue. Le dernier paramètre sera le principal préfixe privé du réseau. Encore une fois, pas de problème en utilisant le préfixe réseau principal ici. Notez que la façon dont nous avons dérivé la clé privée étendue ici est similaire à façon dont nous dérivons la clé publique étendue et le service de clé publique étendue. Nous utilisons le même chemin de dérivation que celui que nous avons utilisé pour créer la clé publique étendue afin de dériver l'adresse UTXO de notre portefeuille. Maintenant, nous allons obtenir la clé privée souhaitée en l' extrayant simplement de la clé privée étendue par la méthode des deux clés privées. Cette méthode est disponible dans la prochaine version de Bitcoin Java. Passons donc au fichier POM pour le mettre à jour. Maintenant, dans un bloc try catch, nous pouvons enfin utiliser la méthode de signature de la classe de signature ECDSA de transaction de Bitcoin Java. Cette méthode prendra la transaction, la clé privée, l'indice d'entrée, le montant UTXO DTO converti en celui de Satoshi. Et le booléen vrai, qui indique que cette entrée est segmentée. La même méthode permet d'obtenir un hachage de signature avec la clé privée. Nous utiliserons l'ECDSA pour obtenir une signature pour cette entrée. Ensuite, il insérera la signature et la clé publique dérivées de l' ancienne clé privée dans le témoin de transaction. Le montant UTXO est nécessaire pour le hachage de la signature, et le dernier paramètre vrai est nécessaire pour générer correctement le hachage de signature et pour ajouter correctement la signature et la clé publique au témoin plutôt que dans le ScriptSig, ce qui est le cas pour les entrées non segmentées. Enfin, nous détectons une éventuelle IOException que la méthode sign peut lancer et encapsulons dans une nouvelle exception d'exécution. Créons maintenant le client de transaction brute node send dans le package client node point. Ce service sera nécessaire pour envoyer nos transactions à notre nœud Bitcoin. Ajoutons-y l' annotation du service. Injectons le client de nœud dans cette classe. Et créons la méthode d'envoi. Il acceptera une chaîne hexadécimale de transaction comme paramètre. Ici, nous appellerons la méthode make request du client node. Nous l'utiliserons pour appeler la méthode RPC du nœud Bitcoin Send Raw . Comme d'habitude, passons un nouvel objet de référence de type paramétré. Ici. L'URL est vide et nous allons transmettre le paramètre hexadécimal de la transaction comme dernier paramètre. Maintenant, dans le package de services GUI Dots, créons le deuxième service de transaction. Ce service sera chargé de signer et d'envoyer la transaction créative. Après avoir cliqué sur le bouton Envoyer dans la boîte de dialogue de transaction, ajoutons l' annotation du service à cette classe. Et créons la méthode de signature et d'envoi. Cela renverra un futur de type void. Et il prendra le DTO de la transaction et le mot de passe du portefeuille comme paramètres. Maintenant, nous allons d'abord créer une liste d'UTXO, CTO, en convertissant les UTXO sélectionnés à partir de la transaction DTO en convertissant les UTXO sélectionnés . Nous appellerons la méthode map sur le flux UTXO sélectionné et utiliserons le générateur UTXO DTO pour créer l'UTXO d t goes à partir de chaque objet UTXO. Injectons donc le générateur UTXO DTO dans cette classe. Créons-le dans le package GUI point services. Maintenant, créons cette méthode de compilation. Il renverra un UTXO DTO au service de transaction central. Ici, la méthode de liste appelée sur le flux résultant sera renvoyée . Refactorisons ici pour utiliser la référence de méthode au lieu d'un lambda. Maintenant, nous allons implémenter cette méthode. D'abord. Ajoutons l' annotation du service à cette classe. Ici, nous obtiendrons l'objet actuel de l'adresse du portefeuille correspondant à l'adresse UTXO reçue. Injectons donc d'abord le portefeuille actuel dans cette classe. Nous allons maintenant appeler la méthode get address, en passant l'adresse UTXO comme paramètre. Créons cette méthode. Il renverra un objet d'adresse. Ici, vous renverrez le résultat de l'appel de la méthode get addressed dans le champ adresses, en passant l' adresse reçue comme paramètre. Enfin, nous allons obtenir l'index actuel des adresses du portefeuille et le stocker dans la variable d'index d' adresse. Maintenant, nous allons obtenir la même adresse le portefeuille actuel et son type d'adresse, stockant dans la variable de type d' adresse. Nous allons maintenant obtenir le chemin de dérivation UTXO en appelant la méthode du chemin de dérivation de construction avec le type d'adresse et l'index d'adresse. Créons cette méthode. Ici. Nous utiliserons l'objet address configs pour obtenir une partie du chemin de dérivation. Injectons-le donc dans cette classe. En fait, ce sera une liste de configurations d' adresses. Réglons le problème. Maintenant, à partir du flux de configurations d'adresses, nous allons utiliser la méthode de filtrage pour sélectionner la configuration d'adresse valide pour le type d'adresse. Ensuite, nous utiliserons la méthode find first et obtiendrons la configuration d'adresse que nous voulons. Enfin, nous allons obtenir le chemin de dérivation à partir de la configuration de l'adresse et concaténer avec la chaîne suivante. Nous allons ajouter une barre oblique , puis l'index des adresses. Ici, vous renverrez un nouveau UTXO DTO en passant le chemin de dérivation et le montant UTXO. Revenons au service d'envoi de transactions. Ici, nous aurons besoin du service de signature de transactions. Injectons-le donc dans cette classe. Maintenant, nous allons appeler la même méthode car ses paramètres transmettront la transaction DTO, la graine mnémotechnique actuelle du portefeuille. Injectons donc le portefeuille actuel dans cette classe. Créons cette méthode dans le portefeuille actuel. Il renverra une chaîne. Ici, retournera le champ de semences mnémotechniques. Créons ce champ. Et ajoutons un setter pour ce champ. Le troisième paramètre de cette méthode est le mot de passe du portefeuille. Le paramètre suivant est le CTos UTXO. Maintenant, dans un bloc try-catch, nous utiliserons le client node send raw transaction pour envoyer une transaction signée à notre nœud. Injectons-le donc dans cette classe. Nous appellerons la méthode send dessus, transmettant la transaction. La transaction sérialisée DTL à l'aide la méthode sérialisée détectera une IOException et l'encapsulera dans une nouvelle exception d'exécution. Nous allons maintenant utiliser l' application Event Publisher. Injectons-le donc dans cette classe. Nous l'utiliserons pour publier un nouvel événement d'envoi de transactions en transmettant ce numéro et le DTO de transaction comme paramètres. Créons donc l'événement envoyé par transaction dans le package GUI point events. Changeons le premier paramètre de signature du constructeur pour accepter un objet. Et passons cet objet au super constructeur. Et définissons le champ DTO de transaction le DTO de transaction reçue. Ajoutons ce champ à cette classe. Et créons un getter pour cela. Nous utiliserons cet événement plus tard. De retour à la méthode sign and send un nouveau résultat asynchrone sera renvoyé ici, en passant null comme paramètre. Ajoutons l' annotation asynchrone à cette méthode en passant le service d'exécution par défaut comme paramètre. N'oubliez pas que nous faisons cela pour exécuter cette méthode de manière asynchrone, ce qui est notre politique lorsque nous communiquons avec notre nœud. D'accord, nous avons créé le champ de départ mnémotechnique dans la classe de portefeuille actuelle, mais nous devons maintenant le définir après avoir créé un nouveau portefeuille. Passons donc à l'enregistrement du portefeuille et ajoutons-y le champ de graines mnémotechniques. Passons maintenant au service de création de portefeuille et ajoutons la chaîne de départ mnémotechnique ici en tant que dernier paramètre de l'instanciation du portefeuille. Maintenant, dans le service de mise à jour du portefeuille actuel , définissons la graine mnémotechnique du portefeuille actuelle sur la graine mnémotechnique du portefeuille. Passons maintenant au deuxième contrôleur de dialogue transactionnel. Dans la méthode initialisée, appelons la méthode Lookup Button sur la boîte de dialogue en lui passant le bouton OK. Ajoutons maintenant un gestionnaire d'événements à ce bouton. Le premier paramètre est un événement d'action, qui définit le clic sur le bouton OK comme action. Le deuxième paramètre est une méthode Lambda qui prend un objet d'événement et appelle la méthode de transaction sign and send. Créons donc cette méthode. Ici. Nous aurons besoin du deuxième service de transaction. Injectons-le donc dans cette classe. Nous allons maintenant appeler la méthode Sign and Send qui s'y trouve, transmettant le DTO de la transaction et le texte du mot de passe du portefeuille comme paramètres. Enfin, nous allons fermer la boîte de dialogue en utilisant la méthode hide dans la fenêtre du volet de dialogue. Laissons fonctionner notre nœud. Et testons enfin ce que nous avons fait en lançant le test send Bitcoin. Super, les tests sont réussis. Le portefeuille a détecté notre transaction et l'a ajoutée au tableau des transactions. Mais attendez, il y a quelque chose d'étrange. Je vais revenir en arrière sur la vidéo et la mettre en pause dans la vue du tableau des adresses pour vérifier quelque chose. Voici le tableau des adresses après que notre portefeuille a envoyé notre transaction. Dans le premier cas de test, notez que le portefeuille a détecté que l'une de nos adresses de changement sur la deuxième ligne avait reçu des Bitcoins. Bien Mais comme l'adresse de la première ligne a son UTXO dans l'entrée de la transaction que nous venons d'envoyer, son solde actuel devrait être nul car sa sortie a été dépensée. Et comme notre tableau d' adresses indique uniquement les robes dont le solde est supérieur à zéro, ce tableau ne doit afficher qu' une seule ligne avec le changement d'adresse. Examinons maintenant le tableau des transactions pour le même scénario de test. Oups, le solde de la transaction que nous venons d'envoyer est erroné. Il devrait être égal à -0,5 bitcoin moins les frais de transaction. Le signe moins indique que nous avons envoyé une transaction depuis notre portefeuille. Le texte relatif à l'équilibre total est également erroné. Il doit être égal à 0,5 moins les frais de transaction. Dans la vidéo suivante, nous allons résoudre ces problèmes. 58. 56 Envoyer des bitcoin partie 9 skillshare 2: Dans cette vidéo, nous allons résoudre certains problèmes rencontrés dans la vidéo précédente. L'un de ces problèmes est que le tableau des adresses affiche des soldes périmés pour les adresses dont la sortie a été dépensée. Étant donné que l'adresse utilisée a un solde nul après utilisation, elle ne devrait pas apparaître dans le tableau des adresses. Ajustons donc ce test pour vérifier si la table d' adresses ne comporte qu'une seule ligne et si le solde de cette ligne égal au changement attendu dans Mount. Ici, nous allons obtenir la table des adresses en utilisant la méthode de recherche. Et dans le bloc then, vous vérifierez si la table des adresses comporte une ligne. Vérifions également si le solde de la première ligne est égal à cette variable, que nous définirons dans le bloc Web. Ensuite, définissons le montant de la variation dans les boîtiers noirs d'usure. Un autre problème que nous avons vu dans la dernière vidéo est que le solde de la transaction est erroné dans le tableau des transactions. Cela se produit parce que lorsque notre application reçoit une transaction de notre nœud, elle considère uniquement le solde des modifications comme solde de transaction pour s'assurer que le test détecte cette erreur, ajoutons la ligne suivante, puis block vérifiera si la première ligne du tableau des transactions a un solde égal à moins la variable totale dépensée. Le solde est également erroné puisqu'il est égal à la somme de tous les soldes des transactions. Faisons donc en sorte que notre test détecte ce problème. Ici. Nous vérifierons si le texte du solde total est correct. Définissons d'abord cette variable. Il sera égal au texte présent dans l' étiquette du solde total de la fenêtre une fois que nous aurons envoyé une transaction. Vérifie si cette variable est égale au texte suivant. Et ici, définissons la variable funds et la mettons à jour dans le lambda final. Maintenant, exécutons notre nœud. Et faisons ce test. OK, le test a échoué car la table des adresses comporte deux lignes. Réglons ces problèmes. Pour ce faire, créons les transactions envoyées par listener. Mais d'abord, réparons quelque chose de totalement indépendant. L' écouteur reçu par bloc se trouve dans le package node point events au lieu du package node point listeners. Réglons ça. Cela étant fait, créons un écouteur d' envoi de transactions dans le package GUI point listeners. Comme son nom l'indique, cet écouteur gérera l'événement de transaction envoyé que le service de transaction publiera après avoir envoyé une transaction. Ajoutons-y l' annotation du composant. Il implémentera l'écouteur de l' application avec le type d'événement transactions envoyées. Mettons en œuvre sa méthode. ici que se déroulera la mise à jour du service UtxOS. Injectons-le donc dans cette classe. Appelons maintenant la méthode de mise à jour transmettant la transaction événementielle DTO. Créons maintenant cette méthode. Nous obtiendrons ici une liste des UTXO issus de la transaction DTO a sélectionné les UTXO. Nous utiliserons une carte sur le flux UTXO sélectionné et instancierons un nouvel UTXO pour chaque UTXO reçu qui transmettra tous les champs UTXO reçus dans l'instanciation UTXO, l' exception du montant qui sera zéro puisque nous venons de le dépenser. Maintenant, pour mettre à jour les adresses de nos portefeuilles, nous allons appeler la méthode de mise à jour du service Update Current Wallet Addresses, lui transmettant les UTXO. Et pour mettre à jour les transactions du portefeuille, appelons la méthode de mise à jour sur le service de transaction Update Current Wallet transmettra le résultat de l'appel de la ligne de transaction de la méthode à celle-ci avec la transaction DTO comme paramètre. Enfin, appelons la méthode de mise à jour du service équilibré du portefeuille actuel méthode de mise à jour du service équilibré pour mettre à jour le solde actuel du portefeuille. Créons cette méthode from dans la classe de lignes de transaction. Ici, une nouvelle ligne de transaction sera renvoyée dans un bloc try-catch. Nous l'instancierons avec l' identifiant de transaction DTO de la transaction. Le montant total dépensé par la transaction formatée a été annulé à l'aide de la méthode de négation. Cela rendra la valeur négative puisque nous la dépensons. Il n'y aura aucune confirmation. Et sa date sera la date actuelle. Enfin, nous allons détecter une IOException qui peut être déclenchée par la méthode d'identification de transaction et rapidement dans le cadre d'une nouvelle exception d'exécution. Revenez au service Update UtxOS. Créons maintenant la méthode de mise à jour qui recevra une ligne de transaction dans la mise à jour. Le service de transaction Wallet actuel utilisera la méthode platform run later puisque le code suivant sera modifier l'interface du portefeuille. Ici, nous allons passer un lambda qui appellera la méthode add transaction row sur le portefeuille actuel pour passer à cette méthode. Maintenant, créons cette méthode. Déplaçons cette méthode vers cet emplacement proche de la méthode d'ajout de lignes de transaction. Ici, nous allons appeler la méthode add transaction row le champ des lignes de transaction, en passant la ligne de transaction comme paramètre. Créons cette méthode dans la classe des lignes de transaction. Ici, nous allons inscrire la transaction dans feuille de route de la transaction en utilisant l'ID de ligne de transaction comme clé. D'accord, avec ces modifications, nous nous attendons à ce qu'au moins la table des adresses soit mise à jour. Réexécutons le test d'envoi de Bitcoin pour le vérifier. D'accord, les adresses présentées maintenant sont correctes, mais le test a échoué à cause de la table des transactions. Le solde des transactions d'envoi est toujours obsolète. Cela s'est produit parce que même si notre écouteur de transactions sin correctement à jour la transaction, lorsque notre portefeuille reçoit la même transaction de notre nœud, il détecte une mise à jour est uniquement le changement d'adresse UTXO. Cela ne réduit pas les frais et les contributions que nous avons dépensées. Nous devons modifier la façon dont nous mettons à jour les transactions actuelles de notre portefeuille pour résoudre ce problème. Dans la mise à jour, la méthode de mise à jour du service UtxOS, qui est appelée une fois que notre application reçoit une transaction, appellera la méthode de liste des transactions RPC du nœud. Cette méthode remboursera toutes les transactions de notre portefeuille, y compris celles que nous envoyons suffisamment intelligemment pour renvoyer les transactions dont le solde est négatif si elles sont envoyées depuis notre portefeuille. Une fois ces transactions en main, nous pouvons les mettre à jour correctement dans notre application. Utilisons donc la liste des nœuds du client pour obtenir toutes les transactions de notre portefeuille et les stocker dans la variable de transactions du nœud. Injectons ce service dans cette classe. Et créons-le dans le package client point no point point point point point de l'API . Finissons de l' injecter dans cette classe. Maintenant, créons l'enregistrement de la transaction du nœud, qui modélisera le retour de la méthode des transactions de liste, créera dans le domaine et démarrera le package de nœuds. Ici, nous appellerons la méthode des transactions par liste, en transmettant le nom du portefeuille actuel. Construisons cette méthode. Et ajoutons l'annotation du service ici. Injectons le client de nœud dans cette classe. Ici, nous allons obtenir un tableau de type transaction de nœud en appelant la méthode make request du client node avec les paramètres suivants. La chaîne de transaction de liste, qui est le nom de la méthode RPC du nœud, une nouvelle référence de type paramétrée. L'URL du portefeuille concaténée avec le nom du portefeuille. Et une chaîne d'astérisque, qui indique que nous voulons que toutes les transactions proviennent de ce portefeuille. La valeur entière maximale, ce qui signifie que nous voulons obtenir le nombre maximum de transactions dans la réponse zéro, ce qui indique à la méthode que nous ne voulons ignorer aucune transaction. Et c'est vrai, ce qui indique que nous voulons surveiller uniquement les transactions incluses dans la réponse. Regardez, seules les transactions sont des transactions. Le nœud n'a pas la clé privée à dépenser. Cette option est logique car notre portefeuille ne transmet aucune clé privée à notre nœud. Enfin, nous avons renvoyé le tableau des transactions converti en liste. Créons maintenant le nœud. Les champs de l'enregistrement des transactions ajouteront uniquement les champs que vous utiliserez. s'agit du T XID, des confirmations, du montant, de l'adresse, qui est l'adresse à laquelle l'expéditeur a l'intention d'envoyer des bitcoins, non du changement d'adresse. Et l'heure, qui est l'horodatage de la création de la transaction. Revenez au service Update UtxOS. Nous appellerons la méthode des transactions du nœud de mise à sur le service de transaction Update Current Wallet. En tant que paramètre, les transactions du nœud seront transmises. Créons cette méthode. Ici, nous obtiendrons une liste des lignes de transactions à partir de l'option Aucune transaction. Nous appellerons la méthode de filtrage sur le flux de transactions du nœud. En tant que paramètre, il transmettra un lambda qui acceptera une transaction de nœud et vérifiera si le portefeuille actuel contient l'adresse de transaction du nœud. Ensuite, nous ajoutons un opérateur or et vérifions si le portefeuille actuel contient une transaction sans identifiant de transaction. Ce filtre produira un flux de transactions contenant uniquement les transactions destinées à envoyer, c'est-à-dire destinées à envoyer, c' recevoir des transactions. La condition selon laquelle l'opérateur or effectuera le flux transactions inclut également les transactions que notre application possède déjà. Cela signifie que le solde des transactions précédemment ajoutées par l'écouteur d' envoi de transactions sera correctement mis à jour avec des soldes négatifs. Maintenant, nous n'utiliserons pas le flux résultant en utilisant la méthode transaction row from. Créons cette méthode et déplacons-la ici. Ici, une nouvelle ligne de transaction instanciée avec l'ID de transaction du nœud sera renvoyée . Le montant de la transaction du nœud formaté, les confirmations de transaction du nœud et l' heure de transaction du nœud convertis en chaîne. Nous convertissons maintenant le flux de transactions en liste. Enfin, nous utilisons la méthode platform run later et, à l'aide d'un lambda, nous appelons « Ajouter des lignes de transaction » sur le portefeuille actuel en lui transmettant les lignes de transaction. Supprimons cette méthode car nous n'en aurons plus besoin. Supprimons également cette méthode dans la ligne de transaction pour la même raison. Encore une chose : dans la méthode des lignes de transactions publicitaires dans la classe des lignes de transactions, nous devons mettre à jour le solde des lignes de transaction avant que nos modifications ne prennent effet. Incluons donc le code suivant pour ce faire. Passons maintenant au test d' envoi de Bitcoin. Avant de l'exécuter, incluons l'appel en mode veille une fois que le test a cliqué sur le bouton OK dans la deuxième boîte de dialogue de transaction. Ainsi, nous évitons que le test échoue en raison des conditions de course. Maintenant, faisons notre test. Super, les tests sont réussis. Faisons tous les tests d'application pour nous assurer que nous n'avons rien cassé dans nos portefeuilles. Je vais accélérer la vidéo maintenant, car ces tests prendront quelques minutes à se dérouler en réalité. Génial. Tous les tests sont réussis. 59. 57 Envoyer des bitcoin partie 10 skillshare 2: Dans cette vidéo, nous ajouterons d'autres tests pour vérifier si notre portefeuille fonctionne comme prévu lors de l'envoi transactions dans différents scénarios. Voyons si notre portefeuille peut envoyer deux transactions l' une après l'autre. Pour ce faire, dupliquons ce test dans la classe de test send Bitcoin. Changeons son nom en. Il devrait envoyer du Bitcoin à Times. Corrigons sa mise en forme. Changeons le nom du portefeuille pour mon test à dix ans. Maintenant, extrayons cette section de code en une méthode. Nous appellerons cela envoyer du Bitcoin. Ajoutons le montant à envoyer comme deuxième paramètre. Après avoir créé une transaction, cliquez sur le bouton OK pour l'envoyer. Ensuite, nous utiliserons cette ligne de code pour transformer notre nœud en bloc. Nous nous attendons donc à ce que notre deuxième transaction soit confirmée, ce qui nous permettra d'utiliser la modification UTXO générée par cette transaction comme entrée lors de la prochaine transaction. Nous allons maintenant cliquer sur l'onglet Envoyer. Et nous appellerons la méthode sleep avec ces paramètres pour attendre confirmation de notre transaction. Après avoir envoyé la première transaction, nous nous attendons à ce que notre premier changement d'adresse apparaisse dans le tableau des adresses. Nous nous attendons à ce qu'une adresse de changement différente soit utilisée lors de la deuxième transaction, car il est important de ne pas réutiliser les adresses lors réception de Bitcoins pour des raisons de confidentialité. Nous allons donc comparer le changement d'adresse dans les deux transactions et vérifier si elles ne sont pas égales. Pour ce faire, examinons le tableau des adresses à l' aide de cette ligne de code. des raisons d' exactitude, changeons le type TableView Pour des raisons d' exactitude, changeons le type TableView en ligne d'adresse. Supprimons la déclaration ici et profitons de l' occasion pour résoudre le même problème dans la méthode de test précédente. Stockera la première adresse de modification dans cette variable, en l' extrayant à partir de la table des adresses. Ensuite, nous appellerons à nouveau la méthode send Bitcoin pour envoyer la deuxième transaction. Après la deuxième transaction vous consulterez à nouveau la table des adresses. Espérons que la première ligne du tableau contiendra la deuxième adresse de modification. Nous allons donc l'interroger à nouveau et stocker l'adresse de la première ligne et la deuxième variable d' adresse de modification. Dans le bloc then, vous ajouterez l'assertion suivante pour vérifier si la première adresse de changement n'est pas égale à la seconde. Ici, nous nous attendons à ce que la taille de la table des transactions soit égale au nombre UTXOS précédent plus deux. Et changeons cette partie du texte du solde total. Nous nous attendons à ce que le solde confirmé soit égal aux fonds moins le total dépensé. Supprimons ce scénario de test, nous n'aurons qu'un seul cas pour ce test. Changeons le montant pour envoyer 0,25. Mettons à jour le total des dépenses en conséquence. Et changeons les quatre derniers chiffres du montant de la modification. Ce montant de variation est la somme des montants de variation des deux transactions. Maintenant, exécutons notre nœud. Ajoutons l' annotation Ignorer au premier test, car nous voulons exécuter uniquement le dernier test. Et exécutons-le. Le test a échoué car la première adresse de modification est égale à la deuxième adresse de modification. Réglons ce problème. Passons à la mise à jour des adresses de portefeuille actuelles service déplacera cette ligne de code vers cet emplacement. Ici, nous allons ajouter une instruction if pour vérifier si l'adresse mise à jour est une adresse de changement. Ajoutons cette constante à cette classe. Ce sera égal au type d'adresse que Seg changerait. Dans le corps de l'instruction if, définira l' adresse de changement de portefeuille actuelle à l'adresse suivante. Ajoutons également une instruction return au corps de cette instruction if. Refaisons le test. Super, le test est passé. Nous allons maintenant commencer à mettre en œuvre une gestion des erreurs dans les situations où les choses ne se passent pas bien lorsque nous essayons envoyer des transactions, par exemple que devrait-il se passer si nous utilisons le mauvais mot de passe de portefeuille lorsque tentative d'envoi d'une transaction. Lorsque notre portefeuille envoie une transaction avec un mot de passe incorrect, cela entraîne la création de la transaction avec des signatures non valides. Lorsque notre nœud le reçoit, il essaie de valider cette transaction. Comme ses signatures sont erronées, il renverra un message d'erreur et ne relayera pas la transaction aux autres nœuds. Actuellement, notre portefeuille ne gère pas l'erreur renvoyée et échouera silencieusement. Créons une solution à cette situation. Notre nœud renvoie une erreur après avoir reçu notre transaction et affichera l'utilisateur une alerte d'erreur indiquant que le portefeuille n'a pas pu envoyer la transaction. Et y. Tout d'abord, créons un test pour ce scénario. Dans la classe de test Send Bitcoin. Dupliquons la première méthode. Renommez-le en « ne devrait pas envoyer de Bitcoin avec un mauvais mot de passe ». Et ajustons sa mise en forme. Changeons également le nom du portefeuille en mon portefeuille de test 11. Ici, nous allons cliquer sur le champ du mot de passe. Définissons une variable pour ce mot de passe. Définissons-le avec mon mot de passe de test et écrivez-le dans le champ du mot de passe. Après avoir reçu des Bitcoins, stockons le solde formaté dans la variable fonds formatés. Comme nous ne parviendrons pas à envoyer une transaction, nous nous attendons à ce que le solde final de notre portefeuille ne change pas et continue d'être égal à cette variable. Maintenant, remplaçons cette section de code par un appel à la méthode send Bitcoin. Une fois que la boîte de dialogue de transaction apparaît, nous cliquons sur le champ du mot de passe du portefeuille. Et nous allons écrire le mauvais mot de passe. Après avoir cliqué sur le bouton OK, nous nous attendons à ce qu'un message d'erreur apparaisse. Définissons ce message d'erreur et stockons-le dans cette variable. Ensuite, avec ce code, essaiera de stocker le nœud avec ce message dans la variable de requête du nœud. L'alerte d'erreur comportera un bouton OK sur lequel vous essaierez de cliquer. Dans le bloc then, vérifiera si le texte de la requête du nœud est égal au message d'erreur. Vérifiera également si le solde de l'adresse dans le tableau des adresses est égal à celui de la variable fonds formatée. Nous nous attendons à ce que la taille de la table des transactions soit égale à un, car nous n'afficherons pas la transaction échouée dans le tableau. Modifions également le solde de transaction attendu ici pour qu'il soit égal aux fonds formatés. Nous nous attendons également à ce que le solde total et le solde confirmé soient égaux à la variable des fonds formatés. Le solde non confirmé attendu doit être égal à zéro avec huit décimales. Supprimons le deuxième scénario de test dans le bloc where. Implémentons maintenant la fonction d'alerte d'erreur. Dans le deuxième service de transaction. Ajoutons une instruction catch ici pour détecter une erreur interne au serveur. Il s'agit du type d'erreur que le nœud renverra en cas problème lorsque nous essaierons de lui envoyer une transaction. Nous allons maintenant utiliser l'enregistreur pour enregistrer cette erreur. Ajoutons donc l'enregistreur à cette classe en tant que champ statique. instanciera en utilisant la méthode logger factory get logger, en transmettant cette classe comme paramètre. Ensuite, nous appellerons la méthode d'erreur qui s'y trouve, en transmettant le corps de la réponse error get sous forme d'appel de méthode de chaîne. Ensuite, nous renverrons l'appel de la méthode d'erreur du gestionnaire d'erreurs de nœud en lui transmettant l'erreur. Injectons le gestionnaire d'erreurs de nœud dans cette classe. Créons cette classe dans le package de services GUI dots. Finissons de l' injecter dans cette classe. Créons-y cette méthode. Il renverra une future erreur de type. en revenir à l'emplacement qui l'appellera, nous voyons que l'identifiant indique une erreur de type. Pour résoudre ce problème, changeons le type de retour du signe et la méthode d'envoi par une erreur de type future. Mais d'abord, créons l' enregistrement d'erreur dans le package de nœuds à points du domaine. Copions cette ligne et collons-la ici. Nous allons le modifier pour importer cette classe d'erreur que nous venons de créer. Si nous ne le faisons pas, Java utilisera sa classe d'erreur intégrée. Maintenant, changeons ce paramètre de type en erreur. Passons également la ligne d'importation à cette classe. Ajoutons-y une annotation de service. Maintenant, avant de continuer à implémenter la fonctionnalité, exécutons le dernier test pour vérifier le format du message d'erreur renvoyé par le nœud dans les journaux. Tout d'abord, ajoutons l' annotation Ignorer à ce test. Nous n'effectuons donc que le dernier test. Ici, nous voyons que le nœud est retourné au message JSON. La partie importante indique que le script a échoué et que 0 p équivaut à une opération de vérification. Cela signifie que le nœud a échoué en raison d'une signature incorrecte lors l' exécution du script combiné pour valider la transaction. Maintenant que nous savons ce que le nœud renvoie à l'application lorsque le mot de passe du portefeuille est erroné, associons cette réponse au mot de passe incorrect que nous voulons que l'utilisateur voie. Dans le gestionnaire d'erreurs du nœud. Ajoutons un bloc try-catch qui convertira l'erreur reçue en un objet wrapper d'erreur de nœud. Créons donc cet enregistrement dans le package de nœuds à points des domaines. Après la réponse adjacente à l'erreur de nœud la spécification ajoutera un champ d'erreur de type erreur de nœud ici. Créons donc l'enregistrement d'erreur de nœud dans le package de nœuds à points du domaine. Il comportera un champ de code et un champ de message. De retour au nœud, le gestionnaire d'erreurs aura besoin du mappeur d'objets. Injectons-le donc dans cette classe. Nous allons maintenant appeler la méthode read value sur le mappeur d'objets car ses paramètres transmettront l'erreur get response body sous forme d'appel de méthode de chaîne. Et la classe Node Error Wrapper. Ce code convertira l'erreur reçue en un objet d'encapsulation d'erreur de nœud. Enfin, nous allons renvoyer un nouvel objet de résultat asynchrone instancié avec un objet d'erreur. Pour instancier l'objet d'erreur, nous utiliserons la méthode error from transmettant l'erreur node error wrapper en tant que paramètre. Créons la méthode frontale. Il renverra un objet d'erreur. Ajoutons le champ de message à cet enregistrement. La méthode front renverra un nouvel objet d'erreur instancié avec un message d'erreur. Pour créer le message d'erreur, ajoutons le champ des messages d'erreur dans cette classe. Ce champ sera chargé de mapper les messages d'erreur du nœud les messages que nous voulons afficher. Ce sera une carte des clés de chaîne et des valeurs de chaîne. Utilisons la carte des méthodes pour le créer. Sa première clé sera le message d'erreur renvoyé par le nœud, que nous avons vu précédemment dans les journaux de l' application. La valeur sera le message d'erreur que nous voulons afficher. Pour cela, nous utiliserons le mauvais mot de passe constant issu de la classe de messages d'erreur que nous allons créer. Créons donc cette classe dans le package de nœuds à points des domaines. Et ajoutons-y cette constante avec le message que nous voulons afficher. Maintenant, nous allons appeler la méthode Get ou default dans le champ des messages d'erreur de la méthode du formulaire, son premier paramètre sera le message d'erreur. Son deuxième paramètre sera un message par défaut, que nous définirons dans cette constante. Ainsi, si le nœud renvoie un message d'erreur que nous n'avons pas encore mappé, le message d'erreur affiché indiquera qu'une erreur s'est produite. Revenez au gestionnaire d'erreurs du nœud. Ajoutons une instruction catch ici pour exception de traitement adjacente que le mappeur d'objets peut lancer. Ensuite, nous l'encapsulons dans une exception d'exécution et nous la lançons. Passons maintenant au deuxième contrôleur de dialogue transactionnel. Ici, nous allons obtenir le résultat de la méthode sign and send et le stocker dans une variable. Assurez-vous simplement d'importer la classe d'erreur correcte. Nous allons maintenant avoir besoin du service d'alerte aux erreurs. Injectons-le donc dans cette classe. Ce service sera chargé d' afficher une alerte avec un message d'erreur. Créons-le dans le package de services GUI dots. Et finissons de l' injecter dans cette classe. Appelons maintenant la méthode d'erreur de gestion sur l'erreur d'alerte ou l' objet de service qui lui transmet le résultat. Créons cette méthode. D'abord. Ajoutons l' annotation du service à cette classe. Ici, nous allons déclarer un objet d'erreur. Ensuite, dans un bloc try-catch, la variable d'erreur sera définie sur l'appel de la méthode result point get. Ensuite, nous allons détecter une exception que le résultat peut générer et l'encapsuler dans une nouvelle exception d'exécution. Maintenant, dans cette instruction if, on vérifiera si l'erreur n' est pas égale à zéro. Si ce n'est pas le cas, nous appellerons la méthode d'erreur d'alerte lui transmettant le message d'erreur. Créons cette méthode. Ici. Nous allons créer un nouvel objet d'alerte avec une erreur de type d'alerte. Ensuite, nous définirons le titre de l' alerte comme erreur. Et nous allons définir le texte de l' en-tête de l'alerte sur une erreur ou deux. Configurons le texte du contenu de l'alerte sur la variable de message. Enfin, appelons la méthode show sur l'objet d'alerte. Maintenant, relançons le test. Super, le test est passé. 60. 58 Envoyer des bitcoin partie 11 Skillshare 2: Dans cette vidéo, nous continuerons à ajouter d'autres validations et alertes pour informer l'utilisateur des tentatives de transfert infructueuses. Tout d'abord, nous allons créer des scénarios de test pour ces scénarios. Dupliquons donc ce test pour ajouter un test pour le scénario dans lequel l' utilisateur souhaite envoyer une transaction avec plus de bitcoins que ses fonds. Renommez-le en ne devrait pas envoyer Bitcoin sans fonds supérieurs montant plus v. Reformatons-le. Et changeons le nom du portefeuille pour mon test à 12 ans. Supprimons ces lignes. Ici. Nous définirons une variable de message d'erreur correspondant au contenu que nous voulons que l' utilisateur voie pour corriger l'erreur Le message sera « Impossible d'envoyer transaction, fonds insuffisants ». Ensuite, avec ce code, essaierai de stocker l'élément d'interface utilisateur avec ce message dans la variable de requête node. Et nous essaierons de cliquer sur le bouton OK dans la boîte de dialogue d'alerte. Dans le bloc then, vous vérifierez si le texte de la requête du nœud est égal au message que nous avons défini précédemment. Supprimons ces variables dans le bloc where car nous n'en aurons pas besoin. Et créons ici la variable de montant précédente avec la valeur suivante. Dupliquons cette ligne pour créer un deuxième scénario de test. La valeur de ce montant sera inférieure d' un satoshi la valeur nécessaire pour envoyer 0,5 bitcoin. Maintenant, supprimons cette ligne. Remplaçons ces valeurs par la variable de montant précédente. Nous allons maintenant créer un scénario de test similaire, mais cette fois en utilisant un portefeuille sans fonds. Dupliquons donc ce test. Changeons son nom pour ne pas envoyer de Bitcoin sans fonds. Changeons le nom du portefeuille pour mon test à 13 ans. Supprimons ces lignes car nous ne recevrons aucun fonds. Et laissons uniquement le montant à envoyer variable et le bloc where. Implémentons maintenant cette fonctionnalité dans la classe de service create transaction. Stockons le DTO de la transaction dans une variable ici. Et renvoyons cette variable. Maintenant. Avant de revenir, il appellera la méthode de validation des fonds en transmettant le DTO de la transaction comme paramètre. Créons cette méthode. Utilisera cette méthode pour valider si la somme des montants d'entrée de la transaction est supérieure à la sortie de la transaction pour certains. Créons donc cette variable pour stocker le montant saisi. Certains attribueront le résultat de l'appel à la transaction DTO, y obtiendront les quantités de méthode saisies. Créons cette méthode. Ici. Nous utiliserons une carte sur le flux UTXO sélectionné pour créer un flux de montants UTXO. Ensuite, nous utiliserons la méthode réduite pour additionner chaque montant obtenu. Enfin, nous utiliserons la méthode or else pour renvoyer la somme ou zéro si aucun UTXO n'est disponible. Maintenant, créons la méthode get output amounts de la méthode ici. Nous utiliserons une stratégie similaire pour certains montants de production. Mais au lieu d'utiliser les UTXO sélectionnés, ils utiliseront une carte sur le flux de sortie de la transaction. La méthode cartographique renverra les montants de sortie convertis en Bitcoin. Et nous utiliserons la méthode reduce et une méthode Rails de la même manière que nous l'avons fait pour la méthode précédente. Revenons à la méthode de validation des fonds. Ici, nous allons créer une variable de sortie pour stocker le résultat de l'appel des montants de sortie. Une méthode que nous venons de créer. Nous allons maintenant ajouter une instruction if pour vérifier si la somme d'entrée est inférieure à la somme de sortie plus le total calculé F0. Si tel est le cas, nous lançons une nouvelle exception de création de transaction avec le message «  fonds insuffisants ». Créons cette constante dans la classe des messages d'erreur. Faisons en sorte que les deux constantes soient finales. Et créons la classe d'exception create transaction dans le package d' exceptions par points de l'interface graphique. Il étendra l'exception d'exécution et transmettra son message au super constructeur. Profitons de l'occasion pour ajouter une autre validation ici. Et si nous essayions d'effectuer une transaction sans avoir à charger le portefeuille ? Pour gérer ce cas , utilisons cette instruction if pour vérifier si le portefeuille actuel possède des adresses. Si ce n'est pas le cas, nous lançons une exception de création de transaction avec un message indiquant que le portefeuille n' est pas chargé. Créons cette constante pour stocker ce message. Passons maintenant au contrôleur de l'onglet Envoyer. Enveloppons la création du DTL de la transaction dans un bloc try-catch. La méthode du dialogue ouvert appelle à. Voilà, nous allons l'attraper. Créez une exception de transaction. Nous utiliserons l'erreur ou le service d'alerte et le corps du capteur. Injectons-le donc dans cette classe. Ensuite, nous appellerons la méthode d'erreur d' alerte en transmettant le message d'exception comme paramètre. Rendons cette méthode publique. Passons au test d' envoi de Bitcoin. Ajoutons l' annotation Ignorer au test que nous avons effectué dans la dernière vidéo. Laissons fonctionner notre nœud. Avant de lancer le test, ajustons quelques détails. Ajoutons un point à la fin des messages d'erreur. Dans la méthode d'envoi de Bitcoin. Ajoutons ce paramètre. La valeur par défaut est true et n'appellera la méthode de dialogue wafer que si elle est vraie. Maintenant, définissons-la sur false et ces appels, car le dialogue de transaction n'apparaîtra pas dans ces tests. Enfin, lançons les tests. Note : les tests sont réussis. Supprimons toutes les annotations ignorées de cette classe. Nous allons maintenant ajouter un tas de nouveaux tests dans une nouvelle classe appelée send Bitcoin additional test dans ce package. Mais ne vous inquiétez pas, cette fois, nous allons simplement copier le contenu de ce cours depuis la page Projet et ressources. Tous ces tests doivent réussir. J'espère que nous n'aurons rien à changer dans notre code pour cela. Mais ils nous aideront à garantir que notre portefeuille enverra correctement les transactions et à détecter d' éventuelles cassures de code à l'avenir. Reformatons-les tous. Lors du premier test, nous vérifierons si un portefeuille avec un mot de passe envoie correctement les transactions. Le prochain test générera des transactions sans il soit nécessaire de les modifier et vérifiera si leurs paramètres sont corrects. Ce test tentera d'envoyer une transaction à l'adresse de notre propre portefeuille et de vérifier si le portefeuille calcule correctement ses montants et ses soldes. Enfin, le dernier test comportera de nombreux cas de test différents avec un nombre et des montants différents d'UTXO précédents. Pour que ces tests fonctionnent, transférons le poids de la méthode de dialogue dans le test send Bitcoin à la classe de test GUI. Faisons en sorte qu'il soit protégé. Supprimons ces importations dans le test d'envoi de Bitcoin. Encore une chose dans la méthode send Bitcoin dans le test send Bitcoin, ajoutons le super mot clé ici pour nous assurer que nous appellerons le poids correct pour la méthode de dialogue, non le paramètre avec le même nom. Nous ferons un autre test dans cette classe. Cette fois, nous allons vérifier ce qui se passe lorsque nous essayons d'envoyer une transaction avec une quantité infime. Dupliquons donc ce test. Changeons son nom pour qu'il ne fasse pas couler de la poussière Bitcoin. Corrigons sa mise en forme. Changeons le nom de son portefeuille pour mon test à 18 ans. Maintenant, copions ce code et ajoutons-le à notre méthode pour approvisionner notre portefeuille. Modifions le message d'erreur en « Impossible d'envoyer montant de la transaction à envoyer est poussière ». Changeons le bloc where en y ajoutant les variables suivantes. Nous choisirons une quantité à envoyer égale à 293 Satoshi, ce que nous savons que notre nœud ne peut pas accepter car cela sera considéré comme de la poussière. Pour le montant précédent , choisissez 0,1 bitcoin. Puisque nous ferons confiance à notre note pour détecter ce type d'erreur, attendrons que le dialogue de transaction nous attendrons que le dialogue de transaction apparaisse après avoir cliqué sur le bouton Envoyer. Et ajoutons le clic sur l'appel de méthode du bouton OK pour confirmer la transaction du dialogue. Passons maintenant à la classe d'erreur. Ajoutons l'entrée suivante à la carte des messages d'erreur. La carte associera l'erreur de message de poussière reçue de notre nœud au message présent dans la constante de poussière de la classe des messages d'erreur. Créons cette constante. Il sera égal au message que nous venons de définir dans le test. Ajoutons l' annotation ignore aux autres tests de cette classe et lançons notre nouveau test. Super, le test est passé. Supprimons toutes les annotations ignorées que nous avons ajoutées précédemment. À ce stade, je recommande d'exécuter tous les tests d'application. C'est ce que j'ai fait et ils ont tous réussi. Je ne le montrerai pas dans cette vidéo car cela prendrait plusieurs minutes. Je vais laisser cet exercice à l'étudiant. 61. 59 Segwit imbriqué, partie 1 de partage de compétences 2: Dans cette vidéo, nous allons commencer à refactoriser notre application pour la préparer, afin d' ajouter la prise en charge d'un plus grand nombre de types d'adresses. Ce sera une refonte relativement importante, mais nous verrons plus tard qu'elle nous permettra ajouter la prise en charge d' autres types d'adresses, tels que l'adresse imbriquée . L'idée de cet acteur de référence est de centraliser tout ce qui spécifique à un type d'adresse dans un objet de configuration d'adresse. Ce faisant, nous serons en mesure d' ajouter d'autres types d'adresses à nos portefeuilles en ajoutant nouveaux objets de configuration d'adresses au projet. Après avoir effectué cette refactorisation, nous ajouterons un nouveau type d'adresse appelé segment imbriqué, dont nous expliquerons l'importance dans quelques vidéos. Passons donc à l'enregistrement de configuration de l' adresse pour ajouter quelques champs. Nous allons ajouter le champ générateur d'adresses. Nous l'utiliserons pour définir le service utilisé pour générer des adresses pour différents types d'adresses. Une carte avec une clé d' énumération d'environnement et une valeur de chaîne. Nous utiliserons ce champ pour enregistrer les préfixes d'adresse pour chaque environnement. Créons-en donc suffisamment. Dans le package BYU w point domains. Il contiendra les constantes de test main net, test net et reg. Ajoutons le champ de préfixe ki étendu ici. Comme son nom l'indique, il définira le préfixe de la clé étendue qui générera les adresses. Le champ suivant sera une chaîne de prédicat en tant que paramètre de type. Il recevra une fonction lambda avec une adresse comme paramètre et une expression qui renverra true si l'adresse correspond au type de configuration de l' adresse et False. Sinon, nous ajouterons un champ de type de clé de pub de script afin pouvoir identifier la configuration d' adresse à utiliser en utilisant le type de clé de pub de script. Ensuite, nous l'ajouterons par fonction avec ces paramètres de type utiliserons ce champ pour définir une fonction permettant d'analyser une adresse à partir d'un script, d'une clé de pub et d'un préfixe donnés . Supprimons maintenant le bean de conflit d' adresses pour le changement d'adresse du Segway. Dans cette refactorisation, un seul bean de configuration d'adresse sera utilisé à la fois pour le segment et pour le segment de changement d'adresse. Modifions l'annotation Bean pour refléter ce changement. Maintenant, changeons cette configuration d' adresse. L'instanciation pour inclure chaque ressource liée à ce type d'adresse changera le champ du chemin de dérivation en une carte où la clé sera un type d'adresse et le la valeur sera son chemin de dérivation correspondant. Ici, nous allons ajouter deux entrées, l'une pour le type d'adresse du segment et son chemin de dérivation initial, et l'autre pour le changement du Segway et son chemin de dérivation initial. Maintenant, au fur et à mesure que cela sera résolu, générateur ajoutera un nouveau générateur d'adresses de segment. Pour le champ des préfixes d'adresse à ajouter la carte suivante ajoutera une entrée pour chaque environnement et ce sont des préfixes d'adresse P2, WP k h. Le champ de préfixe ki étendu sera la principale constante de préfixe net segue. Comme le comparateur d'adresses l'utilisera , le comparateur d'adresses est suivi de la fonction Lambda. Créons donc cette classe et le package utils. Et créons cette fonction. Ce sera une fonction qui prendra une adresse et renverra true si l'adresse commence par l' un de ces trois préfixes présents dans les adresses de segment. Le champ suivant sera égal au script P2 WP k h constant. Enfin, l'analyseur d'adresses sera une référence à la méthode d'adresse du script P2 WP k h. Revenons à la configuration de l' adresse pour remplacer le type du chemin de dérivation. Ce sera une carte avec des types d' adresses comme clés et des chaînes comme valeurs. Maintenant, créons la classe de recherche de configuration d'adresses dans le package api point services. Nous utiliserons ce service pour récupérer la bonne adresse qui peut être fausse et d'autres services que pour récupérer la bonne adresse qui peut être fausse nous refactoriserons ensuite. Ajoutons-y donc l' annotation des services. Et injectons une liste de configurations d'adresses ici. Maintenant, créons cette méthode qui nous permettra de trouver une configuration d' adresse par adresse. Son type de retour sera facultatif ou de type config. Ensuite, nous filtrerons un flux de configurations d'adresses et utiliserons le correspondant d'adresses de la configuration dans le filtre lambda. Ensuite, nous renverrons la configuration d'adresse facultative correspondant à l'adresse reçue en utilisant la première méthode. Créons maintenant une autre méthode qui renverra une configuration facultative de type adresse. Cette fois, il trouvera une configuration d'adresse par type de script. Ce sera similaire à la méthode précédente, mais nous utiliserons le filtre pour vérifier si le passé de la clé pub du script correspond à celle de la configuration de l'adresse. Nous utiliserons également la première méthode définie dans ce cas. Nous allons maintenant créer une méthode pour trouver une configuration d'adresse par type d'adresse. Encore une fois, nous utiliserons un filtre sur un flux de configurations d'adresses. Cette fois, le filtre contiendra un lambda qui vérifiera si le type d'adresse de configuration de l'adresse est égal au type d'adresse précédent, ou s'il est égal à la modification correspondante type d'adresse. Cette fois, nous allons renvoyer l' adresse peut être fausse sans l'objet optionnel en utilisant la méthode orals throw. Cette méthode déclenchera une exception si elle ne trouve pas la configuration d'adresse appropriée. Nous sommes maintenant prêts à commencer à refactoriser d'autres services pour utiliser notre nouvelle configuration d'adresse et notre nouveau Finder de configuration d'adresses. Commençons par le service de création de portefeuille. Supprimons ces deux lignes. Ici. Nous utiliserons un FlatMap dans la liste de configuration des adresses. Ensuite, nous passerons une méthode lambda comme paramètre en renvoyant dans le corps lambda la transformation suivante obtiendra les chemins de dérivation de la configuration de l'adresse reçue. Il manque une dernière lettre S. Renommons donc ce champ en chemins de dérivation. Nous allons maintenant obtenir l'ensemble d'entrées des chemins de dérivation. Ensuite, nous appellerons la méthode map sur le flux de chemins de dérivation. Les entrées renverront une clé pub étendue pour chaque entrée en utilisant la méthode de création du service de clé de pub étendue. Comme ses paramètres passeront la clé principale. La valeur d'entrée, qui sera le chemin de dérivation, la clé d'entrée, qui sera le type d'adresse, et le préfixe ki étendu de configuration de l'adresse. Enfin, nous convertissons le résultat en liste. Passons maintenant au service étendu de clés de pub. Supprimons ces lignes. Ajoutons un quatrième paramètre à cette méthode. Il s'agira d'un préfixe ki étendu. Ici, nous allons remplacer cet argument par le préfixe ki étendu, le préfixe public. Passons maintenant au générateur d'adresses de segments. Ici, nous allons ajouter le préfixe comme deuxième argument, et nous l'utiliserons comme paramètre ici. Maintenant, supprimons le préfixe d'adresse factory de cette classe. Et ajoutons le deuxième argument à cette interface, générons la deuxième méthode. Passons maintenant au générateur séquentiel d'adresses. Dans l'appel à la méthode generate, nous utiliserons le préfixe d'adresse factory. Injectons-le donc dans cette classe. Appelons maintenant la méthode get dessus, en passant le type d'adresse reçue comme paramètre. Nous allons maintenant refactoriser l'usine du générateur d' adresses. Supprimons toutes ces lignes. Injectons le Finder de configuration d'adresses dans cette classe. Ici, nous appellerons la recherche par type d' adresse sur le moteur de recherche de configuration d' adresses, en transmettant le type d'adresse comme paramètre. Ensuite, nous vous renverrons le générateur d'adresses de configuration de l'adresse téléphonique. Maintenant, refactorisons l'usine de préfixes d' adresse. Supprimons toutes ces lignes. Injectons ensuite l'adresse can think Finder dans cette classe. Encore une fois, nous trouverons la configuration de l'adresse par type d'adresse en utilisant cette méthode. Ensuite, nous obtiendrons les préfixes d' adresse à partir de la configuration d'adresse trouvée. Enfin, nous allons renvoyer le préfixe d'adresse correspondant à l'environnement Bitcoin actuel de la manière suivante. Corrigons les tests pour les classes que nous venons de refactoriser, commençant par le test du générateur séquentiel d'adresses. Ajoutons le moteur de recherche de configuration d'adresses tant que champ dans cette classe. Et nous allons l'attribuer à une maquette de cette classe ici. Instancions maintenant une nouvelle configuration d'adresse en définissant sur cette variable. Utilisons ensuite la seule méthode pour définir un objet renvoyé lorsque nous appelons la méthode find by address type sur le moteur de recherche de configuration d'adresses. Dans ce cas, renverra la configuration du Segway. Rendons donc cette méthode publique dans la classe de configuration d'adresses. Remplaçons maintenant ce paramètre d'usine de préfixe d'adresse par la chaîne réseau principale. Et passons le moteur de recherche de configuration d' adresses à l'instanciation de l'usine du générateur d' adresses. Faisons ce test. Oups, la compilation a échoué en raison d'une erreur dans le générateur UTXO DTO. Réglons ça. Ici. Nous obtiendrons la configuration de l'adresse à l'aide du Finder de configuration d'adresse. Injectons-le donc dans cette classe. Supprimons la liste de configuration des adresses de cette classe. Maintenant, nous allons trouver la configuration de l'adresse par type d'adresse ici. Ensuite, nous obtiendrons le chemin de dérivation en utilisant le type d'adresse reçu. Enfin, nous allons concaténer la barre oblique et l' index de l'adresse au résultat. Faisons à nouveau le test. Super, le test est passé. Corrigons maintenant le test du service Create Wallet. Supprimons ces lignes. Instanciera la configuration de l' adresse ici. Ensuite, nous allons créer la liste de configuration des adresses ici. L'ajout du set y configurerait. Supprimons toutes ces lignes. Maintenant, nous allons instancier les objets nécessaires comme ceci. Faisons ce test. Grade. Le test est réussi. Corrigons maintenant le test de service étendu Pub Key. Nous ajouterons le préfixe principal net seg comme dernier paramètre de la méthode create. Et faisons ce test. Super, c'est passé. Enfin, corrigeons le test du générateur d' adresses de segment. Nous allons supprimer le préfixe d'adresse factory de cette classe. Et nous allons transmettre le préfixe d'adresse réseau P2 WP k h principal comme deuxième paramètre de cette méthode. Faisons ce test. Grade. Le test est réussi. Dans la vidéo suivante, nous continuerons à refactoriser notre application. 62. 60 Segwit imbriqué, partie 2 de l'expertise 2: Dans cette vidéo, nous allons continuer à refactoriser notre application. Commençons donc par la classe d'analyseur d' adresses. Injectons le Finder de configuration d'adresses dans cette classe. Supprimons ce code. Nous allons maintenant utiliser le Finder de configuration d' adresse pour trouver une configuration d'adresse par type de clé de pub de script, transmettant le type de clé de pub de script à cette méthode. Ensuite, nous allons mapper le résultat et appliquer l'analyseur d'adresses de configuration d'adresses, en transmettant la clé pub du script et le préfixe approprié comme paramètres. Nous allons maintenant utiliser la méthode URL pour renvoyer une chaîne vide si une adresse ne peut pas être analysée. Rétablissons cette transformation. Passons maintenant à la classe de portefeuille actuelle. Supprimons l'adresse de réception et changeons l'adresse de cette classe. Au lieu d'utiliser un champ pour chaque adresse de réception et de modification, nous utiliserons un champ d'adresses de réception pour modéliser les différentes adresses que nous utiliserons pour recevoir des Bitcoins dans notre portefeuille. Ajoutons donc le champ des adresses de réception à cette classe. Ce sera une carte observable avec des types d' adresses comme clés et des chaînes comme valeurs. Je vais l'instancier ici avec un HashMap observable de la classe FX collections. Supprimons les méthodes qui utilisent les champs supprimés. Créons maintenant la méthode Set Reception Addresses. Nous ajouterons une entrée dans la carte des adresses de réception pour chaque clé de pub étendue. La clé de chaque entrée sera un type d'adresse obtenu en utilisant la valeur de la méthode passant le type de clé de pub étendu comme paramètre. La valeur sera la première adresse de la clé de pub étendue. Maintenant, créons la méthode d'adresse de réception définie. Nous utiliserons cette méthode pour mettre à jour l'adresse de réception actuelle pour un type d'adresse spécifique. Il acceptera un index d'adresses et un type d'adresse comme paramètres. Tout d'abord, nous allons obtenir l' adresse suivante en utilisant la méthode get address ID en transmettant ces paramètres. Ensuite, nous mettrons l'adresse obtenue dans les adresses de réception en utilisant le type d'adresse comme clé. Créons la méthode get receiving address. Il prendra un type d'adresse et renverra l'adresse de réception actuelle car ce type l'obtiendra auprès des adresses de réception en utilisant le type d'adresse comme clé pour la récupération. Maintenant, créons un getter pour les adresses de réception. Renommez-le pour obtenir des adresses de réception observables. Passons maintenant au service de mise à jour des adresses de portefeuille actuelles. Supprimons toutes ces lignes dans un appel de plateforme run later. Ajoutons une fonction Lambda qui utilisera l' adresse de réception actuelle définie par le portefeuille pour définir l'adresse suivante. Supprimons ces champs car nous n'en aurons pas besoin. Maintenant, refactorisons le service de mise à jour actuel du portefeuille. Supprimons ces deux lignes. Ajoutons ensuite un appel à la méthode définie d'adresses de réception que nous venons de créer dans le portefeuille actuel. Passons maintenant au contrôleur de l'onglet Recevoir. Supprimons ce code. Ici. Nous obtiendrons les adresses de réception observables du portefeuille actuel et y ajouterons un auditeur. L'écouteur sera la fonction lambda suivante. Avec cette déclaration if, je vérifierai si l'adresse de réception qui a été modifiée était une adresse suivante ? Si tel est le cas, nous définirons le texte du champ d'adresse de réception sur l'adresse nouvellement ajoutée. Nous allons maintenant refactoriser la façon dont l'adresse de modification est utilisée dans le projet. Créons donc une classe appelée Finder pour modifier le type d' adresse. Cette classe sera chargée de trouver le type d'adresse de changement approprié pour une sortie d'adresse donnée. Bien que nous puissions utiliser différents types d'adresses comme sorties dans une transaction, il est recommandé d'utiliser le même type pour empêcher les tiers de découvrir quelle sortie a été utilisée comme modification. Ce service nous permettra de répondre à cette préoccupation. Ajoutons l' annotation du service à cette classe. Injectons-y le Finder de configuration d'adresse. Créons maintenant la méthode find. Cette méthode renvoie un type d'adresse et prend une adresse comme paramètre. Ici, nous appellerons la méthode de recherche par adresse sur le moteur de recherche de configuration d'adresses. Ensuite, nous associerons la valeur obtenue au type d'adresse de modification équivalent à l'aide du code suivant. Enfin, nous utilisons la méthode or else pour renvoyer le seg qui changerait de type d'adresse. Si le type d'adresse n'a pas été trouvé. Nous utiliserons l'adresse de changement d' adresse du Segway dans ce cas. Bien que nous autorisions notre application à envoyer des transactions vers la plupart des types d'adresses, nous devons fournir cette solution de secours car nous n'implémenterons des transactions vers la plupart des types d'adresses, nous devons fournir cette solution de secours pas tous les types d'adresses comme destinataires . adresses dans notre portefeuille. Passons maintenant au service de création de transactions. Nous devons refactoriser la façon dont l'adresse de changement est obtenue dans cette classe. Ajoutons la variable d' adresse de changement ici. Sa valeur sera égale au résultat de l'appel à la méthode Fine Change d' adresse avec l' adresse comme paramètre. Créons donc cette méthode. Remplaçons d'abord ces bons appels à la méthode de changement d'adresse par la nouvelle variable d' adresse de changement. Ici, nous allons obtenir le type d' adresse en utilisant le Finder de changement de type d' adresse. Injectons-le donc dans cette classe. Nous allons maintenant appeler la méthode find sur le moteur de recherche de changement d' adresse, en passant l'adresse comme paramètre. Ensuite, nous allons renvoyer un appel à la méthode get receiving address, en transmettant le type d'adresse obtenu comme paramètre. Passons maintenant à la classe de configuration de l' adresse. Nous ajouterons des champs relatifs à la création de la transaction. Maintenant. Le premier sera le générateur d'entrées de transactions avec cette nouvelle classe comme type. Créons cette classe dans le package de services API. Ce sera une interface. méthode s' appellera Build, renverra une entrée de transaction et Sa méthode s' appellera Build, renverra une entrée de transaction et prendra un UTXO comme paramètre. Revenons à la configuration de l'adresse. Nous allons ajouter le champ taille d'entrée et de sortie ici. Nous l'utiliserons plus tard dans le cours sur le calculateur de poussière. Ajoutons également le champ de taille ScriptSig ici. Il sera utilisé dans le calculateur de la taille des transactions. Maintenant, ajoutons également le champ du signataire de la transaction. Créons cette classe dans le package api point services. Ce sera une interface. Il aura une méthode de signature qui aura les paramètres suivants. Il lancera également une IOException. Maintenant, dans la classe de configuration d'adresse, définissons les nouveaux champs dans la configuration de l'adresse du segment. Nous ajouterons un nouveau générateur d'entrées de segments en tant que générateur d'entrées de transactions. Créons cette classe dans le package api point services. Il implémentera l'interface Transaction Input Builder et implémentera la méthode build. Pour l'implémenter, copions le code suivant dans la méthode build inputs la classe Transaction Creator et collez-le ici. Remplaçons ce paramètre par un nouveau ArrayList. Nous allons stocker cette entrée de transaction dans cette variable. Ensuite, nous appellerons la méthode set witness, transmettant un nouveau témoin avec les mêmes arguments que nous avons utilisés dans le service Transaction Creators. Enfin, nous avons renvoyé l'entrée de transaction. Copions ces constantes et collons-les dans le générateur d'entrées Segue What. Et ajoutons l'annotation du service ici. Revenons à la configuration de l'adresse. Nous ajouterons 98 comme taille d'entrée et de sortie, zéro comme taille ScriptSig et un nouveau signataire de transactions Segway. Créons cette classe dans le package api point services. Implémentons la méthode du signataire de transaction. Ajoutons l' annotation du service ici. Passons au service de signature de transactions. Nous allons copier cette ligne et la coller ici. Remplaçons ce paramètre par la variable d'index. Et remplaçons le montant UTXO par la variable de montant ici. Notre configuration d'adresse est enfin prête. Passons maintenant au calculateur de la taille des transactions. Utilisons la commande Cleanup Code IDE pour ajouter le mot clé final à chaque champ de cette classe. Injectons le Finder de configuration d'adresses dans cette classe. Supprimons ce code. Redéfinissons la variable toutes les entrées pour mapper le flux d'adresses en entrée transmettant une référence à la méthode de taille d'entrée. Créons cette méthode. Il renverra un double et prendra une adresse comme paramètre. Ici, vous renverrez un code similaire au précédent qui définit la taille d'entrée. Mais le paramètre de taille ScriptSig sera utilisé en trouvant la configuration d'adresse appropriée. L'utilisation de l'outil de recherche de configuration d'adresse générera une exception si nous ne trouvons pas la configuration de l'adresse. Si nous le trouvons, nous en tiendrons la taille du ScriptSig. Ensuite, nous y ajouterons la séquence. Enfin, nous allons additionner les résultats de taille en entrée en utilisant la méthode de la double somme. Si nous ne trouvons aucune entrée, somme sera égale à zéro. Maintenant, supprimons ces lignes. Comme la taille de l'entrée. Nous appellerons la méthode map sur le flux d'adresses de sortie et utiliserons la méthode de taille de sortie pour renvoyer chaque taille de sortie. Nous allons renvoyer ici la somme de la valeur n, longueur de la clé de pub du script et du résultat de la méthode de taille de la clé de pub de script passant l'adresse en paramètre. L'utilisation d'une instruction if permet de vérifier si l'adresse est une adresse seg en utilisant la méthode Segway. Si c'est le cas, nous renvoyons la constante de clé pub du script. Si ce n'est pas le cas, nous allons lancer l'exception suivante. N'oubliez pas que nous n'utiliserons la configuration d'adresse pour calculer la taille de sortie car la configuration d'adresse fait uniquement référence aux adresses que nous pouvons accepter dans nos portefeuilles. Puisque nous prévoyons de prendre en charge plus d'adresses de sortie, nous prendrons comme entrées, devrons gérer la construction de la sortie sans utiliser la configuration de l' adresse. Enfin, nous utilisons la méthode réduite pour calculer la somme des tailles des sorties. Et la méthode or else pour renvoyer zéro sans sortie existe. Supprimons cette constante. Maintenant. Passons au calculateur de poussière. Injectons le Finder de configuration d'adresses dans cette classe. Ajoutons l'adresse en tant que deuxième paramètre à cette méthode de mesure de la poussière. Supprimons cette ligne, nous allons créer la variable de taille d'entrée et de sortie. Nous utiliserons le Finder de configuration d'adresse pour trouver la configuration d'adresse par adresse. Si aucune configuration d'adresse n' est trouvée. Nous allons faire une exception. Si c'est le cas, nous obtenons sa propriété de taille d'entrée et de sortie et la stockons dans une variable. Enfin, nous renvoyons la formule pour calculer si une sortie est de la poussière en utilisant la variable que nous venons de définir. Supprimons cette constante de cette classe. Maintenant, refactorisons le sélecteur de pièces à tirage aléatoire unique qui ajoutera le paramètre de changement d'adresse à ces méthodes. Et nous transmettons le changement d'adresse à l'appel de la méthode Dust. Refactorisons le service des créateurs de transactions. Supprimons maintenant ces constantes. Injectons une liste de générateurs de clés de pub de scripts dans cette classe. Créons cette classe dans le chemin des services api point. Ce sera une interface. Il aura une méthode de correspondance qui renverra un booléen et prendra comme paramètre et adresse. Et il aura une méthode de construction qui renverra un script et prendra une adresse comme paramètre. Finissons d'injecter ce champ dans cette classe. Injectons également le Finder de configuration d'adresses dans cette classe. Ajoutons le changement d'adresse à ces appels de méthode. Supprimons ce code de cette méthode, nous allons créer la variable de script et lui attribuer le résultat de la transformation de flux suivante. Filtrera le flux des générateurs de clés de pub de scripts pour trouver celui qui correspond à la variable d'adresse. Si nous n'en trouvons aucune, nous lançons une exception. Ensuite, nous appelons la méthode build sur le script Pub Key Builder trouvé en transmettant l'adresse en paramètre. Enfin, nous renvoyons le résultat de la transaction contenant le montant et la variable de script. Supprimons maintenant cette méthode et la méthode utilisée de cette classe. Dans la méthode build inputs, supprimons ce code. Maintenant, nous allons appeler la méthode map sur le flux d'UTXos. À l'intérieur, il passera le lambda suivant, vous trouverez la configuration de l'adresse en utilisant l'adresse UTXO. Si nous ne le trouvons pas, nous lançons une exception. Ensuite, nous obtenons le générateur d'entrée de transaction à partir de la configuration de l'adresse et l' appelons méthode spilled, en lui transmettant l'UTXO. Enfin, nous utilisons la méthode collect pour convertir le flux résultant en une ArrayList. Créons la classe de générateur de scripts P2 WP k h dans le package api point services. Il implémentera l'interface Script Pub Key Builder. Implémentons les méthodes d'interface. Injectons le préfixe d'adresse factory dans cette classe. Dans la méthode de correspondance, le résultat de appel à l'adresse correspondant est la méthode de test Segway. Dans la méthode build, nous allons d' abord définir la variable de préfixe sur le préfixe d'adresse. Le résultat de l'appel de la méthode Get transmettra la constante Segway comme paramètre. Ensuite, nous renvoyons le résultat de l'appel à la méthode de script P2 WP k h car le paramètre de cette méthode transmettra le résultat de l'appel du back 30 pour décoder à la méthode hexadécimale. Passons d'abord au fichier POM pour mettre à jour la bibliothèque Java Bitcoin vers la version 0.4, 0.4, qui contient la meilleure méthode 32 dont nous avons besoin. Nous transmettrons le préfixe et l'adresse à cette méthode. Passons maintenant à la classe des signataires de transactions pour une refactorisation plus poussée. Injectons le Finder de configuration d'adresses dans cette classe. Supprimons cette ligne. À sa place, appellera la même méthode en lui transmettant ces paramètres. Créons cette méthode pour créer la variable de signature de la transaction. Nous lui attribuerons le résultat de la transformation suivante. Nous utiliserons le Finder de configuration d'adresse pour trouver une configuration d' adresse par type d'adresse et transmettrons le type d'adresse UTXO DTO à cette méthode. Mais d'abord, ajoutons le champ du type d'adresse à l'enregistrement UTXO DTO. Et ajoutons le type d' adresse à l'instanciation UTXO DTO dans le générateur UTXO DTO. De retour à la transaction, le service des signataires obtiendra la configuration de l'adresse du signataire de la transaction à partir de la configuration de l'adresse téléphonique. Enfin, appelons la méthode de signature des signataires de la transaction en lui transmettant ces paramètres. Ajoutons une clause throws à cette méthode pour indiquer que cette méthode peut lancer une IOException. Le refactoring est terminé. Corrigons maintenant quelques tests, commençant par le test de sélection de pièces à tirage aléatoire unique. Ajoutons la configuration de l'adresse à la méthode de configuration. Ajoutons ensuite la variable de liste des configurations d' adresses contenant le segment Config. Instancions maintenant un nouvel outil de recherche de configuration d'adresses, en lui transmettant les configurations d'adresses. Maintenant, nous allons exécuter ce test. Super, c'est passé. Maintenant, corrigeons le test du service Transaction Creators. Comme le test précédent. Instancions une configuration d'adresse et créons une variable de configuration d'adresse et une variable de recherche de configuration d'adresses. Instancions également un préfixe d' adresse en lui transmettant la chaîne de test reg et le moteur de recherche de configuration d' adresses. Créons maintenant la variable script Pub Key Builders qui lui attribuera une liste contenant un nouveau générateur de script P2 WP k h. Faisons ce test. Super, c'est passé. Maintenant, corrigeons le test du calculateur de taille de transaction. Comme dans les tests précédents, instancions une configuration d'adresse et créons une variable de configuration d'adresse et une variable de recherche de configuration d'adresses. Changeons ces tests de cas. Nous collerons les scénarios de test que vous trouverez sur la page Projet et ressources. Importons la méthode des copies finales. Ces cas de test sont équivalents aux précédents, mais ils ont cette fois de vraies adresses, puisqu'ils sont désormais importants pour la logique du calculateur de la taille des transactions. Faisons ce test. Super, c'est passé. Passons maintenant à la classe de test de l'interface graphique. Ajoutons la constante principale du préfixe du segment net à cet appel de méthode. Et ajoutons la constante de préfixe d'adresse reg test P2 WP k h en tant que paramètre à cet appel de méthode. Maintenant, je vous recommande d'exécuter tous les tests d'application. Ils doivent tous réussir. 63. Adresses Segwit imbriquées: Dans cette présentation, nous parlerons des adresses de segments imbriquées. Alors, qu'est-ce qu'une segue imbriquée ? Quelle adresse ? Les adresses de segments imbriquées sont également appelées segment rap P2, SSH Dash p2, WPA et WPA2. Et des adresses SSH P2. Ce dernier nom décrit le mieux ce qu'ils sont et l'adresse qui code un script de hachage Pay to Witness Pub Key. Dans un script de hachage pay-to-script. La plupart des portefeuilles modernes prennent en charge ces adresses. Leur principal avantage est qu' ils autorisent les anciens portefeuilles, qui prennent généralement en charge les adresses de hachage pay-to-script, mais pas les adresses de segment natives pour leur envoyer des bitcoins. Par conséquent, les propriétaires d'adresses segmentées imbriquées peuvent bénéficier de certains avantages des transactions Segway, tels que des frais de transaction moins élevés et la réception de fonds provenant d'anciens portefeuilles. Alors pourquoi avoir besoin d'adresses natives Segue ? Vous pouvez demander. La raison en est que les adresses natives Ségue rendent les transactions encore plus petites que les adresses segmentées imbriquées. Les adresses de segments imbriquées sont devenues disponibles en 2017 après la mise à jour de l'ensemble Les règles pour générer des adresses de segments imbriquées ont été définies dans le BIP 141. Nous avons choisi des adresses segmentées imbriquées comme adresses de réception secondaires de nos portefeuilles afin de permettre réception de Bitcoins à partir d'anciens portefeuilles. Donc, pour comprendre les adresses de segments imbriquées, commençons par comprendre les adresses SSH P2. P2 SSH est l'acronyme de Pay-to-Script Hash. adresses SSH P2 sont exactement cela. Ils encodent un hachage généré à partir d'un script Bitcoin. Voyons le processus de génération d'une coiffe P2 SH. Nous commençons par un script de remboursement sérialisé hexadécimal. I'll Redeem est généralement un script Bitcoin à signatures multiples, mais il peut s'agir de n'importe quel autre script Bitcoin. Nous utilisons l'algorithme hash 160 pour générer un hachage de script à partir du script d'échange sérialisé. Ensuite, nous combinons le hachage du script avec un préfixe et appliquons l' algorithme de codage en base 58 pour produire une adresse P2 SH grâce au décodage en base 58, grâce au décodage en base 58, nous pouvons obtenir le hachage du script à partir d'un P 2 adresses SSH, une suite imbriquée. Quelle adresse est simplement un script SSH P2 codé en base 58 était un script de rachat est un script de segment. Voyons maintenant comment créer une clé de pub de script P2 SH. N'oubliez pas qu'une clé de script Pub fait partie de la sortie d'une transaction et indique la manière dont l'adresse de réception est présente dans une transaction. Donc, en commençant par une adresse SSH P2, nous avons d'abord décodé la base 58 pour obtenir un hachage de script. Ensuite, nous créons un script composé d' un opcode OP hash 160, hachage de script et d'un opcode OP égal. Il s'agit de la clé de publication du script P2 SH. Pour envoyer des fonds vers une adresse SSH P2, vous devez mettre ce script dans le résultat de la transaction avec le montant de n'importe quel portefeuille, mais qui peut envoyer des bitcoins à une adresse SSH P2, peut envoyer des bitcoins à une suite imbriquée. Quelle adresse ? Voyons maintenant comment créer une entrée de transaction Segue imbriquée, commençant par la clé pub valide pour une adresse UTXO. Nous appliquons ensuite l'algorithme hash 160 pour obtenir un hachage de clé de pub. En combinant le hachage avec un préfixe zéro, nous obtenons un script de segment. Il s'agit du script de remboursement, je ajouterai ultérieurement à la saisie de la transaction. Maintenant, je vais signer une transaction. Pour ce faire, nous produisons d'abord un hachage de signature à partir d'une transaction d'initié en utilisant le même algorithme de hachage de signature que nous utilisons pour signer une transaction Segue. Ensuite, nous combinons le hachage de la signature avec une clé privée valide pour générer la signature à l'aide de l'ECDSA. Ensuite, nous montrons que l'entrée de transaction signe, l'indice de sortie de l'identifiant de transaction, puis les champs de séquence fonctionnent la même manière que les autres types de transaction. Nous ajoutons le script d'échange dans le champ ScriptSig, et nous ajoutons la signature et la clé de pub dans le champ témoin. Notez que contrairement aux entrées natives seg, le ScriptSig n'est pas vide. Dans ce cas. Le champ témoin des entrées de segments imbriquées comporte les mêmes éléments que les entrées de segment natives. Voyons maintenant comment un script de segment imbriqué est exécuté lors de la validation des transactions par les nœuds. validation des segments imbriqués nécessite la validation de deux scripts combinés. A reçu une clé de pub de script SSH P2 provenant d' UTXO et le ScriptSig correspondant provenant d'une entrée de transaction. Les deux scripts sont combinés former le premier script combiné. Le script de remboursement est transmis au script combiné en tant qu'élément sérialisé unique. Lors de cette première validation, de gauche à droite, chaque élément du script combiné est évalué, en commençant par le script de remboursement, qui est ajouté à la pile d'exécution. Ensuite, le hachage OP 160, appliquez le hachage 160 et le script de rachat, transformant en un hachage de script. Ensuite, le hachage du script et le script combiné sont ajoutés à la pile d'exécution. Enfin, l' opcode OP equal compare les deux scripts Hashes et renvoie true s'ils sont égaux. S'ils ne sont pas égaux, la transaction est considérée comme non valide. Ensuite, un second script est formé en combinant le témoin et le ScriptSig. Cette fois, le script de rachat du ScriptSig est évalué dans son intégralité, tout comme il l'est dans évaluations de scripts natifs de Segue. Et comme pour l'évaluation des scripts natifs de Segue, le chiffre zéro initial du ScriptSig déclenche une règle spéciale qui le convertit en script présent dans le script combiné. Désormais, le script combiné est exécuté de la même manière que le script combiné issu des transactions natives segmentées. À partir du script combiné, les clés de signature et de pub sont ajoutées à une pile d'exécution. Ensuite, l'opcode OPT up duplique la clé pub dans la pile d'exécution. Jusqu'à 160 hachages, la dernière clé de pub ajoutée à la pile. Ensuite, à partir du script combiné, le hachage de la clé pub est ajouté à la pile. opcode Up equal verify supprime les deux derniers éléments de la pile d'exécution et les compare. S'ils sont égaux, le script continue de s'exécuter. Enfin, l'opcode object sig vérifie si la signature est valide pour la clé pub restant dans la pile. S'il est valide, il renvoie true à la pile d'exécution. Une fois que tous les éléments du script ont été ajoutés à la pile d' exécution, l' entrée de transaction est considérée comme valide. Si le dernier élément ajouté est vrai, ce processus doit être répété pour chaque entrée de transaction, toutes ses entrées doivent être valides pour qu'une transaction soit considérée comme valide. À titre de rappel visuel, passons en revue l'origine de chaque élément du script Pub Key, ScriptSig et Witness lors de la construction de la transaction. Le hachage du script présent dans la clé de pub du script provient de la base 58, décodant l'adresse de l' UTXO dépensé. Le hachage de la clé pub et le ScriptSig proviennent du hachage 160 d'une clé publique valide. La même clé publique est présente dans le témoin. Le témoin est que la signature a été obtenue en appliquant l'algorithme ECDSA, qui nécessite une clé privée valide. La clé publique et le témoin provenaient de la clé publique dérivée de la clé privée mentionnée. Voyons maintenant quelques paramètres importants pour obtenir des adresses de segments imbriquées. Sur le réseau principal de Bitcoin, le préfixe nécessaire pour obtenir les adresses SSH P2 est C4. Après avoir codé en base 58 une robe avec ce préfixe commençant par le chiffre trois sur le réseau de test Bitcoin et le test reg, le préfixe nécessaire pour obtenir les adresses SSH P2 est 05. Après le codage en base 58, les adresses avec ce préfixe commencent par le chiffre to. Le chemin de dérivation utilisé pour dériver les adresses de segments imbriquées commence par le chemin renforcé 49 pour les portefeuilles, conformément aux directives BIP 49. 64. 62 Segwit imbriqué, partie 3 de l'expertise 2: Dans cette vidéo, nous allons implémenter l' adresse séquentielle imbriquée dans notre portefeuille et ajouter comme option supplémentaire pour recevoir des Bitcoins dans notre portefeuille. Préparons d'abord notre application pour ajouter des tests liés au nouveau type d'adresse. Passons donc au nœud, obtenons une nouvelle adresse client. Nous devons rendre notre application capable d'appeler notre nœud pour générer des adresses SSH P2. Nous pouvons donc créer des tests pour envoyer des bitcoins à ces adresses. Utilisons donc l'option IDE de modification de la signature pour ajouter un nouveau paramètre à cette méthode. Le nouveau paramètre sera une chaîne, son nom sera du type adressé et sa valeur par défaut sera la chaîne back 32. Ajoutons une chaîne vide à cet appel de méthode. Ce paramètre est utilisé si nous voulons ajouter une étiquette à notre nouvelle adresse Comme nous n'en aurons pas besoin, nous la définirons sur une chaîne vide. Et ajoutons le type d'adresse comme dernier paramètre. D'accord, nous pouvons maintenant demander à notre nœud de créer des adresses P2 SH si le refactor de l'IDE a fonctionné. Maintenant, les appels actuels à cette méthode auront la chaîne en retour 32 car il s'agit de moins de paramètres. Passons maintenant au test d' envoi de Bitcoin. Déplaçons cette méthode vers la classe de test de l'interface graphique. Faisons en sorte qu'il soit protégé. Au lieu d'utiliser le mot clé super ici, utilisons celui-ci. Passons maintenant à la classe de test de réception de Bitcoin. Copions tout le code de cette classe. Dans le package de test de l'interface graphique. Créons une nouvelle classe de test appelée receive Bitcoin Nested Segue Test. Et collons le contenu dans cette classe. Apportons quelques modifications à cette classe. Changeons le nom de la classe pour recevoir le test de suivi imbriqué de Bitcoin. Changeons maintenant les noms des méthodes de test. Ajoutons ici une adresse de segment imbriquée. Faisons de même pour toutes les autres méthodes de test en indiquant dans leur nom qui recevront des Bitcoins dans une suite imbriquée quelles adresses ? Maintenant, ajustons ce premier test. Nous ajusterons le nom de son portefeuille. Modifions ensuite le paramètre de recherche ici. Ainsi, la variable d'adresse est affectée à la valeur du champ auquel le segment imbriqué est adressé. Ici, au lieu d'utiliser la méthode «  adresse est valide », nous utiliserons la méthode « adresse du segment imbriqué est valide » que nous allons créer. Corrigons ce formatage de code. Maintenant, créons la méthode segue what address is valid imbriquée dans la classe de test de l'interface graphique Nous utiliserons la méthode address valid comme base. Nous allons donc le dupliquer. Corrigons son nom. À présent. Remplaçons ici le type d'adresse par la constante segwayed imbriquée. Et changeons le chemin de dérivation ici pour commencer par 49. Créons cette constante dans le type d'adresse enum. Créons également la séquence imbriquée pour changer de constante ici. Ici, changeons le préfixe de l'adresse générée par le préfixe d' adresse P2 SH du réseau de test. Et au lieu d'utiliser le générateur d'adresses de segment, j' utiliserai le générateur d'adresses de segment imbriqué. Ajoutons ce champ à cette classe. Nous utiliserons l' annotation filaire automatique pour l' injecter dans cette classe. Créons cette classe dans le package api point services. Je l'implémenterai plus tard. Revenez à la classe de test Sega Nested Sega pour recevoir des bitcoins. Apportons les mêmes ajustements aux autres méthodes de test. Passons maintenant à la classe de configuration des adresses. Dupliquons ce bean l' utiliser comme base pour créer la configuration segwayed imbriquée. Remplaçons ces paramètres par une modification de segment imbriquée et une modification de séquence imbriquée. Changeons le nom de cette méthode en deux configurations de segments imbriqués. Changeons maintenant les paramètres de configuration de l' adresse. Le premier paramètre sera le type d'adresse imbriqué. Dans le deuxième argument, changeons les clés de carte segments imbriqués et changeons de segment imbriqué. Et les deux voies de dérivation. Nous allons commencer par 49. Nous utiliserons le générateur d' adresses segmentées imbriquées comme générateur d'adresses. Faisons en sorte qu'il implémente l'interface du générateur d' adresses. Ajoutons la méthode d'interface. Maintenant, définissons le préfixe de chaque adresse d' environnement. L'environnement réseau principal. Nous utiliserons la constante de préfixe d'adresse SSH réseau P2 principale. Les environnements de test Test Net et Reg . Nous utiliserons la constante de préfixe d'adresse P2 SH du réseau de test. Remplaçons le préfixe ki étendu constante principale du préfixe de segment imbriqué du réseau. L'adresse correspondante sera le prédicat segue imbriqué. Créons ce champ dans le comparateur d'adresses. Il sera similaire au prédicat de segment ci-dessus. Mais le correspondant renverra vrai si l'adresse commence par trois ou deux à la place. Maintenant, nous allons l'importer ici. Utilisons ici la constante SSH P2. Utilisons la méthode d'adresse du segment imbriqué dans le script comme analyseur de script. Utilisera le générateur d'entrées de segments imbriqués comme générateur d'entrées de transaction. Créons cette classe dans le package api point services. Ajoutons la méthode d'interface. En tant que taille d'entrée et de sortie. Nous allons définir 180 comme taille 23 de ScriptSig. Et en tant que signataire de la transaction, il utilisera le signataire de transactions Segway imbriqué. Créons cette classe dans le package api point services. Et ajoutons la méthode d'interface. Notre configuration Ségue imbriquée est prête. Nous devons maintenant implémenter le générateur d' adresses segmentées imbriquées, le générateur d'entrées et le signataire de transaction. Commençons par le générateur d'adresses seg imbriqué. Tout d'abord, ajoutons un test pour ce service dans le package de test api point services. Cela étendra la classe de spécification. Ajoutons la méthode de configuration suivante. Ajoutons la méthode d'appel au fournisseur de publicités de sécurité. Ajoutons le générateur d'adresses de segments imbriqués tant que champ dans cette classe. Et instancions-le ici. Passons maintenant au test du générateur d' adresses de segment. Copions ce test et collez-le ici. Nous l'utiliserons comme base pour notre nouveau test. Au lieu d'utiliser le générateur d'adresses de segment, j'utiliserai le générateur d' adresses séquencé imbriqué ici. Changeons le préfixe de cette constante. Supprimons ces scénarios de test et collons ceux qui sont valides pour les adresses de segments imbriquées. Ils sont disponibles sur la page Projet et ressources. Revenons au générateur d' adresses de segments imbriqués. J'ai créé par erreur cette classe en tant que classe groovy. Utilisons cette fonctionnalité IDE pour convertir cette classe en Java. Supprimons ce code. Ajoutons l' annotation du service à cette classe. Ici, nous allons convertir la clé enfant étendue en clé publique. Ensuite, nous renverrons l'adresse du segment imbriqué à partir de appel de méthode à clé publique compressé l'objet d'obtention en lui transmettant la variable de préfixe. Renommons ce paramètre en clé étendue. Maintenant, nous allons exécuter ce test. Super, c'est passé. Implémentons maintenant le générateur d'entrées Segue What imbriqué. Ajoutons l' annotation du service à cette classe. Copions la méthode de génération dans le générateur d'entrées de segments et utilisons-la le générateur d'entrées de segments et comme base pour notre nouvelle méthode de génération. Nous allons également coller ces deux constantes dans la classe de générateur d'entrée Segue imbriquée. Ajoutons maintenant la constante segwayed imbriquée fictive ScriptSig dans le script ArrayList. Créons cette constante. Il sera égal à la chaîne zéro répétée 44 fois. Ici, nous devons réellement transmettre cette constante dans une liste de méthodes. Maintenant, implémentons le signataire de transactions Segway imbriqué. Ajoutons l' annotation du service ici. Copions la méthode de signature dans le signataire des transactions Segway et utilisons-la le signataire des transactions Segway et comme base pour notre nouvelle méthode de signature. Ici, au lieu d'utiliser la méthode de signature ECDSA des transactions, nous utiliserons la méthode segue imbriquée sinus issue du signataire ECDSA de la transaction P2 SH. Ajoutons le script de remboursement comme quatrième argument de cette méthode. Supprimons ce dernier argument. Créons la variable de script redeem. Cette variable sera égale à l'appel de méthode de script P2 WP k h. En tant que paramètre, il transmettra le hachage 160 de la clé publique compressée correspondante de la clé privée reçue. La méthode Sign Nested Segue se chargera d'ajouter le script de rachat le champ témoin et la clé publique et la signature dans le champ ScriptSig. OK, la configuration Segue imbriquée est enfin prête. Ajoutons maintenant le nouveau champ de segment imbriqué à l'onglet Réception FXML. Tout d'abord, changeons l'adresse de réception et le texte de l'étiquette pour l'adresse du segment. Maintenant, dupliquons tout ce code et changeons le texte de cette étiquette adresse imbriquée. Changeons également cet identifiant éthique deux adresses de réception imbriquées. Déplaçons ce champ vers la deuxième ligne de son conteneur. Pour ce faire, ajoutons l' attribut d'index de ligne du volet de la grille à ce champ et définissons-le sur un. Faisons de même avec cette étiquette. Passons maintenant au contrôleur de l'onglet Recevoir. Dupliquons ce bloc if dans cette instruction if pour vérifier si le changement d' adresse est une adresse de segment imbriquée. Si tel est le cas, nous définirons le contenu de l'adresse de réception Segue imbriquée TextField sur le changement d'adresse. Ajoutons donc ce champ à cette classe. Et ajoutons-y une annotation FXML. Ajoutons également une déclaration de retour ici. Maintenant, faisons quelques tests. Laissons fonctionner notre nœud Bitcoin. Et lançons ce test. Super, les tests sont réussis. Dans la vidéo suivante, nous allons terminer l'ajout de la prise en charge des segments imbriqués pour notre portefeuille. Tu vois, oui. 65. 63 Segwit imbriqué, partie 4 de la combinaison de compétences 2: Dans cette vidéo, nous allons implémenter la possibilité d'envoyer des bitcoins à des adresses imbriquées . Nous allons commencer par créer des tests pour cette fonctionnalité. Donc, dans le package de test de l'interface graphique, créons la classe de test Sega imbriquée Send Bitcoin. Cela étendra la classe de test de l'interface graphique. Copions quelques tests du test Send Bitcoin. Ils serviront de base à nos nouveaux tests. Copions ce code et collez-le ici. Maintenant, nous allons copier ce premier test, puis le coller dans notre nouvelle classe. Faisons de même avec ce test. Faisons de même avec le test au crépuscule. Maintenant, ajustons les nouveaux tests. Changeons le nom de ce test pour envoyer du Bitcoin avec des entrées de segment imbriquées et des sorties segmentées imbriquées. Changeons le nom du portefeuille pour mon test à 23 ans. Et changeons l'adresse de réception du segment imbriqué de cette méthode de recherche à deux segments imbriqués. Ici, changeons ce paramètre en segment de tiret SSH P2. Ce paramètre obligera le nœud à nous renvoyer une adresse de segment imbriquée afin que nous puissions lui envoyer des bitcoins. Maintenant, ajustons les scénarios de test. J'ai précédemment calculé le montant total des frais prévus pour ces affaires. Ils diffèrent des frais de transaction liés aux entrées et sorties natives Segue car la taille de leurs transactions diffère. Procéderons à des ajustements similaires pour le prochain test. Maintenant, créons le générateur de scripts P2 SH. Il implémentera l'interface Script Pub Key Builder. Mettons en œuvre ses méthodes. Dans la méthode match, ces appels de méthode de test Ségue imbriqués seront renvoyés en passant l' adresse en paramètre. Nous renverrons l'appel à la méthode de script P2 SH dans la méthode de construction car son paramètre transmettra l' adresse décodée en base 58 comme suit. Ajoutons l' annotation du service à cette classe. Passons maintenant au test du calculateur de taille de transaction. Dupliquons cette méthode. Nous l'utiliserons comme base pour créer un test visant à vérifier le calcul de la taille des transactions à l'aide d' entrées et de sorties de segments imbriqués. Changeons donc le nom de la méthode pour refléter cela. Supprimons ces scénarios de test et collons les scénarios de test disponibles sur la page Projet et ressources. Maintenant, dans la méthode de configuration, ajoutons le seg imbriqué à configurer dans la liste des configurations d' adresses. Passons maintenant au calculateur de taille de transaction dans la méthode de taille de clé Script Pub. Ajoutons l' instruction if suivante pour tester si l'adresse reçue est une suite imbriquée. Quelle adresse ? Si c'est le cas, renverra la constante segwayed imbriquée dans la clé de pub du script. Créons cette constante. Sa valeur sera de 23. Maintenant, nous allons exécuter ce test. Super, c'est passé. Maintenant, exécutons notre nœud. Et lançons le test Send Bitcoin Nested Segue. Super, les tests sont réussis. Maintenant, jouons un peu avec notre portefeuille dans l'environnement de test net. Pour ce faire, changeons cette variable dans le fichier bitcoin.com pour tester net. Et redémarrons notre nœud. Attendons qu'il soit synchronisé. En fonction de la mise à jour de votre note. Cela peut prendre de quelques minutes à quelques heures. OK, j'ai pondéré la somme des heures. Et enfin, la synchronisation de mes notifications. Exécutons notre application. Créons un portefeuille. D'abord. Recevons des Bitcoins à l'adresse de notre segment imbriqué. Pour ce faire, utilisons ce robinet. OK, la transaction est apparue dans mon portefeuille. Attendons un peu pour que cela se confirme. D'accord. Maintenant, la transaction a une conformation. Maintenant, envoyons des fonds à l'adresse du robinet. Il est intéressant de noter que cette transaction n'a pas eu besoin d'être modifiée et nous nous sommes retrouvés sans fonds puisque nous avons dépensé notre seule contribution. Vérifions la dernière transaction dans l'explorateur de blocs. Attendons un peu pour que cela se confirme. J'ai attendu quelques minutes, et maintenant il a trois conformations. L'explorateur de blocs affiche la même chose. Génial. Tout fonctionne comme prévu. Faisons encore un test. Recevons d' abord plus de Satoshi dans l'adresse de notre segment, puis dans notre adresse imbriquée . OK, maintenant que les deux transactions sont confirmées, envoyons des fonds à une adresse de segment imbriquée depuis cette page. Maintenant, la transaction a généré des changements. Puisque nous l'avons envoyée à une adresse de segment imbriquée, la modification générée a également été envoyée à une séquence imbriquée. Quelle adresse ? Au bout d'un moment, la transaction a été confirmée. Génial. 66. 64 héritage de la compétence partagée 2: Dans cette vidéo, nous allons implémenter dans notre portefeuille la possibilité d'envoyer des bitcoins à des adresses P2 pKa H, également appelées adresses traditionnelles. P2, pk h était le type vestimentaire le plus utilisé avant la montée en popularité des adresses segmentées ces dernières années. De nos jours, il est toujours très populaire. Il est donc important que notre portefeuille envoyer des bitcoins à ces adresses. Commençons par refactoriser la façon dont notre portefeuille crée des clés de script de pub afin qu'il soit plus facile d'ajouter à l'avenir la prise en charge de l'envoi de bitcoins vers d'autres types d'adresses. Pour cela, créons l' enregistrement de configuration du script dans le package domains. Semblable à la configuration des adresses, cette classe contiendra des paramètres importants pour créer des transactions selon des types de clés de pub de script spécifiques. Ajoutons-y donc les champs suivants. Le générateur de clés de pub de scripts, la taille de la clé de pub de script et le prédicat Address Matcher, qui vous aideront à identifier le type de configuration du script par adresse. Créons maintenant la classe de configuration de script dans le package api point config. Encore une fois, similaire à la classe de configuration d' adresses. Cette classe sera chargée d'instancier et de définir toutes les clés de script auxquelles notre portefeuille peut envoyer des bitcoins. Ajoutons-y l' annotation de configuration. Maintenant, créons la méthode annotée Bean suivante. Il renverra une configuration de script et définira la configuration P2 WP. Son générateur de clés de pub de scripts sera le générateur de scripts P2 WP k h. Sa taille de script sera égale à 22 et son correspondant d'adresses sera le segment Lambda. Passons au générateur de scripts P2 WP k h. Pour faciliter l'instanciation, le préfixe d'adresse factory sera supprimé du service. Construira la variable de préfixe en analysant le préfixe à partir de la variable d'adresse à l'aide de la méthode parse prefix. Créons cette méthode. Nous allons d'abord vérifier si l'adresse commence par la constante de préfixe d' adresse réseau P2 WP k h de test. Si c'est le cas, nous allons renvoyer cette constante. Ensuite, nous ferons la même déclaration, mais en utilisant plutôt la constante de préfixe d'adresse reg test P2 WP k-th. Enfin, nous renverrons la constante principale du préfixe d'adresse réseau P2 WP k h si le code est exécuté jusqu'à ce point. Créons maintenant le bean pour la configuration du script P2 SH. Il utilisera le générateur de scripts P2 SH. Sa taille sera de 23 et son correspondant d'adresses sera le segment lambda imbriqué. Créons maintenant la configuration du script et trouvons sa classe dans le package api point services. Comme son nom l'indique, ce service sera chargé de trouver la configuration de script appropriée pour les autres services. Ajoutons-y l' annotation du service. Maintenant, injectons la liste des configurations de script dans cette classe. Spring Boot Magic injectera tous les beans de configuration des scripts dans cette liste après le démarrage de l'application. Maintenant, créons la méthode de recherche par adresse. Il renverra une configuration de script et prendra une adresse comme paramètre renverra la transformation de flux suivante ici filtrera le script peut penser à un flux en utilisant le correspondant d'adresses de chaque script config. Nous utiliserons la première méthode pour filtrer la première configuration de script. Si nous n'en trouvons aucune, utiliserons la méthode URLs throw pour lancer une exception. Passons maintenant au service des créateurs de transactions qui utilisera le script config finder pour refactoriser cette classe. Tout d'abord, supprimons la liste des générateurs de clés de pub de script de cette classe, car nous ne l'utiliserons pas. Et injectons le script can think Finder dans cette classe. Maintenant, dans la méthode de sortie de compilation, supprimons ce code. Créera cette variable de script à l'aide de l'outil de recherche de configuration du script, recherche par méthode adressée. Ensuite, nous appellerons la méthode de construction du générateur de clés de script pub sur le résultat. Maintenant, refactorisons le calculateur de la taille des transactions. Injectons le script config Finder dans cette classe. Maintenant, supprimons le code dans la méthode de taille de clé de script Pub. À sa place, nous utiliserons le script config Finder pour rechercher une configuration de script par adresse et renvoyer la taille de sa clé de script pub. Supprimons ces importations et constantes car nous ne les utiliserons pas. Passons maintenant à l'interface Script Pub Key Builder. Supprimons la méthode match de cette méthode et de toutes ses implémentations, car nous ne l'utiliserons plus. Le refactoring est terminé. Maintenant, avant d'ajouter la configuration du script P2 PKa H , créons le test send Bitcoin legacy dans le package de test de l'interface graphique. Cela étendra la classe de test de l'interface graphique. Nous utiliserons cette classe pour vérifier si notre portefeuille envoie correctement une transaction à une adresse existante. Copions le code suivant du test d'envoi de Bitcoin et collez-le ici. Nous l'utiliserons comme base pour notre nouveau test. Changeons son nom pour envoyer du Bitcoin avec des entrées segmentées, sortie existante et le seg changeraient. Notez que même si nous serons en mesure d' envoyer des fonds vers une ancienne adresse, nous ne serons pas en mesure de les recevoir vers une ancienne adresse appartenant à notre portefeuille. Par conséquent, utilisera les adresses natives Segue pour recevoir les modifications de ces transactions. Et le nom de ce test reflète cela. Changeons le nom du portefeuille pour mon test à 26 ans. Remplaçons ce paramètre par « ancienne » afin créer une ancienne adresse à laquelle nous enverrons des bitcoins. Modifions également les scénarios de test en utilisant les valeurs précédemment calculées suivantes. Ces valeurs diffèrent des autres transactions car les clés de pub de script P2, pKa, H sont légèrement plus grandes que les clés de pub de script natives Segue, qui ont un pub de script natives Segue, qui impact sur la taille et le phi de la transaction. Passons maintenant à la classe de configuration du script. Ajoutons le mot clé public ici. Créons le bean de configuration P2 pKa H car son générateur de clés de pub de scripts définira un nouveau générateur de scripts p2 pk H, qui sera créé ultérieurement. taille de sa clé de pub de scripts sera de 25 et c'est réglé. Matcher sera cet ancien Lambda que nous créerons plus tard. Créons le générateur de scripts P2 pKa H dans le package api point services. Implémentons la méthode d'interface. Dans la méthode de construction, elle renverra le script P à P k h, l'appel à la méthode de script car son paramètre transmettra l' adresse décodée hexadécimale en base 58 en utilisant la méthode de décodage en base 58 avec la méthode checksum to hex. Passons maintenant à la classe métrique d' adresse. Dupliquons ce champ. Nous l'utiliserons comme base pour ces anciens lambda. Ici, je vais remplacer ces paramètres par un, M et N. L'un est le préfixe de legacy qui figure dans le réseau principal. M et n sont les préfixes valides pour les autres environnements. Importons ces anciens lambda ici. D'accord, maintenant notre portefeuille peut envoyer des bitcoins à d' anciennes adresses. Maintenant, ajustons certains tests. Passons au test du calculateur de la taille des transactions. Dans la méthode de configuration, instancions le moteur de recherche de configuration du script. Nous lui transmettrons une liste de configurations de script. Reprendra les configurations de script de la classe de configuration de script. Instancions-le donc ici. Maintenant, ajoutons le script peut figues ici. Maintenant, dupliquons ce test. Renommez-le pour qu'il calcule la taille de la transaction pour P2 WP k-ème entrées de transaction et p2 pk pour chaque sortie de transaction. Ce nom de test décrit bien le scénario qui sera testé. Supprimons ces scénarios de test. Je vais coller ici ces cas de test qui sont disponibles sur la page Projet et ressources. Corrigons le formatage de ces scénarios de test. Faisons ce test. Grade. Les tests sont réussis. Maintenant, corrigeons le test du service Transaction Creators. Copions ce code et collez-le ici. Supprimons la fabrique de préfixes d' adresses et les générateurs de clés de pub de scripts. Et corrigeons l' instanciation du service ici. Faisons ce test. Super, c'est passé. Maintenant, corrigeons le test de sélection de pièces à tirage aléatoire unique qui nécessitera à nouveau ce bout de code. Alors copiez-le et collez-le ici. Assurez-vous que le sélecteur de pièces à tirage aléatoire unique est correctement instancié. Dans mon cas, l'identifiant l'a déjà fait. Faisons ce test. Grade. Le test est réussi. Maintenant, exécutons notre nœud. Avant cela, assurez-vous que l' environnement de test reg est défini sur le fichier bitcoin.com. Exécutons maintenant le test Send Bitcoin Legacy. Super, le test est passé. 67. 65 Enregistrer des skillshare de portefeuille 2: Dans les vidéos précédentes, nous avons implémenté une application entièrement fonctionnelle que vous pouvez déjà utiliser pour créer des portefeuilles et envoyer et recevoir des Bitcoins. Mais si nous fermons l'application, nous perdons toutes les informations sur les portefeuilles que nous créons dans cette vidéo et dans la suivante, nous commencerons à implémenter la possibilité sauvegarder et de charger des portefeuilles dans notre application. Pour stocker les données de notre application, nous utiliserons la base de données H SQL. Sql est une base de données SQL implémentée en Java. Nous avons choisi H SQL pour les raisons suivantes. Tout d'abord, il s'agit d'une base de données légère. Deuxièmement, il est compatible et facile à utiliser avec la bibliothèque Spring Boot Data JPA. Enfin, il peut être facilement crypté comme nous le montrerons dans cette vidéo. Passons au fichier XML Poem Dot pour ajouter les dépendances Spring Boot Data JPA et H SQL DB. Cliquez sur ce bouton pour charger les nouvelles dépendances. Passons maintenant au fichier de propriétés des points de l'application. Nous allons définir certaines configurations nécessaires pour la base de données. Cette configuration détermine que chaque modification apportée à nos classes d'entités met à jour notre base de données en conséquence. Dans Spring Boot, les classes annotées d'entités définissaient les structures de tables, comme nous le verrons bientôt. Dupliquons cette ligne pour l'utiliser comme base pour les autres configurations. Nous devons définir la classe de pilote nommée config sur la classe suivante. Le nom d'utilisateur et le mot de passe. Tu peux nous régler ce que tu veux. Comme je ne l'utilise que pour les tests, je vais définir ces champs sur Y0 W pour le moment. Mais n'oubliez pas de remplacer ces valeurs des chaînes plus sécurisées avant d'utiliser ce portefeuille sur le réseau principal. Maintenant, définissons l' URL de la base de données. Comme nous utiliserons une base de données basée sur des fichiers, devrons définir cette configuration JDBC deux-points H, fichier SQL DB deux-points, le chemin dans lequel nous voulons que les fichiers de base de données résident. Dans mon cas, le chemin que nous allons commencer par le dossier BYOD W situé dans le siège dr. Racine. Dans ce dossier, je souhaite créer des dossiers spécifiques pour chaque environnement réseau Bitcoin. Pour ce faire, je vais me référer à la variable d'environnement Bitcoin dans le fichier de propriétés des points de l'application, en la plaçant entre accolades et après le signe $1 comme celui-ci. Enfin, j'utiliserai le sous-dossier de données de ce dossier et nommerai les fichiers de base de données comme étant ma base de données. Et nous avons terminé la ligne par un point-virgule. Maintenant, dans le package BYOD W, créons le package de base de données. Dans ce package, créons le package d'entités. Et créons la classe d' entités de portefeuille qu'elle contient. Dans cette classe, nous allons modéliser les registres dans la table de base de données du portefeuille. Pour ce faire, ajoutons-y l'annotation de l' entité. Et l'annotation de la table avec son paramètre de nom égal à Wallet. Maintenant, ajoutons quelques champs à cette classe. chaque champ de cette classe, nous allons modéliser une colonne à partir de la table du portefeuille. Notre objectif est de ne sauvegarder que les champs nécessaires pour obtenir les mêmes données de portefeuille après le chargement. Ajoutons donc le champ ID. Ajoutera ce champ pour suivre la bonne pratique qui consiste à toujours ajouter un identifiant d'auto-incrémentation à une table de base de données relationnelle. Pour cela, ajoutons deux annotations à ce champ. La première est l'annotation ID, la seconde est l'annotation de valeur générée avec le paramètre suivant. Ajoutons également une annotation de colonne avec ID comme paramètre de nom. L'annotation de colonne déterminera le nom correspondant de la colonne liée à ce champ dans la table du portefeuille. Nous suivrons le style des majuscules pour les paramètres du nom de colonne où toutes les lettres ou minuscules et le trait de soulignement séparent les mots. Créons maintenant le champ du nom. Ajoutons également l' annotation de colonne à ce champ. Outre le paramètre name, ajoutons également le paramètre unique égal à vrai et le paramètre nullable égal à faux. Ces paramètres ajouteront les contraintes uniques et non nullables dans le tableau de cette colonne. Par conséquent, l'application générera une erreur si vous essayez de créer un registre sans nom dans le tableau du portefeuille. Créons également le champ de départ mnémotechnique avec l'annotation suivante. Le paramètre length limitera la longueur maximale de ce champ à 500 caractères. Ajoutons également le paramètre nullable égal faux à cette annotation. Maintenant, ajoutons le champ du nombre d'adresses générées avec l'annotation de colonne suivant le style Snake Case. Le dernier champ sera créé à l'adresse. Ajoutons l' annotation de date créée pour indiquer que ce champ utilisera la date actuelle pour enregistrer ses valeurs. Maintenant, créons quelques constructeurs. abord, un constructeur vide , nécessaire pour que Spring Boot instancie correctement cette classe. Créons ensuite un constructeur avec tous les champs de cette classe à l'exception de l'identifiant. Créons des getters pour les mêmes champs. Notre entité de portefeuille est terminée. Maintenant, dans le package de base de données, créons le package de référentiels. Et créons l'interface du référentiel du portefeuille à l'intérieur de celui-ci. L'interface du référentiel du portefeuille sera chargée d'interagir avec la base de données en récupérant les données et en les enregistrant dans la table du portefeuille. Pour y parvenir, il étendra l'interface du référentiel JPA ajoutera des paramètres de type à cette extension. Le premier test sera l'entité que nous allons gérer ce référentiel. Dans ce cas, il s'agira de la classe d'entité du portefeuille. Le second doit être le type d'identifiant de l'entité. Ce sera donc la classe longue. Grâce à cette interface simple, nous avons déjà accès aux opérations de base de données courantes pour la table du portefeuille, telles que l'insertion de registres et leur recherche par identifiant. Tout cela vous est automatiquement proposé par la bibliothèque Spring Boot Data JPA. Créons maintenant le package de services dans le package de base de données. À l'intérieur, créons la classe de service Save Wallet. Cette classe sera chargée de sauvegarder le portefeuille après sa création. Ajoutons-y l' annotation du service. Injectons le référentiel du portefeuille dans cette classe. Faisons de même avec le champ relatif au nombre initial d'adresses générées. Maintenant, créons la méthode Save Wallet. Il prendra un objet de portefeuille comme paramètre. À mettre en œuvre. Il instanciera d' abord un nouvel objet d'entité de portefeuille avec les paramètres suivants à partir du portefeuille. Ensuite, nous appellerons la méthode save du référentiel du portefeuille en passant l' entité du portefeuille comme paramètre. *****. J'ai mélangé l'ordre des paramètres ici. Réglons ça. Et ajoutons ici l'annotation qualificative pour l'injection correcte de ce champ. C'est ça. Avec ce code simple, nous avons réussi à enregistrer facilement les informations du portefeuille dans la base de données SQL. Créons maintenant le package listeners dans le package de base de données. Et créons une classe appelée save wallet listener. À l'intérieur. Cette classe servira d'auditeur pour l'événement de portefeuille créé. Ainsi, une fois que l'application aura créé un portefeuille, elle sera chargée d'appeler le service de sauvegarde du portefeuille pour enregistrer le portefeuille. Ajoutons-y donc l' annotation du composant. Il implémentera l'écouteur de l' application avec l'événement de portefeuille créé comme paramètre de type. Mettons en œuvre sa méthode. Ici, nous appellerons la méthode save wallet, en passant le portefeuille d'événements comme paramètre. Créons cette méthode. Nous utiliserons le service Save Wallet ici. Injectons-le donc dans cette classe. Ensuite, nous appellerons la méthode save wallet ici, en passant le portefeuille comme paramètre. Maintenant, si tout fonctionne correctement, notre application enregistrera les portefeuilles dans la base de données après leur création. Exécutons donc notre application pour tester cette fonctionnalité qui sera d'abord testée dans l'environnement de test reg. Assurez-vous que l'option VM dans la configuration d'exécution de l'application BYOD W est vide. Pour ce test spécifique, nous n'aurons pas besoin d'exécuter notre nœud. Laissons-le fonctionner. Créons un portefeuille. OK, si tout fonctionnait correctement, le portefeuille a été enregistré. Fermons notre application. Maintenant. Voyons si les fichiers de base de données ont été créés dans le dossier spécifié. Super, l'application a créé le dossier reg test et les fichiers de base de données attendus. Ouvrons-les. Fichier journal Idb point. Ici, nous pouvons voir toutes les opérations de nos bases de données d' applications en SQL écrites en texte brut. Nous pouvons voir qu'il possède une commande d'insertion contenant les données du portefeuille, y compris sa graine mnémonique. Bon. Mais cela n'est pas enregistré puisque quiconque obtient ce fichier peut connaître tous nos portefeuilles, nos graines mnémotechniques. Nous allons bientôt résoudre ce problème en cryptant ces fichiers. Pour l'instant, voyons les données du portefeuille enregistrées dans un format plus lisible. Pour cela, rendez-vous sur ce site Web pour télécharger la base de données H SQL. Cliquez sur le lien de téléchargement pour télécharger la dernière version. Après l'avoir téléchargé, extrayez son contenu dans un dossier. Ouvrons le dossier bin situé dans le dossier extrait. Exécutons maintenant le point tournant du gestionnaire d'exécution dans ce fichier. Passons aux propriétés des points de l'application dans notre application pour copier l'URL de la base de données. Maintenant, collons son contenu dans ce champ. Et remplaçons cette variable par reg test. Ajoutons ici le même nom d'utilisateur et le même mot de passe que nous avons définis dans le fichier de propriétés point de notre application. Cliquons. OK, super. Nous avons réussi à nous connecter à notre base de données. Maintenant, cliquez avec le bouton droit sur le dossier public Dot Wallet ici et cliquez sur l' instruction SQL select. Exécutons cette commande en cliquant sur ce bouton. Génial. Voici les données de notre portefeuille sous forme de tableau. Nous pouvons voir que notre application a enregistré avec succès les données du portefeuille. Fermons cette application. Maintenant, comme je l'ai déjà dit, il est important de crypter nos fichiers de base de données. Pour ce faire, ajoutons le suffixe suivant à l' URL de la base de données dans le fichier de propriétés des points de l' application. Nous allons définir ici une clé cryptographique et un type de cryptage. Le type de berceau sera AES, qui est une cryptographie symétrique que l'application utilisera pour crypter données avant de les enregistrer dans la base de données et les déchiffrer lors de leur extraction. La clé cryptée sera la clé nécessaire pour les deux opérations. Utilisons à nouveau le gestionnaire de base de données SQL pour générer une clé de chiffrement valide. Cliquez sur le bouton OK ici. Exécutons la commande SQL suivante. Copions la clé générée dans un éditeur de texte, puis copiez-la à nouveau valeur de la clé cryptée dans les propriétés des points de l' application. Ajoutons maintenant la même configuration de base aux autres fichiers de propriétés du projet. Supprimons le dossier reg test, créons une distorsion des fichiers de base de données. Et réexécutons notre application. Créons un nouveau portefeuille. Maintenant, ouvrons le dossier reg test et le fichier journal my db point généré. Son contenu est désormais totalement incompréhensible, ce qui signifie qu'il a été chiffré avec succès. Copions à nouveau l'URL de la base de données, y compris le suffixe de cryptage, et ouvrez-la à l'aide du gestionnaire de base de données H SQL. Super, nous pouvons à nouveau voir les données du portefeuille enregistrées en utilisant la nouvelle URL de cette application. 68. 66 Load Wallet partie 1 skillshare 2: Dans cette vidéo, nous allons commencer à implémenter la possibilité de charger des portefeuilles précédemment enregistrés dans notre application. Tout d'abord, effectuons les refactorisations nécessaires. Passons au service de création de portefeuille. Nous voulons être en mesure de créer des portefeuilles avec différentes dates et différents nombres d'adresses générées. Ajoutons-les donc en tant que paramètres dans cette méthode. Maintenant, remplaçons cette instanciation de date par la variable at créée. Et ajoutons la variable nombre d'adresses générées comme dernier paramètre de cette méthode. Passons maintenant au contrôleur de dialogue Create Wallet pour ajouter ces paramètres à l'appel à la méthode create. Injectons le nombre initial d' adresses générées dans cette classe. Maintenant, changeons la signature de la méthode des adresses ADA pour inclure le dernier paramètre que nous venons d'ajouter à cet appel. Dans le service d'adresses ADD, ajoutons la variable nombre d'adresses générées à l' appel et à la signature de cette méthode. Passons-le également comme dernier paramètre de la méthode de génération du générateur séquentiel d'adresses. Changeons la signature de cette méthode pour inclure ce paramètre. Supprimons maintenant le champ relatif au nombre initial d' adresses générées dans cette classe. Et remplacons-la ici par la variable nombre d' adresses générées. Passons maintenant à la mise à jour des adresses de portefeuille actuelles . Le service définira le champ du nombre initial d'adresses générées comme dernier paramètre de cet appel de méthode. Créons maintenant la classe de test du portefeuille de chargement dans le package de test de l'interface graphique. Cela étendra la classe de test de l'interface graphique. Passons au test d'envoi de Bitcoin pour copier cette partie du code, car nous en aurons besoin pour notre nouveau test. Et nous allons le coller ici. Passons maintenant à la classe de test de réception de Bitcoin. Copions ce premier test et utilisons-le comme base pour notre nouveau test. Renommez-le pour qu'il charge portefeuille et reçoive du Bitcoin. Formatons ce test. Ajoutons un bloc donné à ce test. Ici, définissons un nom de portefeuille et des variables de mot de passe. Définissons également une variable de départ mnémotechnique. Nous utiliserons la méthode de création du service de semences mnémotechniques pour le générer. Injectons le service de démarrage mnémonique dans la classe de test de l'interface graphique. Maintenant, appelons la méthode create wallet ici, passant le nom du portefeuille, le mot de passe et la graine mnémotechnique comme paramètres. Créons cette méthode dans la classe de test de l'interface graphique. Ici, nous allons créer un portefeuille l'aide du service Create Wallet. Injectons-le donc dans cette classe. Appelons maintenant la méthode create lui transmettant ces paramètres. Nous allons maintenant utiliser le service Save Wallet. Injectons-le donc dans cette classe. Et appelons-la méthode Save Wallet, en passant le portefeuille comme paramètre. Enfin, renvoyons le portefeuille ici. Revenons au test du portefeuille de chargement. Maintenant que nous avons créé et enregistré un portefeuille, je vais essayer de le charger. Supprimons donc ce code. Appelons la méthode load wallet en passant le nom du portefeuille comme paramètre. Créons cette méthode dans la classe de test de l'interface graphique. Il prendra également un paramètre de mot de passe facultatif avec une chaîne vide comme valeur par défaut. Tout d'abord, nous allons essayer de cliquer sur un composant dont le texte est chargé. Ce composant sera le bouton du menu de chargement, qui se trouvera à côté du bouton Nouveau dans le menu en haut de la fenêtre principale. Ensuite, nous allons déplacer la souris sur un composant contenant le portefeuille de texte. Ensuite, nous nous attendrons à ce qu'un sous-menu contenant tous les noms de portefeuilles chargés apparaisse. Ensuite, nous cliquerons sur celui dont le texte est égal à la variable nommée portefeuille. Ensuite, nous nous attendons à ce qu'une fenêtre de dialogue apparaisse avec un champ de saisie du mot de passe et un bouton OK. Nous allons donc cliquer sur ce champ qui contient l'identifiant éthique du mot de passe du portefeuille de chargement. Nous allons maintenant saisir le mot de passe dans ce champ. Ensuite, nous cliquerons sur le bouton OK. Enfin, appelons la méthode sleep pour attendre le chargement du portefeuille. D'accord, le reste du test se déroulera de la même les tests de portefeuille de réception que nous avons utilisés comme base pour ce test enverront des bitcoins au portefeuille chargé et s'attendront à ce que les adresses et les tables de transactions soient rempli avec les valeurs appropriées. Passons maintenant au fichier FXML Playground Dot pour concevoir le menu de chargement. Ajoutons une commande de menu à la barre de menus. Modifions son texte à charger. Maintenant, ajoutons une commande de menu au menu de chargement. Supprimons cet élément de menu qui a été ajouté automatiquement. Changeons les textes de ce menu en portefeuille. Et supprimons cet élément de menu. Maintenant, dans la vue de l'éditeur de texte, ajoutons un Fx ID à cette balise de menu. Configurons-le pour charger le menu FXML. Ajoutons-le au contrôleur de fenêtre principal. Ajoutera une annotation FXML et la transformera en champ privé. Ajoutons maintenant la classe de menu de chargement dans le package observables. Cette classe sera chargée de gérer les éléments de menu qui seront ajoutés pour chaque portefeuille nous créons dans notre application. Ajoutons-y une annotation de composant. Créons le champ des éléments de menu ici. Ce sera un ensemble observable de type entité de portefeuille. Nous allons l'instancier à l'aide d'un nouveau wrapper d'ensembles observable, en lui transmettant un nouveau LinkedHashSet. Créons maintenant la bonne méthode des éléments de menu observables ici. Cela renverra les éléments du menu. Créons maintenant l'écouteur du menu de chargement dans le package GUI point listeners. Cet écouteur sera déclenché par l' événement gooey Started publié après le démarrage de l'application. Nous l'utiliserons pour charger tous les portefeuilles enregistrés dans la base de données et les ajouter au menu de chargement. Ajoutons-y une annotation de composant. Il implémentera la classe d'écoute de l'application avec l'événement de démarrage de l'interface graphique comme paramètre de type. Mettons en œuvre sa méthode. Nous utiliserons le référentiel du portefeuille ici. Injectons-le donc dans cette classe. Injectons également le menu de chargement dans cette classe. Ensuite, nous appellerons la dernière méthode pour charger tous les portefeuilles depuis la base de données. Pour chaque portefeuille, vous appellerez la méthode d'ajout de portefeuille. Créons cette méthode encapsulée dans l'appel ultérieur de la plateforme, appelons la méthode add du menu de chargement, en passant l' entité du portefeuille comme paramètre. Créons cette méthode et la classe de menu de chargement. Ici, il suffira d'appeler les éléments du menu add method en passant l' entité du portefeuille comme paramètre. Copions maintenant cette ligne. Passons à la classe de service Save Wallet. Nous allons le coller ici. Injectons le menu de chargement dans cette classe. Avec ce code, notre portefeuille nouvellement enregistré sera ajouté au menu de chargement. Passons maintenant au point FXML du terrain de jeu. Copions ces lignes et collons-les dans le FXML de la fenêtre principale. Passons maintenant au contrôleur de fenêtre principal. Dans la méthode initialisée, toutes les modifications du menu de chargement observables seront liées au menu de chargement. composant Fxml aura besoin du menu de chargement ici. Injectons-le donc dans cette classe. Maintenant, appelons-y la méthode get observable menu items. Et appelons la méthode ad listener sur le résultat en tant que paramètre. Nous allons passer le Lambda suivant. Le corps Lambda ajoutera l'élément et le stockera dans la variable de portefeuille comme ceci. Ensuite, nous utiliserons une instruction if pour vérifier si le menu contient le portefeuille comme celui-ci. Créons cette méthode. L'utilisation de la transformation de flux suivante permet de vérifier si le menu de chargement FXML contient un élément de menu portant le même nom que la variable d'entité du portefeuille. Ici, si le menu de chargement FXML ne contient pas le portefeuille, vous l'ajouterez. Instanciera un objet d'élément de menu en passant comme paramètre, le nom du portefeuille. Ensuite, nous ajouterons l'élément de menu au menu de chargement FXML, comme ceci. Passons maintenant à la classe de test de l' interface graphique dans la méthode de démarrage avant que chaque test ne nettoie la base de données afin que les portefeuilles noms dupliqués en bois ne soient pas conservés. Ainsi, nous évitons les blocages des tests dus à la contrainte de nom unique dans la table des portefeuilles. Nous aurons besoin du référentiel du portefeuille ici. Injectons-le donc dans cette classe. Ensuite, nous appellerons la méthode Supprimer tout. Maintenant, exécutons notre nœud. Et lançons le test du portefeuille de chargement. OK, le test s'est déroulé jusqu'à la partie attendue et a échoué. Nous avons pu constater que notre menu de chargement avait été créé et renseigné avec le nom du portefeuille créé. Bon. Dans la prochaine vidéo, nous continuerons à implémenter cette fonctionnalité, C. Oui. 69. 67 Load Wallet partie 2 skillshare 2: Dans cette vidéo, nous allons continuer à implémenter la fonctionnalité de chargement du portefeuille. Pour commencer, nous allons créer une fenêtre de dialogue qui apparaîtra après avoir cliqué sur le nom du portefeuille que nous voulons charger et le menu de chargement comme base pour le créer. Nous utiliserons la boîte de dialogue Créer un portefeuille. Passons donc à la boîte de dialogue FXML de création de portefeuille. Copions tout ce contenu. Créons le fichier FXML du dialogue de chargement du portefeuille dans le package FXML. Et payons le contenu copié ici. Remplaçons le texte de l'en-tête du dialogue par la phrase suivante. Changeons l'attribut pref height à 300. Supprimons également ces lignes. Passons au Scene Builder pour voir à quoi il ressemble. Remplaçons le texte de cette étiquette par le mot de passe du portefeuille. Dans la vue de l'éditeur de texte, changeons cet identifiant FX pour charger le mot de passe du portefeuille. Et changeons le contrôleur FX du Dialogue Pain Tag pour charger le contrôleur de dialogue Wallet. Créons cette manette. Ajoutons-y l' annotation du composant. Et ajoutons tous ces champs FXML au contrôleur. Passons maintenant au contrôleur de fenêtre principal avant d'ajouter l' élément de menu au menu de chargement FXML Nous allons appeler la méthode set on action sur celui-ci, transmettant le Lambda suivant. Cela obligera l' application à exécuter la méthode de dialogue Open Load Wallet, en passant le portefeuille comme paramètre après avoir cliqué sur cet élément de menu. Créons donc cette méthode. Copions le contenu de la méthode de dialogue Open Create Wallet et utilisons-la la méthode de dialogue Open Create Wallet comme base pour notre nouvelle méthode. Réglons le titre du dialogue pour charger le portefeuille. Remplaçons le premier paramètre d'instanciation du chargeur FXML par le champ de dialogue Load Wallet. Injectons ce champ dans cette classe. Ajoutons cette annotation de valeur ici et changeons son paramètre dans le fichier FXML du portefeuille de chargement. Maintenant, nous devons passer le portefeuille au contrôleur de dialogue du portefeuille de chargement. Pour ce faire, récupérons d'abord le contrôleur à partir du chargeur FXML. Appelons ensuite cette méthode de portefeuille définie dessus, en lui passant le portefeuille. Créons cette méthode. Ici. Nous allons simplement définir le champ d'entité du portefeuille la variable portefeuille. Créons ce champ. Maintenant, créons la méthode initialisée qui sera exécutée après l'apparition de la boîte de dialogue. Copions ce code et le contrôleur de dialogue Create Wallet et collons ici. Cela définira l' action de fermeture de la fenêtre de dialogue sur le bouton d'annulation. Copions et collons également ce code dans la nouvelle méthode initialisée. Cela définira l'action du bouton OK. Mais au lieu d'appeler la méthode create wallet, elle appellera la méthode load wallet. Créons-le. D'abord. Nous allons récupérer une nouvelle entité de portefeuille dans la base de données et la définir comme champ d'entité de portefeuille. Pour ce faire, nous aurons besoin du référentiel du portefeuille. Injectons-le donc dans cette classe. Ensuite, nous appellerons la méthode find by name dessus, transmettant le nom de l' entité du portefeuille. Créons cette méthode. La méthode sera la suivante. Spring Boot Data JPA magic traduira automatiquement le nom de cette méthode en requête SQL et récupérera l'entité du portefeuille avec le nom passé en paramètre depuis la base de données. Nous allons maintenant créer un objet de portefeuille. Pour ce faire, nous devrons créer un service de portefeuille. Injectons-le donc dans cette classe. Nous appellerons la méthode create en passant les paramètres suivants. Tous ces paramètres, à l'exception du mot de passe du portefeuille, seront extraits de l'entité du portefeuille trouvée dans la base de données. Le mot de passe sera extrait du champ de dialogue du mot de passe. Injectons l' objet contextuel dans cette classe. présent, l'utilisation du contexte publiera un événement de portefeuille chargé lui transmettant ce portefeuille et le portefeuille créé. Enfin, nous appellerons la méthode hide pour fermer la fenêtre de dialogue de cette manière. Créons la classe d'événements du portefeuille chargé. Transmettra le paramètre du contrôleur de dialogue Load Wallet au super constructeur. Et nous allons définir le champ du portefeuille sur le paramètre constructeur du portefeuille. Créons un getter pour le champ du portefeuille. Maintenant, nous allons procéder à quelques refactorisations dans l'écouteur d'importation de portefeuille créé. Nous voulons qu'il soit à l'écoute des événements liés aux portefeuilles chargés. Mais dans l'état actuel des choses, il ne peut écouter que l'événement du portefeuille créé. Pour changer cela, supprimons cette instruction d'implémentation et cette annotation Override. Changeons le nom de cette méthode pour importer le portefeuille et son paramètre dans un objet de portefeuille. Changons le paramètre de méthode d'importation du portefeuille en Wallet. Créons maintenant une méthode annotée avec l'annotation Event Listener. Il sera appelé lors de l'événement de portefeuille créé, et il recevra un événement de portefeuille créé en tant que paramètre. Ici, nous appellerons la méthode du portefeuille d'importation, en passant le portefeuille d'événements comme paramètre. Cette refactorisation continuera à faire en sorte que les choses fonctionnent comme avant. Mais maintenant, si nous voulons écouter un autre événement, nous pouvons simplement créer une autre méthode annotée d'écoute en passant l'événement que nous voulons comme paramètre. C'est exactement ce que nous allons faire maintenant L'événement load wallet appellera également la méthode import wallet ici, transmettant le portefeuille d'événements comme paramètre. Cela obligera le nœud Bitcoin à importer le portefeuille, comme lorsque nous créons un nouveau portefeuille. Créons maintenant la classe d'écouteur de portefeuille chargée dans le package Listeners. Ajoutons-y l' annotation du composant. Créons une méthode annotée Event Listener appelée événement de portefeuille déchargé. Il prendra comme paramètre un événement de portefeuille chargé. Ici, nous appellerons la méthode load wallet en passant le portefeuille d'événements comme paramètre. Créons cette méthode. Ici. Nous aurons besoin de la mise à jour du service de portefeuille actuel. Injectons-le donc dans cette classe. Et nous y appellerons la méthode de mise à jour. Le passage du portefeuille en tant que paramètre nécessitera également la mise à jour du service UtxOS. Injectons-le donc dans cette classe. Ensuite, nous appellerons la méthode de mise à jour qui s'y trouve, en transmettant les adresses et le nom du portefeuille comme paramètres. Avec ces deux lignes de code, nous nous attendons à ce que le portefeuille actuel soit remplacé par le portefeuille chargé et que ses adresses, transactions et soldes soient mis à jour en conséquence. Corrigons maintenant quelques tests. Nous avons cassé les vidéos précédentes lors du test du générateur séquentiel d'adresses. Supprimons ce premier paramètre dans l'instanciation du générateur séquentiel d'adresses. Et définissons 20 comme dernier paramètre de cette méthode. Faisons ce test. Super, ça fonctionne comme prévu. Faisons de même avec le test du service Create Wallet. OK, ça marche. Maintenant. Laissons fonctionner notre nœud. Nettoyons et compilons le projet à l'aide de cette fonctionnalité Maven IDE. Et lançons le test du portefeuille de chargement. Cela a échoué. Le problème se situe dans le contrôleur de fenêtre principal. Ici, nous devons appeler la méthode get controller du chargeur FXML au lieu de la méthode load. Faisons à nouveau le test. Super, c'est passé. 70. 68 Load Wallet partie 3 skillshare 2: Dans cette vidéo, nous allons ajouter d'autres tests et apporter quelques optimisations à la fonctionnalité de chargement du portefeuille. L'une des caractéristiques de notre portefeuille est le déni plausible. Dans ce contexte, le déni plausible est une fonction de sécurité qui vous permettra de masquer les adresses de votre portefeuille en saisissant un mot de passe différent pour charger votre portefeuille. Cela signifie que notre portefeuille ne contiendra pas de mauvais mots de passe. Chaque mot de passe saisi donnera accès à un ensemble d'adresses différent, mais l'observation de tiers ne sera pas en mesure de déterminer si les adresses de portefeuille chargées contiennent la majeure partie de vos fonds. Créons un test pour ce scénario. Dupliquons ce test et utilisons-le comme base pour notre nouveau test. Renommez-le pour qu'il charge le portefeuille avec un mot de passe différent et recevez des bitcoins. Nous allons le reformater. Augmentons le numéro nommé du portefeuille. Nous allons maintenant définir cette variable de mot de passe différente et la transmettre à la méthode load wallet comme deuxième argument. Passons-le également comme dernier paramètre de la méthode valide des adresses. Définissons le paramètre de mot de passe comme paramètre facultatif pour cette méthode, en définissant sa valeur par défaut sur une chaîne vide. Remplaçons la variable de mot de passe par la chaîne vide et la méthode des deux clés principales. Laissons fonctionner notre nœud. Commentons cette méthode et lançons notre nouveau test. Super, c'est passé. Ce test montre que notre application prend déjà en charge n'importe quel mot de passe pour charger un portefeuille et que chaque mot de passe génère un ensemble d'adresses distinct. Décommentons ce test. Compte tenu de notre façon de voir un portefeuille comme ayant plusieurs ensembles d'adresses en fonction de leurs mots de passe. Nous devons corriger un problème dans notre application. Lorsque nous passons des appels vers notre nœud Bitcoin via notre application, nous utilisons le nom de notre portefeuille. Cela pose problème car pour des opérations telles que la récupération de notre portefeuille, des transactions et UTXO depuis notre nœud collecteront les mêmes informations pour différents ensembles d'adresses générés par différents mots de passe. Pour optimiser notre note, les appels RPC et collecter uniquement les informations relatives aux adresses générées avec un mot de passe donné, utiliseront la première adresse de réception générée comme nom du portefeuille important pour notre nœud. Pour ce faire, passons à l'enregistrement du portefeuille. Créons ici la bonne méthode de première adresse. Il utilisera la méthode get addresses pour renvoyer la première adresse du portefeuille. Maintenant, nous devons remplacer chaque appel vers le champ du nom du portefeuille qui a été passé pour communiquer avec notre nœud par un appel de méthode de première adresse Utilisons notre identifiant pour identifier les utilisations de le champ du nom et effectuez le refactoring. Passons maintenant au service de mise à jour du portefeuille actuel et définissons la première adresse du portefeuille actuel. Créons cette méthode. Ici. Nous allons définir le premier champ d'adresse sur le paramètre reçu. Créons ce champ. Et créons un getter pour cela. Maintenant, remplaçons la méthode getName actuels du portefeuille les appels à la méthode wallet get first address actuels. Passons maintenant au test du portefeuille de chargement, commentons le premier test et exécutons le test restant. Les grandes choses continuent de fonctionner comme avant. Décommentons ce test. Passons maintenant à la classe de configuration d'adresses. Puisque nous utilisons désormais la première adresse de portefeuille pour interagir avec notre nœud, la première adresse doit toujours être la même pour une combinaison de code mnémotechnique et de mot de passe. Par conséquent, nous devons garantir que la liste des configurations d' adresses et leurs adresses se trouvent toujours dans le même ordre. Pour ce faire, utilisons l' annotation de commande dans les deux beans. Ajoutons l' annotation de commande avec zéro comme argument dans ce premier Bean. Cela obligera Spring à injecter ce bean dans les listes de configuration d' adresses en tant que premier élément. Remplaçons également le deuxième argument de l'objet de configuration d'adresse par un Hashmap lié. Contrairement aux cartes générées par la méthode map, le Hashmap lié conserve l'ordre d'insertion y parviendra en utilisant le code suivant. Faisons maintenant le même refactorisation à l'autre bean de configuration Red Dress. Et ajoutons l'annotation de commande ici en utilisant une comme paramètre, garantissant qu'elle sera injectée après la première activation des configurations d'adresses par le bean. Maintenant, faisons une autre optimisation. L'importation d'adresses vers notre nœud est parfois lente. Pour éviter d' importer inutilement des adresses sur notre nœud, nous vérifierons si elles sont déjà importées. Pour ce faire, créons le nœud reçu par le client d' adresse dans le package client node point. Ce client récupérera toutes les adresses actuellement chargées par notre nœud. Ajoutons-y l' annotation du service. Et injectons-y le client du nœud. Créons maintenant la méthode des listes d' adresses ici. Il renverra une liste d'objets d'adresse de nœud en tant que paramètres. Il faudra un nom de portefeuille. Amen conf, qui définira le nombre minimum de conformations des adresses renvoyées. Le paramètre include empty, qui définira si l'appel renverra des adresses sans fonds. Et le paramètre include watch only qui indiquera au nœud si nous voulons récupérer des adresses dont le nœud ne connaît pas les clés privées correspondantes. Créons l'enregistrement de l'adresse du nœud dans le package de nœuds à points du domaine. Il ne comportera qu' un champ d'adresse. Utilisation du client de nœud. Passons l'appel RPC ici. Il renverra un tableau d' adresses de nœuds. Le premier paramètre de la méthode make request sera la liste reçue par chaîne d'adresse. Ensuite, nous allons transmettre un nouvel objet de référence de type paramétré. Ensuite, l'URL du portefeuille. Enfin, les paramètres de méthode vestimentaire listés que nous avons décrits précédemment. Nous allons maintenant renvoyer une conversion du tableau d'adresses de nœuds en une liste d'adresses de nœuds comme celle-ci. Passons maintenant au service de portefeuille d'importation. Ici, nous allons ajouter une instruction if pour vérifier si les adresses des portefeuilles n'ont pas été importées de cette manière. Créons cette méthode. Inside the if body utilisera la méthode d'importation des adresses pour importer les adresses uniquement si elles n'ont pas été importées auparavant. Implémentons la méthode d' adresse importante. Nous obtiendrons les adresses importées en utilisant le nœud reçu par le client d'adresses. Injectons-le donc dans cette classe. Ensuite, nous appellerons la méthode des listes d'adresses. La transmission des paramètres suivants convertira le résultat en flux et utilisera la méthode map pour extraire toutes les adresses des nœuds. Ensuite, nous convertirons le résultat en un ensemble d'adresses à l'aide de la méthode de collecte. Ensuite, nous allons convertir les adresses des portefeuilles en un ensemble comme celui-ci. Maintenant, en utilisant la méthode de suppression sur les adresses du portefeuille, toutes les adresses importées seront supprimées de celui-ci. Enfin, nous vous renverrons les adresses du portefeuille si appelez la méthode vide. Si le résultat est vrai, toutes les adresses de portefeuille ont déjà été importées. Oh, nous avons oublié de supprimer cette ligne. Allons-y. À présent. Passons au test d' envoi de Bitcoin. À partir de maintenant, nous ajouterons quelques assertions concernant la fonctionnalité de chargement du portefeuille à certains tests. Ensuite, si nous trouvons des bogues dans le processus, nous les corrigerons. Commençons par le premier test d'envoi de Bitcoin. Supprimons cette ligne à sa place. Ajoutons un appel à la méthode Weight Load Wallet. L'utilisation de cette méthode permettra d'accélérer l'exécution de ce test. Créons-le dans la classe de test de l'interface graphique. Ici, appelons la méthode Wafer. Transmettre ces paramètres. À chaque itération de ce rappel, nous utiliserons la méthode sleep pour attendre 1 s. Ensuite, nous vérifierons si la première adresse du portefeuille actuel est définie. Injectons donc le portefeuille actuel dans cette classe. À l'aide de la liste de nœuds, le client des portefeuilles vérifiera si le nœud a chargé l'adresse avec la première adresse du portefeuille actuel. Injectons donc ce service dans cette classe. Avec ce code, vous attendrez que le nœud charge le portefeuille. Maintenant, nous allons résoudre un problème qui peut parfois entraîner des échecs de test. Ici, le paramètre de taille totale attendu est égal à la somme de l'indice d' itération actuel plus un. Créons maintenant la dernière variable d'adresse de réception qui définira sa valeur sur l'adresse de réception présente dans la fenêtre. Maintenant, définissons d'autres variables qui nous aideront à comparer les valeurs du portefeuille avant et après son chargement. Tout d'abord, la taille de la table des transactions. Ensuite, le solde du tableau des transactions de la première ligne. Appelons maintenant la méthode load wallet en passant le nom du portefeuille comme paramètre. Définissons cette variable ici. Nous allons maintenant définir la table des transactions après la variable de chargement. Nous l'obtiendrons en utilisant la méthode de recherche comme avant de le charger. Ensuite, nous cliquerons sur l'onglet adresses et définirons la table des adresses après chargement de la variable de la même manière. Ensuite, nous allons cliquer sur l'onglet Recevoir et définir la dernière adresse de réception, la variable de post-chargement et le texte du libellé après la variable de chargement. Maintenant, dans le bloc then, supprimons ces deux lignes. Et comparons les dernières variables d'adresse de réception avant et après le chargement du portefeuille. Définissez ensuite la taille de la table des adresses et variables équilibrées de la table des adresses de la première ligne ici. Et ajoutons ces deux comparaisons qui sont égales à celles que nous venons de supprimer. Maintenant, comparons les tailles des tables d'adresses avant et après le chargement du portefeuille. Et faisons de même avec l'équilibre de la première ligne de la table d'adresses. Supprimons maintenant ces deux lignes en les remplaçant par les lignes suivantes, qui font les mêmes comparaisons mais utilisent les variables refactorisées. Et ajoutons les comparaisons suivantes des variables avant et après le chargement du portefeuille. Commentons tous les autres tests de ce fichier. Et lançons le test restant. Le test a échoué car les dernières adresses de réception avant et après le chargement du portefeuille sont différentes. Dans la prochaine vidéo, nous allons résoudre ce problème. 71. 69 Load Wallet partie 4 skillshare 2: Dans cette vidéo, nous allons corriger l'erreur liée au fait d'avoir des adresses de réception différentes avant et après le chargement d'un portefeuille. Cela se produit parce que nous utilisons UTXOS pour mettre à jour l'index actuel des adresses de réception. Après avoir chargé le portefeuille et récupéré le portefeuille UTXOS, les anciennes sorties utilisées pour mettre à jour l' adresse de réception ne font plus partie de l'ensemble UTXO car elles étaient déjà dépensées. Ainsi, l'adresse de réception finit par ne pas être mise à jour. Nous allons résoudre ce problème en transférant le code responsable de la mise à jour des adresses de réception du service de mise à jour des adresses de portefeuille actuelles vers une nouvelle classe. Dans la nouvelle classe, nous utiliserons les transactions récupérées depuis le nœud contenant toutes les adresses utilisées par les portefeuilles pour mettre à jour les adresses de réception actuelles. Créons donc cette classe qui sera appelée mettre à jour l' adresse de réception du portefeuille actuel de son service dans le package GUI point services. Ajoutons l' annotation du service ici. Maintenant, copions et collons du code du service de mise à jour des adresses de portefeuille actuelles dans cette classe. Ajoutons cette annotation qualificative. Créons maintenant la méthode de mise à jour ici. Il faudra une liste des transactions entre nœuds. L'utilisation de la méthode map permet d'obtenir un flux d' adresses à partir du flux de transactions entre nœuds. Ensuite, nous filtrerons le flux pour qu'il ne contienne que les adresses du portefeuille actuel. Ensuite, nous appellerons la méthode mark is used sur chaque adresse. Reprenons cette méthode du service de mise à jour des adresses de portefeuille actuelles. Nous allons maintenant appeler la méthode actuelle de saisie des types d'adresses du portefeuille . Créons cette méthode. Il renverra le résultat de l'appel de la méthode addresses get addresstypes. Il renverra un ensemble de types d'adresses. Créons cette méthode dans la classe d'adresses. Ici, vous renverrez simplement le jeu de clés du champ d' adresses. Maintenant, pour chaque type d'adresse, nous allons appeler la méthode de réception des mises à jour. Pour cela, le type de ce paramètre de méthode sera remplacé par le type d'adresse. Et nous supprimerons cette ligne car nous n'en aurons plus besoin. Passons maintenant au service de mise à jour des adresses de portefeuille actuelles pour supprimer le même code que nous avons collé notre nouvelle classe et ses utilisations. Passons maintenant au service de mise à jour UtxOS. Injectons le service de mise à jour des adresses de réception du portefeuille actuel dans cette classe. Et appelons la méthode de mise à jour depuis le service injecté en passant les transactions du nœud comme paramètre. Passons maintenant au test d' envoi de Bitcoin. Ajoutons l'appel à la méthode de sommeil ici pour éviter une nouvelle condition de course qui peut se produire. Cela permet parfois de s'assurer que votre nœud fonctionne. Et faisons ce test. Le problème d'adresse de réception a été résolu, mais le test a échoué en raison d'un autre bogue. Le solde de la transaction après le chargement d'un portefeuille n'est pas mal calculé. Réglons ce problème. Pour résoudre ce bogue, nous devons mieux comprendre le fonctionnement de l'API de transactions de liste Bitcoin Core. Voici la documentation de l'API Bitcoin Core pour la liste des transactions. Notez que pour chaque transaction, l'API ne renvoie qu' un seul champ d'adresse. Le montant fait uniquement référence au montant en bitcoins envoyé à cette adresse , qui négatif s' il n'appartient pas à notre portefeuille et positif dans le cas contraire. Si la transaction génère une modification, l'API renvoie plusieurs registres pour chaque transaction. Chaque registre possède un champ d'adresse de la sortie de transaction. Voyons un exemple du résultat de cette API pour une transaction envoyée depuis notre portefeuille avec une entrée et deux sorties. Pour la même transaction, l'API a renvoyé trois registres. Nous pouvons voir qu'ils font référence à la même transaction en examinant leurs numéros de transaction. Notez que les deux premiers registres ont la même adresse. Ces registres font référence à la sortie du changement. Le premier a un montant positif indiquant qu'il s'agit d'une adresse appartenant à notre portefeuille. Il s'agit du montant de la modification. Le deuxième registre a le même montant, mais il est négatif. Cela signifie que nos portefeuilles ont envoyé un montant à cette adresse. Il comporte également des frais négatifs, qui correspondent aux frais de transaction que nous avons payés lors de la transaction. Si nous additionnons le montant des deux premiers registres, nous obtenons zéro, qui correspond exactement au solde que nous avons payé nous-mêmes lors de la transaction. Enfin, le troisième registre contient un montant négatif indiquant que nous envoyons des bitcoins à cette adresse. Il comporte également une redevance égale à celle du deuxième registre. Compte tenu du fonctionnement de cette API, la bonne façon de calculer le solde de la transaction consiste à additionner les montants enregistrés retournés pour la même transaction et les frais de l'une d' entre elles enregistre, la transaction équilibrée avant de charger un portefeuille est correcte car nous la calculons de manière à prendre en compte la deuxième transaction créée avant de l'envoyer à notre nœud. Une fois que nous avons chargé notre portefeuille, nous perdons les informations de transaction qui ne sont pas prises en compte pour calculer le solde de la transaction. Passons donc au service de transaction Update Current Wallet pour résoudre le problème. Notre nouvelle solution n'aura plus besoin de ce filtre. Supprimons donc cette ligne à sa place. Ajoutons un appel à la méthode de collecte comme paramètre. Nous appellerons les collecteurs en les regroupant par méthode transmettant une référence à la transaction du nœud (TX ID) avec ce code, nous obtiendrons une carte où les clés seront des identifiants de transaction et les valeurs seront des listes de transactions de nœud avec le même ID de transaction. Appelons la méthode des valeurs sur le résultat plutôt que la méthode stream pour obtenir un flux de listes de transactions entre nœuds avec le même T XID. Le reste de cette méthode reste tel quel. Créons la transaction à partir de la méthode. Il prendra une liste des transactions des nœuds et renverra une ligne de transactions. Déplaçons cette méthode ici. Commençons par les frais de transaction. Je le retirerai d'un flux sans frais de transaction. Créons le champ de frais dans la transaction du nœud. Ensuite, nous filtrerons le stream pour des frais nominaux. Ensuite, nous facturerons d' abord l'amende pour que les premières soient remboursées et utiliserons la méthode URL pour renvoyer zéro si aucun frais n'est trouvé. Maintenant, calculons le montant. L'utilisation de la méthode map permet d' obtenir un flux contenant tous les montants des transactions de nœud à partir du flux de transactions de nœud. Ensuite, nous utiliserons la méthode réduite, transmettant la référence de la méthode d'addition décimale à grande échelle à certains montants. Enfin, nous utiliserons la méthode or else pour renvoyer zéro sans qu'aucune transaction ne soit trouvée. Copions et collons maintenant cette ligne ici. Nous utiliserons l'identifiant TX de la transaction du premier nœud comme premier paramètre de l'instanciation de la ligne de transaction. Ensuite, nous ajouterons les frais de transaction obtenus au montant et transmettrons le montant en tant que paramètre ici. Enfin, nous transmettrons confirmation de la transaction du premier nœud à temps en tant que paramètres d'instanciation de la dernière ligne de transaction . Supprimons cette méthode car nous n'en aurons plus besoin. Réexécutons ce test d'envoi de Bitcoin. Le premier test a réussi, mais le second a échoué en raison d'une condition de course. Réparons-le rapidement avec l'appel à la méthode de sommeil ici. Nous corrigerons mieux cette erreur dans la prochaine vidéo. Pour l'instant, commentons cette ligne pour n'exécuter que la note de test ayant échoué . Le test est réussi. Décommentons le reste du test. 72. 70 Load Wallet partie 5 skillshare 2 1: Dans cette vidéo, nous allons ajouter d'autres assertions de test pour vérifier si nous pouvons charger correctement un portefeuille avec plus d' adresses générées que le nombre initial d'adresses générées par la configuration. Mais d'abord, optimisons une méthode de test afin d'éviter certaines conditions de course lors de certains tests. Dans la classe de test Send Bitcoin. Supprimons ces deux appels à la méthode du sommeil, car notre solution permettra de mieux gérer les conditions de course fois que nous aurons envoyé des bitcoins. Passons à la classe de test de l'interface graphique. Ajoutons ce paramètre facultatif dans la méthode send Bitcoin and wait avec la valeur par défaut égale à l'adresse de réception du hashtag. Ajoutons ensuite ce qui suit et la condition à cette valeur de retour. Avec ce code, l'attente ne s'arrêtera que si le champ d'adresse de réception est différent de la variable d' adresse. Par conséquent, nous évitons l'erreur d'envoyer des Bitcoins à la même adresse deux fois de manière séquentielle. Passons maintenant au test de réception de Bitcoin. Dans le dernier test de cette classe, nous ajouterons quelques assertions pour vérifier si nous pouvons charger correctement un portefeuille avec plus d'adresses générées que le nombre initial d'adresses générées par la configuration. Définissons donc le portefeuille nommé variable et remplaçons cette variable par le paramètre de la bonne méthode. Appelons maintenant la méthode Weight Load Wallet ici et supprimons les appels à la méthode de sommeil de ce test. Maintenant, après avoir reçu des Bitcoins sept fois, définissons la dernière variable d' adresse de réception sur la valeur présente dans le champ d'adresse de réception. Maintenant, copions cette ligne dans le test Sand Bitcoin et collez-la ici. Changeons cette variable pour répondre à sa vue tabulaire. Faisons de même avec cette autre ligne. Maintenant, copions et collons toutes ces lignes entre le test d'envoi de Bitcoin et notre test. Copions et collons également cette ligne dans notre nouveau test afin de comparer la dernière adresse de réception avant et après le chargement du portefeuille. Ajoutons cette ligne pour comparer la taille de la table des transactions avant et après le chargement du portefeuille. Sur cette ligne, nous ferons de même avec la taille de la table des adresses. Et cette autre ligne comparera le texte de l'étiquette avant et après le chargement du portefeuille. Laissons fonctionner notre nœud. Commentons les autres tests de cette classe et lançons notre nouveau test. Le test a échoué en raison de la différence entre la dernière adresse de réception avant et après le chargement du portefeuille. De plus, si vous avez remarqué le nombre d' adresses dans la table des adresses après le chargement, il n'est que de trois alors que le nombre correct serait de sept. Cela est dû au fait que nous n'enregistrons pas le nombre d' adresses générées une fois que nous les avons générées. Réglons ce problème. Passons à la mise à jour des adresses de réception des portefeuilles. Le service actuel aura besoin du référentiel du portefeuille ici. Injectons-le donc dans cette classe. Nous allons maintenant appeler la méthode du nombre incrémentiel d' adresses générées dans le référentiel du portefeuille. Ses paramètres transmettront le nombre initial d'adresses générées et le nom actuel du portefeuille. Créons cette méthode. Remplaçons ce paramètre de type la classe entière et ce nom de paramètre par incrément. Comme son nom l'indique, cette méthode incrémentera le nombre de champs d'adresses générés dans notre portefeuille. Pour ce faire. Ajoutons-y l' annotation transactionnelle. Cette annotation est requise par la bibliothèque JPA car elle effectuera l'opération SQL en deux étapes. Ajoutons également l'annotation modificatrice. Cette annotation est requise par les méthodes de référentiel qui modifient les registres et les tables, ce qui est le cas. Enfin, ajoutons l' annotation de requête à cette méthode. Cette annotation indiquera l'opération SQL que nous voulons effectuer en tant que paramètre. Ajoutons la chaîne suivante. Cette instruction de type SQL ajoutera au nombre d'adresses générées la valeur d'incrément transmise comme premier argument à la méthode annotée. La clause where fera en sorte que cette opération ne se produise que dans le portefeuille dont le nom est égal au paramètre name. Pour lier les paramètres de la méthode aux variables SQL. Ajoutons ces deux annotations de poèmes à ces paramètres. Maintenant, refaisons notre test. Super, c'est passé. Notre fonctionnalité de portefeuille de chargement est terminée. Maintenant, il est important d'exécuter tous nos tests d'application pour vérifier si un bogue est apparu. Mais d'abord, nous allons corriger et optimiser certains de nos tests pour utiliser la méthode Weight Load Wallet et supprimer certains appels de méthode de sommeil qui ne sont plus nécessaires. Tout d'abord, peu communs à ces tests. Et faisons les optimisations mentionnées. Dans les tests de segments imbriqués, tels que ceux de cette classe, nous devons ajouter certains paramètres pour envoyer des bitcoins et un appel à la méthode d' attente. Alors allons-y. Le dernier paramètre de ces appels doit être la chaîne hashtag, segment imbriqué, adresse de réception. Dans certaines méthodes comme celle-ci, nous devons également définir l'identifiant plus un est le troisième argument de l'appel à la méthode send Bitcoin and wait. Maintenant, nous pouvons exécuter tous nos tests d'application. Ils doivent tous passer dans ma machine. Ils prennent une demi-heure. J'ai donc laissé cet exercice à l'étudiant. 73. 71 Importer un porte-monnaie 2: Dans cette vidéo, nous allons implémenter la possibilité d'importer un portefeuille contenant la graine mnémotechnique. Il est important de disposer de cette option pour récupérer votre portefeuille et les cas où vous perdez, détruisez ou n'avez pas accès au matériel ou aux fichiers contenant l'application ou la base de données contenant les données de votre portefeuille. Dans ces cas, il vous suffit saisir votre source sauvegardée et éventuellement votre phrase secrète dans la fonction d'importation de l'application pour accéder à nouveau à votre portefeuille. Encore une chose, vous ne serez pas obligé de récupérer votre portefeuille. À l'aide de cette application, vous pourrez utiliser les graines mnémotechniques générées par cette application pour récupérer votre portefeuille et d'autres portefeuilles compatibles avec le BIP 39. Vous pourrez également récupérer l'accès aux adresses de votre portefeuille Bitcoin en important votre graine mnémotechnique BIP 39 générée par d'autres portefeuilles dans cette application. Assurez-vous simplement que les deux applications prennent en charge les blocs de dérivation des adresses que vous souhaitez importer. Commençons donc par créer le test du portefeuille d'importation. Cela étendra la classe de test de l'interface graphique. Copions ce code du test d'envoi de Bitcoin et collez-le ici. Créons maintenant un test appelé devrait importer un portefeuille et recevoir du Bitcoin. Dans le bloc unique, définissons le portefeuille nommé variable. Et créons une graine mnémonique en utilisant la méthode de création du service de semences mnémotechniques. Appelons maintenant la méthode d'importation du portefeuille en passant le nom du portefeuille et graine mnémotechnique comme paramètres. Créons cette méthode. Ajoutons également un mot de passe comme troisième paramètre facultatif à cette méthode. Ici, nous allons cliquer sur un menu avec l'importation de texte. Ensuite, nous cliquerons sur l' élément de menu contenant le portefeuille de texte. Maintenant, nous allons cliquer sur le composant avec un identifiant FX ou un nom de portefeuille. Ce composant sera un champ de saisie lequel nous saisirons le nom du portefeuille importé. Ensuite, nous appellerons la méthode write en passant la variable name comme paramètre pour taper le nom dans ce champ. Ensuite, nous cliquerons sur le champ du mot de passe, qui contiendra un identifiant FX ou un mot de passe de portefeuille. Ensuite, nous écrirons le mot de passe dans ce champ. Ensuite, nous allons cliquer sur le champ de départ mnémotechnique et écrire la variable de départ mnémotechnique dans ce champ. Enfin, nous cliquerons sur le bouton OK. Ajoutons également la méthode sleep call pour attendre le chargement du portefeuille. Revenons au test du portefeuille d'importation à l'aide de la méthode de recherche, récupérons la valeur de l'adresse présente dans le champ d' adresse de réception. En utilisant la méthode d'envoi de Bitcoin et d'attente, envoyons 1 000 Satoshi à l'adresse récupérée. Nous allons maintenant cliquer sur l'onglet adresses. Ensuite, en utilisant la méthode de recherche, nous obtiendrons la table des adresses et la stockerons dans une variable. Nous allons cliquer sur l'onglet des transactions, obtenir le tableau des transactions et le stocker dans une variable. Faisons de même avec le texte étiqueté « solde total ». Maintenant, définissons deux variables pour stocker la taille de la table des adresses et la taille de la table des transactions. Ajoutons les assertions suivantes dans ce bloc pour vérifier si les variables précédemment définies ont les valeurs attendues. Dupliquons maintenant ce test. Renommez-le en devrait importer le portefeuille usagé et le bloc reçu. Dans ce test, nous allons créer un portefeuille et y recevoir des Bitcoins avant de l'importer, puis nous allons importer le portefeuille, générer un bloc dans notre note et vérifier si l'application se charge correctement et met à jour le portefeuille importé. Créons donc ici un bloc donné dans lequel nous allons créer un portefeuille et y envoyer un Bitcoin. Maintenant, supprimons cette ligne. Changeons le nom de cette variable pour importer le nom du portefeuille et augmenter son numéro de portefeuille. Nous utiliserons cette variable pour nommer le portefeuille importé, car nous ne pouvons pas créer deux portefeuilles portant le même nom. Passons la variable de mot de passe à cet appel de méthode. Après avoir importé le portefeuille, générons un bloc. Pour ce faire, générons d'abord une adresse de note à l'aide du client node get new address. Ensuite, nous appelons la méthode generate to address, en passant l'adresse du nœud comme paramètre pour générer un bloc. Maintenant, appelons la méthode du sommeil pour attendre que le bloc soit extrait. Enfin, modifions le solde total attendu. Je m'attendrai à un solde d'un Bitcoin confirmé et de zéro Bitcoin non confirmé. Le reste du test reste tel quel. Maintenant. Passons au point FXML du terrain pour concevoir le menu des fonctionnalités d'importation. Dupliquons la balise de menu de chargement et son contenu. Modifions cet attribut de texte pour l'importer. Cet identifiant de fax permet d'importer le menu FXML. Ajoutons également l' attribut action ici avec sa valeur faisant référence à la méthode Open-end Port Wallet. Le dialogue créera cette méthode plus tard pour répondre à un clic sur cet élément de menu en ouvrant un fenêtre de dialogue. Passons au Scene Builder pour voir à quoi il ressemble. OK, le menu Importer a été ajouté à côté du menu de chargement. Copions et collons maintenant ce code dans la fenêtre principale FXML. Créons cette méthode dans le contrôleur de fenêtre principal. Son code sera très similaire à la méthode de dialogue Open Create Wallet. Alors copiez-le et collez-le ici. Changeons le titre de la boîte de dialogue pour importer un portefeuille. Et remplaçons le champ de dialogue Charger le portefeuille par le champ de dialogue d'importation du portefeuille ici. Créons ce champ et injectons-le dans cette classe. L'annotation de valeur ici pointe vers la boîte de dialogue d'importation du portefeuille FXML. Créons maintenant l'entrée sous forme de dialogue FXML dans le package FXML. Utilisons le contenu du dialogue de création de portefeuille FXML comme base pour le créer. Nous allons maintenant modifier le texte de l'en-tête du dialogue. Au lieu de cliquer sur Créer, demandons à l'utilisateur de saisir une graine mnémonique valide. Ensuite, changeons le contrôleur FX pour importer le contrôleur de dialogue du portefeuille. Passons maintenant au Scene Builder. Supprimons le bouton Créer. Mettons une étiquette ici et changeons son texte en date de création. Ajoutons un sélecteur de date à la cellule. Cliquons sur la zone de texte de départ mnémotechnique et rendons-la modifiable. Revenons à l'éditeur de texte. Remplaçons le nom de ce Fix de toilette et cet identifiant de fax par un mot de passe du portefeuille. Réglons le sélecteur de dates FX ID sur la date de création. Créons maintenant le contrôleur de dialogue du portefeuille d'importation dans le package Controllers. Ajoutons-y l' annotation du composant. Ajoutons tous ces champs FXML au contrôleur. Rendons tous ces champs privés. Et ajoutons-y l' annotation FXML. Copions et collons la méthode initialisée depuis le contrôleur de dialogue Create Wallet vers notre nouveau contrôleur. Et faisons de même en faisant en sorte que toutes les entrées requises soient remplies. Remplaçons cette variable de nom par le nom du portefeuille. Copions et collons également cette méthode dans notre nouvelle classe. Dans le gestionnaire d'événements du bouton OK nous appellerons la méthode d'importation du portefeuille. Cette méthode créera simplement un portefeuille en utilisant le type de données de l'utilisateur. Utilisons donc la méthode create wallet du contrôleur de dialogue Create Wallet comme base pour le créer. Injectons le service Create Wallet dans cette classe. Remplaçons ces variables par celles de ce contrôleur. Et injectons le nombre initial d' adresses générées dans cette classe. Faisons de même avec ce champ contextuel. Maintenant, au lieu d'utiliser une nouvelle date comme paramètre de cette méthode, j' appellerai la méthode de la date de facturation. Créons cette méthode. Nous allons utiliser la logique suivante ici. Si l'utilisateur ne choisit pas de date, nous utiliserons la date à laquelle Bitcoin a commencé à fonctionner. S'il le souhaite, nous utiliserons la date choisie. Le paramètre date définira jusqu'où, dans le passé du nœud nous irons pour trouver des informations sur les adresses de portefeuille importées. Plus l'état est ancien, plus le nœud mettra du temps à importer le portefeuille. Utilisons donc la méthode de date par défaut pour définir la date par défaut. Nous allons utiliser ici l'objet de format de date simple avec le paramètre suivant. Ensuite, nous essaierons de renvoyer l'appel simple de la méthode d' analyse du format de date en passant la constante de date par défaut comme paramètre. Nous utiliserons le bloc catch pour encapsuler l'exception d'analyse dans une exception d'exécution. Définissons cette constante, qui est la date à laquelle le Bitcoin a commencé à fonctionner. Ici. Si la date de création n'est pas nulle, nous redéfinissons la variable de date à la valeur suivante. Enfin, nous renvoyons la date. Après avoir créé le portefeuille, l'événement du portefeuille importé sera publié. Créons-le dans le package GUI point events. Ici, nous allons transmettre ce paramètre au super constructeur et définir le champ wallet sur le paramètre wallet. Créons un getter pour ce champ. Passons maintenant à l'écouteur Save Wallet. Cet écouteur répondra aux événements de portefeuille importés pour enregistrer les portefeuilles importés. Refactorisons-le pour qu'il puisse écouter plus d'un événement. Pour ce faire, supprimons cette instruction d'implémentation. Changeons cette méthode en l'appelant événement de portefeuille non créé. Ajoutons-y l'annotation Event Listener. Créons maintenant la méthode d'événement de portefeuille sans importance, en transmettant l' événement de portefeuille importé comme paramètre. Copions et collons cette ligne ici. Et ajoutons l'annotation Event Listener à cette méthode. La définition d'une annotation d'ordre pour méthodes annotées des auditeurs d' événements rendra l'ordre d'exécution de ces écouteurs prévisible. Plus le paramètre d'annotation d'ordre est petit, plus la priorité d'exécution de cet écouteur est élevée par rapport aux autres auditeurs du même événement. Ajoutons donc cette annotation à cette méthode. Passons zéro comme paramètre pour que cet écouteur soit le premier du genre à s'exécuter Ajoutons la même annotation à la méthode d' événement du portefeuille non créée. Nous donnons la priorité à la sauvegarde du portefeuille après sa création afin de garantir qu'en cas d'échec des auditeurs ultérieurs, nous sauvegardons au moins son DataFirst. Passons maintenant à l'écouteur d'importation de portefeuille créé. Nous voulons que cet écouteur importe le portefeuille importé dans le nœud Bitcoin. Dupliquons donc la méthode d'événement du portefeuille déchargé. Changeons son nom en événement de portefeuille sans importance et faisons en sorte qu'il soit l'événement approprié. Ajoutons maintenant l' annotation de commande à ces méthodes. Les auditeurs d'événements de portefeuille importés et créés recevront un comme paramètres et le récepteur d'événements de portefeuille chargé zéro. De cette façon, nous avons garanti que lorsque le portefeuille essaie de récupérer des données depuis le nœud, seront déjà importées par le nœud. Passons maintenant à l'écouteur de portefeuille chargé et ajoutons une méthode d'écoute pour l'événement de portefeuille importé, comme nous venons de le faire dans la classe précédente. Ajoutons maintenant une annotation de commande aux deux méthodes, transmettant comme paramètre pour la méthode d' événement du portefeuille sans importance et une autre pour la méthode d' événement du portefeuille déchargé afin que ces auditeurs s'exécutent tous les autres pour leurs événements. Maintenant, exécutons notre nœud. Et faisons ce test. Le premier test a réussi, mais le second a échoué. Voyons pourquoi. OK, une exception de violation de contrainte s'est produite car nous avons essayé deux fois d'enregistrer un portefeuille portant le même nom. Nous avons oublié de modifier la variable de nom de portefeuille dans l'appel à la méthode d'importation du portefeuille pour la variable de nom de portefeuille d'importation. Corrigons ce problème et relançons le test défectueux. Super, c'est passé. 74. 72 Valider le partage de compétences de portefeuille 2: Dans cette vidéo, nous allons implémenter quelques validations avant créer un portefeuille d'importation et d'essayer d'envoyer des transactions. La première validation empêchera la création du portefeuille de continuer si le nom du portefeuille est égal à un nom créé précédemment. Passons donc au test de création de portefeuille pour créer un test pour cette condition. Il sera appelé ne devrait pas créer de portefeuille avec un nom répété. Créons un portefeuille dans le bloc donné, créant les variables nécessaires et en les utilisant dans la méthode create wallet. Dans le bloc unique, ajoutons du code pour créer un portefeuille portant le même nom que celui créé dans le bloc donné, mais en utilisant maintenant l'interface graphique. Après avoir essayé de créer le portefeuille, ajoutons la méthode sleep call ici Nous nous attendons à ce que l'application affiche une fenêtre de dialogue d'alerte contenant un message indiquant que le nom du portefeuille existe déjà. Définissons donc une variable contenant le message. Nous allons maintenant utiliser la méthode de recherche pour obtenir un composant contenant ce message et le stocker dans la variable de requête node. Enfin, nous allons cliquer sur le bouton OK pour fermer la fenêtre de dialogue. Dans le bloc d'alors. Ajoutons la comparaison suivante pour vérifier si le message dans la fenêtre de dialogue d'alerte est égal à la variable du message d'erreur. Passons maintenant à la manette de dialogue de création de portefeuille. Dans la méthode create wallet, nous utiliserons une instruction if avec un service de validation du portefeuille pour vérifier si le nom du portefeuille est valide. Injectons donc ce service dans cette classe. Créons ce service et le package de services point de base de données. Et finissons de l' injecter dans cette classe. Dans l'instruction if, appelons la méthode wallet exists qui s'y trouve, en transmettant le texte du nom comme paramètre. Créons cette méthode. Nous utiliserons le service d'erreur d'alerte et le corps if. Injectons-le donc dans cette classe. Nous allons maintenant appeler la méthode d'erreur d' alerte qui s' y trouve en tant que paramètre. Passons cette constante. Créons cette constante dans la classe des messages d'erreur. Il contiendra le même texte que celui que nous avons défini dans le test. Importons cette constante ici et appelons la déclaration de retour. Passons maintenant au service de validation du portefeuille. La méthode In the wallet exists dirigera le référentiel du portefeuille. Injectons-le donc dans cette classe. Maintenant, nous allons renvoyer l'appel à la méthode exists by name, en passant le nom du portefeuille comme paramètre. Créons cette méthode simplement par cette signature de méthode Spring Data JPA magic sait déjà comment interroger les informations souhaitées depuis la base de données. Passons au test de création de portefeuille. Commentons ces tests. Exécutez notre nœud et lancez notre nouveau test. Super, le test est passé. Décommentons ces tests. Ajoutons maintenant la validation du même nom de portefeuille dans la fonction d'importation de portefeuille. Copions donc ce test et collez-le ici dans le test du portefeuille d'importation. Changeons son nom pour ne pas importer de portefeuille avec un nom répété. Faisons quelques adaptations à ce test. Tout d'abord, augmentons le numéro nommé du portefeuille. Modifions-le ensuite pour importer un portefeuille ici au lieu de le créer. Et changeons les paramètres de ces appels de méthode. Passons maintenant à la manette de dialogue Créer un portefeuille et copiez-la si vous la bloquez ici. Et nous allons le coller ici dans la manette de dialogue du portefeuille. Injectons les services nécessaires dans cette classe. Remplaçons cette variable par le nom du portefeuille. Maintenant, commentons ces tests et lançons notre nouveau test. Grade. Le test est réussi. Décommentons ces tests. Ajoutons maintenant une validation d' adresse. Lorsque vous essayez d' envoyer des transactions. Actuellement, nous pouvons saisir n'importe quoi dans le champ adresse à envoyer. Si nous essayons d'envoyer une transaction à une adresse non valide et qu'une erreur se produit et que celle-ci est ignorée silencieusement par l'application sans que l'utilisateur ne s'en aperçoive, implémentera une validation qui fera une boîte de dialogue d'alerte apparaît à l'écran si l'adresse à envoyer n'est pas valide. Passons d'abord au test d'envoi de Bitcoin pour créer un test pour ce scénario. Nommez-le, cela ne devrait pas envoyer de Bitcoin à une adresse invalide. Ajoutons du code pour créer un portefeuille à l'aide de l'interface graphique et du wind block. Attendons la création du portefeuille. Maintenant, copiez-collez ce code ici pour envoyer des fonds dans le portefeuille. Créons cette variable de montant précédente ici et fixons sa valeur à 0,1. Définissons un pour la deuxième méthode de plage appelée paramètre. Créons maintenant une adresse de nœud et générons un bloc pour celle-ci. Cliquons sur l'onglet Envoyer et appelons la méthode send Bitcoin pour essayer d' envoyer 0,01 Bitcoin à l' adresse à envoyer à la variable. Étant donné que la variable adresse à envoyer contiendra des adresses non valides, nous nous attendons à ce qu'une fenêtre de dialogue d'alerte apparaisse contenant un message indiquant que l'adresse à envoyer n'est pas valide. Créons donc une variable de message d'erreur avec le message suivant. Nous allons maintenant utiliser la méthode de recherche pour obtenir un composant contenant ce message et stocké dans la variable de requête node. Enfin, nous allons cliquer sur le bouton OK pour fermer la fenêtre de dialogue. Bloquez ensuite, ajoutons la comparaison suivante pour vérifier si le message dans la fenêtre de dialogue d'alerte est égal à la variable du message d'erreur. Définissons l'adresse à envoyer à aide de quelques cas de test dans le bloc where. Ici, passons ces scénarios de test disponibles sur la page Projet et ressources. Chaque scénario de test comporte une erreur. Les différentes parties du code seront détectées. Le premier cas de test est une chaîne avec un préfixe inexistant. le second cas, le préfixe reg test est correct, mais l'adresse restante n'est pas valide. Les trois adresses suivantes seraient des adresses de test d'enregistrement valides, mais leurs derniers caractères ont été modifiés. Pendant la construction de l'adresse. Une partie de l'adresse utilise le reste de l' adresse à créer. Cette partie constitue la somme de contrôle de l' adresse et sa fonction est de détecter les modifications d' adresse. Lors du décodage de l'adresse, la somme de contrôle est vérifiée et nous nous attendons à ce qu'une erreur se produise cas d'échec de cette vérification. Les trois dernières adresses sont valides, mais elles ne proviennent pas de l'environnement de test reg Elles doivent donc être considérées comme non valides. Passons à l'outil de recherche de configuration des scripts. Dans l'appel à la méthode URLs throw, passons un lambda dont le corps renverra une nouvelle exception de transaction de création avec une constante d'adresse non valide provenant de la classe des messages d'erreur. L'exception de création de transaction est déjà détectée plus loin dans le code et son message est déjà affiché dans une fenêtre de dialogue d' alerte. Créons cette constante dans la classe des messages d'erreur. Il contiendra le même texte que celui que nous avons défini dans le test. Avec cette modification, nous nous attendons à ce que la validation couvre les adresses dont les préfixes ne sont pas valides. Passons maintenant au service des créateurs de transactions. Enveloppons le code de la méthode de sortie de construction dans un bloc try-catch. Dans le catch, le bloc lancera l'exception de création de transaction en transmettant la constante d' adresse non valide. Avec cette modification, nous nous attendons à ce que la validation couvre les erreurs liées au décodage des adresses dont la vérification du checksum échoue. Passons au test d' envoi de Bitcoin. Maintenant, commentons ces tests et lançons notre nouveau test. Les trois derniers tests ont échoué. Notre portefeuille a réussi à envoyer des fonds à ces adresses. Cela s'est produit parce que le décodage des adresses supprime les préfixes d'adresse. Bien entendu, les transactions ont été envoyées uniquement dans l'environnement de test Reg. est donc important de rendre ces adresses invalides pour éviter les situations où vous pensez gérer votre portefeuille dans un environnement, qu'il fonctionne réellement dans un autre. Réglons ce problème. Passons à la classe Address Matcher. Créons ces méthodes de segmentation. Il renverra un prédicat de chaîne. Et il faudra un environnement suffisant comme paramètre. Nous allons maintenant créer un objet cartographique avec des environnements comme clés et des prédicats de chaînes comme valeurs. Nous utiliserons la carte des méthodes pour créer cette carte. Un Lambda sera défini pour chaque environnement afin de vérifier si le paramètre d'adresse possède le préfixe attendu pour cet environnement. Pour les adresses réseau principales de Segue, nous pensons qu'elles ne commencent pas par BCR mais par des BC adresses réseau de test BC. Nous allons commencer par les tests de dépistage de la tuberculose et les tests de dépistage. Nous allons commencer par BCR t. Ensuite, nous allons renvoyer l' appel à la méthode map.get en passant l'environnement en paramètre. Maintenant, dupliquons cette méthode et changeons son nom en segment imbriqué. Dans ce cas, peuvent être des adresses réseau. Nous allons commencer par trois tests, les adresses de test net et reg. Nous allons commencer par deux. Dupliquons cette méthode et changeons son nom en utilisant ses anciennes adresses réseau principales. Nous allons commencer par un. Testez les adresses de test net et reg. Nous allons commencer par M ou N. Maintenant, retirons ces Lambdas de cette classe. Passons maintenant à la classe de configuration des adresses. Ajoutons ce champ d' environnement Bitcoin. Ajoutons une annotation de valeur ici pour injecter la valeur de ce champ à l'aide du paramètre point properties de l'application d'environnement Bitcoin . Changeons maintenant le paramètre de segment ici pour l'appeler en tant que méthode et transmettons le champ d' environnement Bitcoin comme paramètre. Faisons de même avec ces paramètres de segment imbriqués ici. Passons maintenant à la classe de configuration du script. Nous allons apporter la même modification que nous venons de faire dans la classe de configuration d'adresse. Injectons l' environnement Bitcoin dans cette classe et modifions les beans de configuration du script pour appeler les méthodes de correspondance d' adresses appropriées. Maintenant, avant de réexécuter notre nouveau test, corrigeons certains tests. Dans le test du générateur séquentiel d'adresses, nous devons définir l'environnement Bitcoin dans l' instanciation de la configuration des adresses comme ceci. Faisons ce test. Super, ça passe toujours. Maintenant, faisons de même pour le test du service Create Wallet. OK, ça passe toujours. Faisons de même pour le test de sélection de pièces par tirage aléatoire unique . Cette fois, nous devons définir l'environnement Bitcoin dans la configuration du script sur. Laissons-le fonctionner. Super, ça passe toujours. Maintenant, corrigeons le test du service Transaction Creators. OK, ça marche toujours. Enfin, faisons la même correction dans le test du calculateur de taille de transaction. Mais cette fois, nous devons configurer les environnements Bitcoin pour tester le net. Puisque nous utilisons des adresses réseau de test dans ce test, grade, les tests sont réussis. Passons maintenant au test d' envoi de Bitcoin. Commentons ces scénarios de test pour n'exécuter que les trois derniers. Laissons-le fonctionner. Super, les tests sont réussis. Décommentons ces tests. Et corrigeons ce test nommé lettre. Il envoie, pas envoyé. 75. 73 Partage d'habiletés de la barre de progression 2: Dans cette vidéo, nous allons ajouter une section de bas de page à la fenêtre principale de notre application. Le pied de page contiendra une barre de progression et une étiquette de texte. La barre de progression sera active lorsque notre portefeuille communiquera avec notre nœud, ce qui peut parfois prendre un certain temps. L'étiquette textuelle affichera une brève description de l'activité de notre portefeuille au cours de cette communication. Concevons donc cette section dans le FXML à points du terrain de jeu. Passons au Scene Builder. D'abord. Ajoutons une case H au bas de la fenêtre principale. Changeons la largeur préférée de la boîte H à 600 et la hauteur préférée à 19. Ajoutons maintenant une barre de progression à la case H. Ajoutons-y également une étiquette. Nous allons définir la marge gauche de l'étiquette sur dix et son texte sur une chaîne vide. Maintenant, dans l'éditeur de texte, copions ce code ici et collez-le dans le point FXML de la fenêtre principale. Encapsulons maintenant la barre de progression et les composants étiquetés dans des fichiers FXML. Tout d'abord, créons la barre de progression FXML. Supprimons ce contenu. Créons une balise racine éthique avec un type pointant vers la classe Java FX de la barre de progression. Copions maintenant les attributs de la balise et du point FXML de la fenêtre principale et collez-les dans notre nouveau FXML. Définissons cette balise XML NSF X dans la fenêtre principale, FXML. Supprimons cette barre de progression à sa place. Ajoutons la balise de contrôle de la barre de progression, qui sera créée ultérieurement. Créons maintenant un fichier FXML à points de bas de page pour encapsuler la balise label. Supprimons ce code. Copions et collons le code de balise d'étiquette de la fenêtre principale FXML dans le nouveau FXML. Remplaçons la balise label par une balise racine éthique dont le type pointe vers la classe labellisée Java FX. Ajoutons cet attribut XML NSF x à la nouvelle balise. Ajoutons maintenant les importations manquantes à ce fichier. Revenez à la fenêtre principale. Remplaçons la balise d'étiquette copiée par la balise du contrôleur de pied de page. Nous allons maintenant créer le contrôleur de barre de progression et l'importer ici. Faisons de même avec le contrôleur de pied de page. Passons maintenant au contrôleur de barre de progression. Ajoutons-y l' annotation du composant. Utilisons le constructeur du contrôleur de l'onglet Receive comme base pour créer le constructeur du contrôleur de barre de progression. Corrigons son nom et annotation de valeur pour qu'ils pointent vers les bons. Et supprimons le portefeuille actuel car nous n'en aurons pas besoin. Maintenant, copions ce constructeur et collez-le dans le contrôleur de pied de page. Corrigons le nom du constructeur et ajoutons l' annotation du composant à cette classe. Faisons en sorte que l'annotation de valeur pointe vers le FXML approprié. Maintenant, faisons en sorte que cette classe étende la classe d'étiquette. Et la classe de contrôleur de barre de progression étendra la classe de barre de progression. Passons à la classe d'écouteur GUI et ajoutons les deux contrôleurs à l'ensemble afin qu'ils soient configurés en tant que composants personnalisés. Maintenant, créons un observable qui modélisera l'état de progression. Il s'agira de la classe de progression asynchrone créée dans le package observables. Ajoutons-y une annotation de composant. Pour définir l'état de la barre de progression, vous créerez un double champ de propriété appelé progression. Instancions-le ici avec un nouvel objet à double propriété simple utilisant zéro comme paramètre. Plus tard, le paramètre zéro, qui définit l'état de la barre de progression sur inactif, sera transmis à la barre de progression. Nous allons maintenant créer le champ de description de la tâche. Il s'agira d'une propriété de chaîne et nous définirons le texte du libellé du pied de page. Instancions-le à l'aide d'une nouvelle propriété de chaîne simple. Créons des getters pour les deux propriétés. L'IDE a créé deux getters pour chaque champ, l'un pour la propriété et l'autre pour la valeur de la propriété. Il n'aura besoin que des getters pour les propriétés. Supprimons donc les autres getters. Maintenant, créons la méthode de démarrage ici. Nous l'utiliserons pour définir la valeur de progression sur la constante de progression indéterminée. La valeur de cette constante fera en sorte que la barre de progression affiche une barre se déplaçant vers la gauche et la droite, indiquant qu'une tâche est en cours d'exécution en arrière-plan. Définissons également la méthode stop, qui ramènera la valeur de progression à zéro. La barre de progression sera donc inactive, indiquant qu'aucune tâche n'est en cours d'exécution en arrière-plan. Enfin, créons la méthode de description de tâche set. Il prendra une chaîne comme paramètre. Et il définira le paramètre de description dans le champ de description de la tâche. Maintenant, pour contrôler le moment où la barre de progression et le libellé du pied de page changent, nous allons utiliser un aspect. Créons la classe d'aspect de progression dans le package GUI point services. Dans Spring Boot. Et l'aspect est un modificateur de méthode. Nous utiliserons un aspect pour définir que chaque méthode annotée avec une annotation spécifique lancera la barre de progression pour trouver le texte et le libellé du pied de page, exécutera le code de la méthode et rétablir l'état de la barre de progression et de l'étiquette. Pour cela, ajoutons les annotations d'aspect et de composant à cette classe. Injectons la progression asynchrone observable dans cette classe. Créons maintenant la méthode d'activation de la barre de progression. Il renverra un objet. Ajoutons l' annotation around à cette méthode car son paramètre transmettra une chaîne avec le texte au moment de l'annotation, ouvrira les parenthèses, activera la barre de progression, fermera les parenthèses. Cette annotation indique que l'aspect exécutera le code avant et après ses méthodes modifiées. En activant le paramètre de la barre de progression, nous définirons que l' aspect modifiera les méthodes annotées avec une annotation portant ce nom. Ajoutons maintenant deux paramètres à cette méthode. Le premier sera le point commun précédent, qui servira de descripteur pour la méthode annotée. La seconde sera la barre de progression d' activation, qui donnera accès aux paramètres d'annotation. Créons donc cette annotation, nous la créerons dans un nouveau package d'annotations de l' interface graphique. Pour en faire une annotation, nous devons modifier ce mot clé en tant qu'interface. Ajoutons l' annotation cible à ce fichier car son paramètre transmettra la constante de méthode. Cela rendra l'annotation valide uniquement dans les méthodes, et non dans les classes ou les champs. Ajoutons également l'annotation de rétention en passant la constante d'exécution comme paramètre. Cette annotation sera ainsi active lors de l'exécution. Enfin, ajoutons le champ de valeur de chaîne à cette annotation. Ce champ sera rempli par le paramètre transmis à cet appel d'annotation. Revenons à la classe sur l' aspect de la progression. Ici, dans une plate-forme run later, l'appel de méthode transmettra un lambda dont le corps appellera la méthode de description de tâche async progress set, transmettant la valeur de la barre de progression activate comme paramètre sera également appelez la méthode async progress start ici. Nous allons maintenant appeler le point de jointure précédent, la méthode process et l'objet renvoyé par le stockage dans la variable de résultat. La méthode proceed exécutera la méthode annotée et renverra son résultat. Maintenant encapsulée dans une plate-forme, la méthode run later modifiera à nouveau l'état des champs de progression asynchrones. Mais cette fois, nous allons définir la description de la tâche une chaîne vide et appeler la méthode stop lors de la progression asynchrone. Enfin, nous allons renvoyer la variable de résultat contenant l' objet renvoyé par la méthode annotée. Passons maintenant au contrôleur de la barre de progression. Injectons la progression asynchrone observable dans cette classe. Liera le champ de progression asynchrone à la propriété de progression de ce contrôleur dans la méthode initialisée. Passons à la manette de bas de page. Injectons la progression asynchrone observable dans cette classe. Dans la méthode initialisée, le champ de description de la tâche de progression asynchrone sera lié champ de description de la tâche de progression asynchrone à la propriété texte de ce contrôleur. Maintenant, pour que la barre de progression fonctionne, nous devons annoter les méthodes que nous voulons suivre avec l'annotation de la barre de progression active. Faisons-le d'abord dans le service de portefeuille d'importation. Passons la chaîne avec le portefeuille de chargement de textes comme paramètre. Copions cette annotation et collez-la ici dans la méthode sign and send du service de transaction sin. Modifions son paramètre en envoyant une transaction. Ajoutons également cette annotation à la méthode de mise à jour des classes de service UtxOS update en tant que paramètre. Passons la phrase «  Mettre à jour UTXOS ». Maintenant, exécutons notre nœud. Et lançons le test Send Bitcoin Legacy pour vérifier la barre de progression en action. Comme nous l'avons vu, la barre de progression et libellé du pied de page fonctionnent comme prévu. Génial. 76. 74 Mettre à jour les dépendances skillshare 2: Dans cette vidéo, nous allons mettre à jour les dépendances de notre projet. Maintenir à jour les dépendances d'un projet est une bonne pratique. Ce faisant, nous bénéficions des correctifs de bogues et de vulnérabilités de sécurité appliqués à nos dépendances, garantissant ainsi la sécurité de notre application. Passons donc au fichier xml Palm Dot qui augmentera la version de nos dépendances obsolètes. Selon la date à laquelle vous les mettez à jour, versions plus récentes peuvent être disponibles. Augmentons la version parent Spring Boot Starter. Pour moi, la version la plus récente est la 2.7. 0.5 augmentera la version Java à 19. Supprimons cette version géniale maintenant, puisqu'elle n'est plus nécessaire, sa version sera définie automatiquement. Passons aux paramètres de structure du projet. Mettons à jour la version Java du projet. Si vous en avez besoin, la version Java n'est pas disponible. Vous pouvez cliquer sur Ajouter un SDK pour le télécharger. Réglons le niveau de langue du projet au dernier niveau disponible. Maintenant, augmentons la version des contrôles Java FX. Faisons de même avec le JavaFX FXML. Mettons maintenant à jour le plugin Java FX Maven et le plugin G Maven pour plus d'exactitude. Mettons à jour la version Java de Bitcoin à 0.4, 0.4 dans la configuration du plug-in de dépendance Maven. Maintenant, cliquons sur le bouton Charger Maven Changes. Mettons maintenant à jour la version 23 de Bitcoin Core Node. Téléchargez-le depuis le site Web Bitcoin core.org. Téléchargeons la version 23 et installez-la dans le même dossier que la version précédente. Je l'ai déjà fait, donc je vais sauter cette partie. Maintenant. Assurez-vous de définir l'indicateur d'environnement de test reg dans le fichier bitcoin.com. Avant d'exécuter notre nœud, supprimons les dossiers de test reg dans le dossier Bitcoin no data et dans le dossier de base de données de notre application. Nous le ferons simplement pour nettoyer notre environnement de test. Maintenant, exécutons notre nœud en regardant la console. Notez que notre nœud exécute la version 23. Bien. Maintenant, nous devons apporter une petite modification pour notre portefeuille fonctionne correctement avec la nouvelle version de Bitcoin Core Node. Regardons la documentation de la méthode RPC de création de portefeuille pour mieux la comprendre. Dans la version 23 de Bitcoin Core, l'argument descripteurs de la méthode create wallet RPC est défini par défaut sur true, alors que dans la version précédente, il était défini sur false. Cela empêche notre portefeuille d'applications d'appeler certaines méthodes RPC que nous utilisons pour y remédier. Cela définira manuellement sur False afin que la modification ne nous affecte plus. Passons donc au client Node Create Wallet. Ajoutons les paramètres suivants ici. Ajoutons-les à la signature de la méthode create wallet. En outre, le paramètre de clés privées désactivé sera un booléen et définira si le portefeuille de nœuds créé générera des clés privées. Lorsqu'il est défini sur true, le paramètre blank crée un portefeuille de nœuds sans graines ni clés. La phrase secrète définit une phrase secrète facultative pour crypter le NerdWallet. Comme son nom l'indique, le paramètre avoid reuse définit une politique visant à éviter la réutilisation des adresses. Enfin, le paramètre descriptors définit si le portefeuille de nœuds créé est un portefeuille de descripteurs. Un portefeuille descripteur est un nouveau type de portefeuille dans le nœud Bitcoin Core que nous n'utiliserons pas. Passons maintenant au chargement du nœud ou à la création d'un service de portefeuille. Ajoutons ces variables à cet appel de méthode. Copions maintenant ce code et le nœud créons client de portefeuille et collez-le ici. Passons maintenant au service de portefeuille. Ajoutons les valeurs suivantes à cet appel de méthode. Ici, nous allons définir les clés privées désactivées et les paramètres vides sur true. Depuis notre application, cela n'obligera pas le nœud à créer des clés privées et des graines pour nous. La phrase secrète sera une chaîne vide. Nous définirons le paramètre avoid reuse sur false, car notre nœud générera des adresses pour nous et le paramètre des descripteurs sera faux. Passons maintenant à la classe de test de l'interface graphique. Dans cet appel de méthode, passons les valeurs suivantes. Contrairement au cas précédent, cette fois, nous voulons générer des clés privées et des graines car nous utiliserons le portefeuille de nœuds pour envoyer des bitcoins lors de nos tests. Par conséquent, les deux premiers paramètres seront faux. La troisième sera une chaîne vide. Le paramètre éviter la réutilisation sera défini sur true. Ainsi, le nœud évitera de réutiliser les adresses pour notre portefeuille de test et l' argument des descripteurs sera faux. Faisons maintenant une modification supplémentaire pour une raison quelconque. Après avoir mis à jour nos dépendances. Lorsque deux boutons OK apparaissent à l' écran lors de certains tests, test FX finit par cliquer sur le mauvais. Pour résoudre ce problème, passons à l'erreur ou au service d'alerte. Ajoutera un Fx ID au bouton OK de l'alerte par programmation. Pour ce faire, créons la variable ok. ici. Nous allons utiliser la méthode lookup pour obtenir la référence du bouton et l'affecter à la variable ok. comme ceci. Ensuite, nous définirons l' identifiant pour qu'il alerte. OK. Passons maintenant au test de création de portefeuille. Dans ce test, au lieu d'appeler la méthode click on avec le paramètre okay, passons une référence au bouton OK de la boîte de dialogue d'alerte en utilisant son identifiant. Maintenant, ce test cliquera sans équivoque sur le bouton OK droit. Faisons de même avec tous les autres tests présentant le même problème dans le projet. Corrigons celui du test du portefeuille d'importation. Maintenant, faisons-le dans le cadre du test Send Bitcoin Nested Segue. Enfin, corrigeons les tests et envoyons le test Bitcoin. Maintenant, à titre d'exercice, je vais laisser à l'étudiant le soin d' exécuter tous les tests d'application. 77. 75 Mainnet skillshare 2: Dans cette vidéo, nous allons installer et exécuter notre application sur l'environnement réseau principal. Comme nous allons traiter avec de l'argent réel, il est fortement recommandé de garantir la réussite de tous les tests de candidature. En outre, il est conseillé de commencer à jouer avec de petites quantités de Bitcoin. Tout d'abord, mettons à jour la bibliothèque Java Bitcoin vers les versions 0.4, 0.5 dans le fichier POM. Cette version corrige un problème lors de l'importation du fichier de liste de mots lors de l'exécution de l'application après son installation. Passons au service de semences mnémotechniques et supprimons ces déclarations car nous n'en avons plus besoin. Faisons de même avec cette méthode de création de graines mnémotechniques dans le contrôleur de dialogue Create Wallet. Maintenant, exécutons notre nœud sur l'environnement réseau principal. Pour ce faire, allons dans notre fichier bitcoin.com et supprimons la ligne de configuration reg test, sauvegardons le fichier et exécutons le nœud Bitcoin. OK, maintenant notre nœud fonctionne sur l'environnement réseau principal. Voici la partie la plus triste. synchronisation de notre note sur l'environnement réseau principal peut prendre des jours ou des semaines car, pour le moment, sa taille est de 436 Go. Dans mon cas, la console indique que la progression du téléchargement de la blockchain est d'environ 52 %. Plus loin dans cette vidéo, je vous montrerai l'application s'exécute sur mon autre machine, qui est déjà complètement synchronisée. Pour l'instant, modifions notre application pour l'exécuter sur l'environnement réseau principal. Dans le fichier de propriétés des points de l'application, modifions l'environnement Bitcoin en définissant deux réseaux principaux. Nous allons attribuer le port 83 32 à la configuration de l'URI RPC de la note. Il s'agit du port par défaut que le nœud Bitcoin utilise pour exposer son API RPC sur le réseau principal. Ensuite, définissons la clé crypt dans configuration de l'URL de la source de données Spring sur cette variable d'environnement qui nous oblige à définir cette variable d'environnement dans notre système d'exploitation avant de compiler notre code. Ce faisant, nous augmentons la sécurité de notre application, en évitant d'exposer les variables de base de données dans notre code. Faisons de même avec les valeurs des configurations de nom d' utilisateur et de mot de passe Spring Data Source. Nous allons maintenant générer des valeurs sécurisées pour ces configurations. Pour ce faire, utilisons le gestionnaire de base de données SQL pour y parvenir en appelant la fonction crypt key comme suit. Générons trois valeurs copiez-les et collez-les dans un fichier texte. Il est important de conserver ces valeurs en lieu sûr, car toute modification de ces valeurs avant de compiler à nouveau l'application entraînera la perte de l' accès à la base de données. Dans ce cas, vous aurez toujours accès à votre portefeuille. Si vous conservez vos portefeuilles, votre code mnémotechnique et votre mot de passe, vous devrez supprimer les fichiers de base de données et compiler à nouveau l' application. Maintenant, je vais coller ces valeurs de variables d' environnement directement dans l'application que les propriétés des points peuvent corriger. Je le fais parce qu'au moins sur mon ordinateur Windows, l'application n'interpole pas ces valeurs avec l'environnement système. Premièrement, le même problème ne se produit pas sous Linux. Je pense donc que c'est une sorte de bogue étrange lors de la compilation. Dites-moi dans la section des commentaires si vous avez rencontré le même problème. Nous pouvons donc trouver ensemble une solution à ce problème. Pour l'instant, nous pouvons passer à l'application dot properties is, is in the Maven tab. avec le bouton droit de la souris sur le bouton Installer. Cliquez sur Modifier la configuration d'exécution. Dans l'onglet Runner. Activons la case à cocher Ignorer les tests afin que la commande Maven install n'exécute pas les tests de l' application avant l'installation de l'application. Si vous utilisez de nouvelles versions d' IntelliJ AID, cette option est peut-être disponible dans l' icône de configuration de cette fenêtre. Cliquez sur le bouton OK. Maintenant, double-cliquez sur l'option d'installation personnalisée dans la section Exécuter la configuration. Super, l'application a été installée avec succès dans le dossier indiqué dans la console. Avant de l'exécuter, veillez à installer le SDK Java avec la même version que l'application. Je vais aller sur le site Web d'Oracle pour le télécharger et l'installer. Après l'avoir installé, fermez et ouvrez le terminal. Copiez maintenant le chemin où votre application a installé le fichier JAR de l'application. Vous pouvez utiliser la commande java space double tiphen version pour vous assurer que votre terminal exécute la bonne version de Java. Exécutez maintenant la commande java space, tiret jar space, le chemin que vous venez de copier. Super, l'application a démarré avec succès sur l'environnement réseau principal. Essayons de créer un nouveau portefeuille. Il a réussi à créer un nouveau portefeuille, mais comme notre nœud est toujours en panne, la barre de progression du chargement resterait active pendant longtemps avant que nous puissions le tester. Maintenant, je vais montrer le portefeuille qui fonctionne sur l'environnement réseau principal ma machine Linux où le nœud est synchronisé à 100 %. Je viens donc d'installer l'application de la même manière que nous l'avons fait pour Windows. Cela montre un grand avantage de Java , à savoir la compatibilité multiplateforme fluide. Lancer l'application. À partir de maintenant, je vais masquer certaines données que vous verrez à l'écran pour des raisons de confidentialité. D'abord, je charge un portefeuille. Je l'ai déjà créé correctement chargé comme prévu. Maintenant, je vais créer un nouveau portefeuille. Je vais annoter la graine mnémotechnique à l'aide d'un stylo et de papier avant de cliquer sur le bouton OK. Maintenant, je vais copier l'adresse et la coller dans un éditeur de texte. Maintenant, je vais charger le portefeuille précédent, qui contient des fonds. Maintenant, envoyons des Satoshi à l'adresse que nous avons copiée de la table des adresses. Nous pouvons constater qu'un nouveau changement d' adresse a reçu des fonds. Génial. Dans le tableau des transactions, nous voyons qu'une nouvelle transaction sans confirmation a été créée. Ouvrons maintenant le portefeuille qui a reçu les fonds. Nous pouvons voir que la table des adresses et la table des transactions contiennent un nouveau registre indiquant que nous avons reçu avec succès des Satoshi. Super, tout fonctionne correctement. 78. Cours supplémentaires - Bitcoin Core v26: Bienvenue à notre premier cours supplémentaire sur la mise à jour notre application pour communiquer avec la version 26 de Bitcoin Core. Nous verrons qu'il existe de très bonnes raisons rester à jour avec la dernière version de Bitcoin Core. Tout d'abord, visitons ce site Web pour télécharger la version 26 de Bitcoin Core. Cliquez sur la version adaptée à votre système d'exploitation. Comme j'utilise Windows, je vais télécharger le fichier. Essentiellement, nous allons remplacer la version actuelle de Bitcoin Core dont nous disposons Assurez-vous de choisir le même chemin d'installation que celui que nous utilisons actuellement. Dans mon cas, je ne procéderai pas à l'installation puisque je l'ai déjà. Mais pour vous, cela devrait être aussi simple que de cliquer plusieurs fois sur le bouton suivant avant d'exécuter la nouvelle version installée. Explorons les avantages immédiats qu'il offre, commençant par la version 25 de Bitcoin Core. Nous pouvons voir dans ses notes de publication qu'il implémente un nouvel indice qui accélère considérablement les scans du portefeuille Re. Pour opter pour ce nouveau filtre, il suffit d'ajouter le filtre de blocage égal à un paramètre à notre fichier de configuration Bitcoin. Au redémarrage du nœud, il commencera à créer ce nouvel index Cela peut prendre quelques heures, mais par la suite, nous remarquerons que le chargement d'un portefeuille après un certain temps sans exécuter notre nœud devient beaucoup plus rapide Passons maintenant à certaines modifications introduites dans notes de publication de la version 26. Nous constatons que pour utiliser des portefeuilles sans descripteur, nous devons définir un paramètre RPC obsolète dans notre fichier de configuration Bitcoin Par la suite, les portefeuilles sans descripteur seront déconseillés dans les prochaines versions principales. Ne t'inquiète pas. Nous montrerons comment migrer notre application vers des portefeuilles de descripteurs dans le prochain cours supplémentaire Pour l'instant, afin de garantir que nos portefeuilles actuels fonctionneront avec la version 26 de Bitcoin Core, ajoutons ce paramètre à notre fichier de configuration Bitcoin Pendant ce temps, ajoutons également le filtre de blocage égal à un paramètre dont nous avons parlé précédemment. Exécutons maintenant notre nœud principal Bitcoin dans l'environnement de test reg. Comme toujours, nous avons presque terminé toute modification importante apportée à notre application Nous devons exécuter tous nos tests pour assurer que tout fonctionne correctement. Je l'ai déjà fait de mon côté et j'ai découvert qu'un test cessait de fonctionner lorsqu'il était exécuté avec la nouvelle version principale de Bitcoin. Il s'avère que le test «   Ne pas envoyer de Bitcoin avec le mauvais mot de passe » de la classe de test « Send Bitcoin  » a échoué. Cependant, non pas parce que la transaction a été envoyée avec succès, mais parce que l'erreur renvoyée différente de celle attendue Je l'ai débogué et j'ai découvert que la réponse d'erreur envoyée par Bitcoin Core dans la nouvelle version contient désormais un message différent , celui-ci Nous supprimons simplement le non au début et l'ajout a échoué à la fin. Maintenant, le mappage entre cette réponse d'erreur du noyau et notre application doit être précis. C'est ça. Maintenant, si vous faites nos tests, ils devraient tous réussir. Dans le prochain cours supplémentaire, nous verrons ce qu'est un portefeuille descripteur et comment adapter notre application pour créer ce type de nous verrons ce qu'est un portefeuille descripteur et comment adapter notre application pour créer ce type de portefeuille. À bientôt.