Commencer
De la sécurité Burstcoin à la sélection du portefeuille, le guide de démarrage fournit les informations nécessaires pour réussir.
Logiciel
La collection définitive de logiciels libres et faciles à utiliser se trouve dans la bibliothèque de logiciels Burstcoin.
Documentation
Visitez le projet de documentation Burstcoin pour plus d’informations. Contribuez à la nouvelle documentation ou recommandez des améliorations.
Robinets
Activer un nouveau portefeuille pour une extraction ou pour recevoir un transfert de Bittrex. Visiter le liste des robinets Burstcoin community.
FAQs
Prise en charge des nouveaux utilisateurs, cette section contient les questions les plus fréquentes. Aidez-nous en visitant la section documentation.
Fonctionnement du traitement des transactions Burstcoin
Chaque portefeuille Burstcoin agit comme un nœud de traitement des transactions lorsqu’il est connecté au réseau.
Une transaction Burstcoin, telle qu’un paiement de la partie A à la partie B, est initiée en entrant les détails de transaction dans un portefeuille Burstcoin. La transaction prévue est diffusée sur le réseau en tant qu’objet de transaction avec un ID de transaction et les détails de transaction inclus. Les nœuds (portefeuilles Burstcoin en ligne et entièrement synchronisés) évaluent les détails de la transaction pour déterminer si elle est valide.
All values for the transaction detail inputs are bounds checked.
- Tous les détails obligatoires sont-ils spécifiés?
- Les frais de transaction spécifiés sont-ils supérieurs ou égaux aux frais de transaction minimum?
- La date limite des transactions est-elle d’au moins une minute dans l’avenir?
S’il n’y a pas d’exceptions,le traitement des transactions se poursuit comme suit :
- La clé publique du compte d’envoi est calculée à l’aide de la phrase de passe secrète fournie.
- Le solde du compte d’envoi est extrait d’un scan de la blockchain.
Les éléments suivants sont des chèques relatifs au solde du compte d’envoi:
- Le solde du compte d’envoi est-il supérieur à zéro ?
- Le solde confirmé du compte d’envoi est-il supérieur ou égal au montant de la transaction plus les frais de transaction ?
- Le solde confirmé du compte d’envoi est-il suffisant pour couvrir le montant de la transaction plus les frais de transaction pour la transaction en cours ainsi que toute autre transaction à partir du même compte qui n’a pas encore été confirmée?
Si le compte d’envoi a un solde suffisant, le traitement se poursuit comme suit:
- Un objet de transaction est créé qui inclut tous les détails de la transaction. La transaction se voit attribuer un numéro de transaction.
- La transaction est signée à l’aide de la clé privée du compte d’envoi.
- Les données de transaction chiffrées sont placées dans un message qui demande aux pairs du réseau de traiter la transaction.
- La transaction est diffusée à tous les pairs du réseau.
Remarque : Si l’une ou l’autre des vérifications de détails échoue, le réseau répondra par un code d’erreur et un message.
Les transactions valides sont ajoutées au « magasin de transactions non confirmé », une zone de détention au sein du « mempool ». Lorsqu’un nouveau bloc est généré, ces transactions sont priorisées par le générateur de blocs et le plus grand nombre possible sont ajoutés, sous réserve d’une limite sur le nombre de transactions par bloc (255) et le nombre maximum d’octets.
Les transactions progressives sont incluses en premier, sélectionnées en fonction de la hauteur du bloc à laquelle elles ont été acceptées dans la chaîne de blocs. Si deux transactions échelonnées ont été acceptées à la même hauteur de bloc, la transaction avec le numéro d’index inférieur est sélectionnée en premier. Une fois toutes les transactions échelonnées incluses, les transactions régulières non confirmées sont incluses, sélectionnées en fonction des frais spécifiés, puis par horodatage si plusieurs transactions ont les mêmes frais spécifiés. Remarque : L’ordre de sélection n’est pas conservé lorsqu’un bloc est finalisé. Les transactions ne seront effectuées que par horodatage. Le nouveau bloc est ajouté à la chaîne de blocs qui composent le livre partagé distribué immuable de Burstcoin. Toute transaction qui n’a pas été incluse reste dans la zone de détention en attendant l’inclusion dans un bloc futur.
Les transactions sont considérées comme ayant une confirmation lorsqu’elles sont d’abord incluses dans un bloc. Chaque bloc suivant ajoute une autre confirmation à la transaction. Les transactions Burstcoin sont considérées comme fiables après 10 confirmations. Jusqu’à 720 blocs peuvent être « réorganisés » par le réseau en cas de problème, de sorte qu’une transaction avec 721 confirmations est considérée comme irréversible. Les transactions avec 1 440 confirmations sont considérées comme permanentes.
L’ordre d’octet d’une transaction d’envoi est le suivant :
Longueur (bits) | Nom | Définition des données | Total cumulatif (octets) |
---|---|---|---|
8 | type | Type de transaction (paiement, échange d’actifs, marché, etc.) | 1 |
4 | Version TX | 0 sur la genèse, 1 actuellement, pièces jointes et appendices ajoutés | 1.5 |
4 | Sous-type | Sous-type de transaction (exemple : créer l’ordre d’enchères avec le type d’actif) | 2 |
32 | Timestamp | Timetamp actuel où l’époque est le bloc de genèse | 6 |
16 | Date limite | Date limite en quelques minutes pour le traitement de la transaction | 8 |
256 | Clé publique de l’expéditeur | Clé publique 256 bits pour l’envoi d’une transaction | 40 |
64 | Récipiendaire/Genèse | Bénéficiaire de la transaction, genèse des transactions sans destinataire, exemple : actifs | 48 |
64 | Montant NQT | Montant à envoyer au bénéficiaire, à Planck (1 Burstcoin 100 000 000 Planck) | 56 |
64 | Frais NQT | Montant des frais, à Planck | 64 |
256 | Transaction référencée Full Hash | Plein hh pour la transaction à référence, habituellement laissé vide | 96 |
512 | signature | Signature de cette transaction où ce champ est nul, la signature doit être générée par la clé privée de la clé publique déclarée précédemment | 160 |
32 | Drapeaux | position 1: message arbitraire 2: message crypté 3: annonce clé publique 4: message crypté à soi-même | 164 |
32 | Hauteur du bloc EC | Hauteur de bloc de bloc référencé pour le clustering économique | 168 |
64 | ID de bloc EC | ID du bloc mentionné ci-dessus | 76 |