Guide des transactions – Bitcoin – investir sur crypto

Carte de paiement Crypto

Demandez votre Carte de paiement Crypto ici

Recevez 8 € de BTC gratuitement

Inscrivez-vous à CoinBase









Actualité cryptomonnaie


BÊTA: Cette documentation n’a pas été examinée en détail par les experts Bitcoin et contient donc probablement de nombreuses erreurs. S'il vous plaît utiliser le Problème et Modifier liens dans le menu en bas à gauche pour nous aider à améliorer. Pour fermer cet avertissement

    cliquez ici

introduction

Cette section décrira chaque partie et
montrer comment les utiliser ensemble pour créer des transactions complètes.

Pour que les choses restent simples, cette section prétend que les transactions avec la base
pas exister. Les transactions Coinbase ne peuvent être créées que par des mineurs Bitcoin
et ils font exception à la plupart des règles énumérées ci-dessous. Au lieu de
soulignant l’exception de la coinbase à chaque règle, nous vous invitons à lire
sur les transactions coinbase dans la section Chaîne de blocs de ce guide.

Les parties d'une transaction

La figure ci-dessus montre les principales parties d'une transaction Bitcoin. Chaque
La transaction a au moins une entrée et une sortie. Chaque entrée passe le
satoshis payé à une sortie précédente. Chaque sortie attend alors comme non dépensée
Sortie de transaction (UTXO) jusqu'à ce qu'une entrée ultérieure l'utilise. Quand ton
Le portefeuille Bitcoin vous dit que vous avez un solde de 10.000 satoshi, vraiment
signifie que vous avez 10 000 satoshis en attente dans un ou plusieurs UTXO.

Chaque transaction est préfixée par un numéro de version de transaction sur quatre octets qui indique
Bitcoin pairs et mineurs quel ensemble de règles à utiliser pour le valider. Cette
permet aux développeurs de créer de nouvelles règles pour les transactions futures sans
invalider les transactions précédentes.

Dépenser une sortie

Une sortie a un numéro d’index implicite basé sur son emplacement dans le
transaction: l'index de la première sortie est zéro. La sortie a aussi un
montant en satoshis qu’il paye à un script pubkey conditionnel. N'importe qui
qui peut satisfaire les conditions de ce script pubkey peut dépenser jusqu'à la
montant de satoshis payé à elle.

Une entrée utilise un identifiant de transaction (txid) et un numéro d'index de sortie
(souvent appelé “vout” pour vecteur de sortie) pour identifier une sortie particulière à
être dépensé. Il a également un script de signature qui lui permet de fournir des données
paramètres qui satisfont aux conditions du script pubkey. (Le séquence
nombre
et locktime sont liés et seront couverts ensemble dans
une sous-section ultérieure.)

Les figures ci-dessous aident à illustrer comment ces fonctionnalités sont utilisées par
montrant le flux de travail Alice utilise pour envoyer une transaction Bob et qui Bob
utilise plus tard pour dépenser cette transaction. Alice et Bob utiliseront le
forme la plus courante de la transaction standard P2PKH (Pay-To-Public-Key-Hash)
type. P2PKH permet à Alice de passer des satoshis à une adresse Bitcoin typique,
et laisse ensuite Bob dépenser plus ces satoshis en utilisant un simple
paire de clés cryptographiques.

Création d'un hachage de clé publique P2PKH pour recevoir un paiement

Bob doit d'abord générer une paire de clés privée / publique avant qu'Alice puisse créer la
première transaction. Bitcoin utilise l’algorithme ECDSA (Elliptic Curve Digital Signature Algorithm) avec
la courbe secp256k1; Les clés privées secp256k1 sont constituées de 256 bits de valeur aléatoire
Les données. Une copie de ces données est transformée de manière déterministe en une secp256k1 Publique
clé
. Comme la transformation peut être répétée de manière fiable plus tard, le
la clé publique n'a pas besoin d'être stockée.

La clé publique (pubkey) est alors hachée de manière cryptographique. Ce hash de pubkey peut
répété de manière fiable plus tard, il n’a donc pas besoin d’être stocké.
Le hachage raccourcit et masque la clé publique, rendant manuelle
transcription plus facile et offrant une sécurité contre
problèmes imprévus qui pourraient permettre la reconstruction de clés privées
à partir de données de clé publique à un moment ultérieur.

Bob fournit le hachage pubkey à Alice. Les hashes Pubkey sont presque toujours
envoyé codé sous forme d'adresses Bitcoin, qui sont des chaînes codées en base58
contenant un numéro de version d'adresse, le hachage et une détection d'erreur
somme de contrôle pour attraper des fautes de frappe. L'adresse peut être transmise
à travers tout support, y compris les supports à sens unique qui empêchent le dépensier
de communiquer avec le récepteur, et il peut encore être codé
dans un autre format, tel qu’un code QR contenant un bitcoin:
URI
.

Une fois qu'Alice a l'adresse et la déchiffre dans un hachage standard, elle
peut créer la première transaction. Elle crée un P2PKH standard
sortie de transaction contenant des instructions qui permettent à quiconque de dépenser cette
sortie s'ils peuvent prouver qu'ils contrôlent la clé privée correspondant à
La clé publique hachée de Bob. Ces instructions s'appellent le script pubkey
ou scriptPubKey.

Alice diffuse la transaction et l'ajoute à la chaîne de blocs.
Le réseau le catégorise comme une sortie de transaction non dépensée (UTXO), et Bob
le logiciel de portefeuille l’affiche comme un solde dépensable.

Quelque temps plus tard, Bob décide de passer le UTXO, il doit créer un
entrée qui fait référence à la transaction Alice créée par son hachage, appelée
un identifiant de transaction (txid) et la sortie spécifique utilisée par son
numéro d'index (index de sortie). Il doit alors créer un Signature
scénario
-une
collection de paramètres de données qui satisfont aux conditions posées par Alice
dans le script pubkey de la sortie précédente. Les scripts de signature sont également
appelé scriptSigs.

Les scripts Pubkey et les scripts de signature combinent des clés publiques secp256k1
et des signatures avec une logique conditionnelle, créant un
mécanisme d'autorisation.

Déverrouillage d'une sortie P2PKH pour les dépenses

Pour une sortie de style P2PKH, le script de signature de Bob contiendra les deux suivants:
morceaux de données:

  1. Sa clé publique complète (non endommagée), afin que le script pubkey puisse vérifier qu'il
    les hachages ont la même valeur que le hachage pubkey fourni par Alice.

  2. Une signature secp256k1 réalisée à l’aide de la formule cryptographique ECDSA pour combiner
    certaines données de transaction (décrites ci-dessous) avec la clé privée de Bob.
    Cela permet au script pubkey de vérifier que Bob possède la clé privée qui
    créé la clé publique.

La signature secp256k1 de Bob ne prouve pas simplement que Bob contrôle sa clé privée; ça aussi
rend les parties non-script de signature de sa transaction inviolables afin que Bob puisse en toute sécurité
diffusez-les sur le réseau peer-to-peer.

Quelques choses signées lors de la dépense d'une sortie

Comme illustré dans la figure ci-dessus, les données signées par Bob incluent les
txid et index de sortie de la transaction précédente, la précédente
le script Pubkey de sortie, le script Pubkey créé par Bob qui laissera la prochaine
destinataire dépense la sortie de cette transaction et le nombre de satoshis à
passer au destinataire suivant. En substance, toute la transaction est
signé, sauf pour les scripts de signature, qui contiennent les clés publiques complètes et
secp256k1 signatures.

Après avoir mis sa signature et sa clé publique dans le script de signature, Bob
diffuse la transaction aux mineurs Bitcoin à travers le d'égal à égal
réseau
. Chaque pair et mineur valide indépendamment la transaction
avant de le diffuser ou de tenter de l'inclure dans un nouveau bloc de
transactions.

Validation de script P2PKH

La procédure de validation nécessite l'évaluation du script de signature et du script pubkey.
Dans une sortie P2PKH, le script pubkey est:

OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG

Le script de signature de l'expéditeur est évalué et préfixé au début de la
scénario. Dans une transaction P2PKH, le script de signature contient une signature (sig) secp256k1
et clé publique complète (pubkey), créant la concaténation suivante:

     OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG

Le langage de script est un
Forth-like
langage basé sur la pile délibérément conçu pour être apatride et non
Turing complète. L'apatridie garantit qu'une fois la transaction ajoutée
à la chaîne de blocs, il n'y a aucune condition qui le rend en permanence
impensable. Turing-incomplétude (spécifiquement, un manque de boucles ou
gotos) rend le langage de script moins flexible et plus prévisible,
simplifiant grandement le modèle de sécurité.

Pour vérifier si la transaction est valide, les opérations de script de signature et de script pubkey
sont exécutés un élément à la fois, en commençant par le script de signature de Bob
et continuer jusqu’à la fin du script de pubkey d’Alice. La figure ci-dessous montre la
évaluation d'un script de publication standard P2PKH; en dessous de la figure est une description
du processus.

Évaluation de la pile P2PKH

  • La signature (du script de signature de Bob) est ajoutée (poussée) à une pile vide.
    Comme il ne s’agit que de données, rien n’est fait à part l’ajouter à la pile.
    La clé publique (également issue du script de signature) est placée au-dessus de la signature.

  • D'après le script Pubkey d'Alice, le OP_DUP l'opération est exécutée. OP_DUP pousse sur la pile
    une copie des données qui se trouvent actuellement au sommet – dans cette
    case créant une copie de la clé publique fournie par Bob.

  • L'opération exécutée ensuite, OP_HASH160, pousse sur la pile un hachage
    des données qui s'y trouvent actuellement, dans ce cas, la clé publique de Bob.
    Cela crée un hachage de la clé publique de Bob.

  • Le script Pubkey d’Alice pousse ensuite le hash pubkey que Bob lui a donné pour le
    première transaction. À ce stade, il devrait y avoir deux copies du document de Bob
    pubkey hash en haut de la pile.

  • Maintenant, ça devient intéressant: le script de pubkey d’Alice s’exécute OP_EQUALVERIFY.
    OP_EQUALVERIFY est équivalent à l'exécution OP_EQUAL suivi par OP_VERIFY (pas montré).

    OP_EQUAL (non montré) vérifie les deux valeurs en haut de la pile; dans ce
      Dans ce cas, il vérifie si le hachage pubkey généré à partir de la
      clé publique Bob fournie est égale à la clé de hachage pubkey Alice fournie lorsque
      elle a créé la transaction n ° 1. OP_EQUAL pops (supprime du haut de la pile)
      les deux valeurs comparées et les remplace par le résultat de cette comparaison:
      zéro (faux) ou une (vrai).

    OP_VERIFY (non montré) vérifie la valeur en haut de la pile. Si
      la valeur est faux il met immédiatement fin à l'évaluation et
      la validation de la transaction échoue. Sinon, il apparaît le vrai valeur de la pile.

  • Enfin, le script pubkey d’Alice s’exécute OP_CHECKSIG, qui vérifie la
    signature Bob fournie contre la clé publique maintenant authentifiée qu'il
    également fourni. Si la signature correspond à la clé publique et était
    généré en utilisant toutes les données requises pour être signé, OP_CHECKSIG
    pousse la valeur vrai sur le dessus de la pile.

Si faux n'est pas au sommet de la pile après le script pubkey
évaluée, la transaction est valide (à condition qu'il n'y ait pas d'autre
problèmes avec elle).

Scripts P2SH

Les scripts Pubkey sont créés par des utilisateurs peu intéressés qui
ce script fait. Les destinataires se soucient des conditions du script et, si
ils veulent, ils peuvent demander aux utilisateurs d'utiliser un script pubkey particulier.
Malheureusement, les scripts pubkey personnalisés sont moins pratiques que les scripts courts.
Les adresses Bitcoin et il n'y avait pas de moyen standard pour les communiquer
entre les programmes avant la mise en œuvre généralisée du programme BIP désormais déconseillé70 Paiement
Protocole
discuté plus tard.

Pour résoudre ces problèmes, pay-to-script-hash
(P2SH) ont été créées en 2012 pour permettre à
un spender crée un script pubkey contenant un hachage d'une seconde
script, le
racheter le script.

Le flux de travail P2SH de base, illustré ci-dessous, semble presque identique à
le flux de travail P2PKH. Bob crée un script de rachat avec n'importe quel script, il
veut, hache le script de rachat et fournit le rachat de script
hacher
à Alice. Alice crée une sortie de style P2SH contenant
Bob utilise le script hash.

Création d'un script P2HS avec rachat et hachage

Lorsque Bob souhaite utiliser la sortie, il fournit sa signature avec
le script de rachat complet (sérialisé) dans le script de signature. le
le réseau peer-to-peer garantit que les scripts de hachage de script d'utilisation complets sont identiques
valeur que le script hash Alice mettre dans sa sortie; il traite ensuite le
utiliser le script exactement comme si c’était le script pubkey principal, laissant
Bob passe la sortie si le script de rachat ne retourne pas false.

Déverrouillage d'une sortie P2SH pour les dépenses

Le hachage du script de rachat a les mêmes propriétés qu'un pubkey
hacher
—Il peut donc être transformé en format d'adresse Bitcoin standard
avec seulement un petit changement pour le différencier d’une adresse standard.
Cela rend la collecte d’une adresse de type P2SH aussi simple que celle d’un
Adresse de style P2PKH. Le hachage masque également les clés publiques de la
utiliser les scripts, les scripts P2SH sont donc aussi sécurisés que les hachages de clé de publication P2PKH.

Transactions standard

Après la découverte de plusieurs bugs dangereux dans les premières versions de
Bitcoin, un test a été ajouté qui n'accepte que les transactions de la
réseau si leurs scripts pubkey et les scripts de signature correspondaient à un petit ensemble de
modèles considérés comme sûrs, et si le reste de la transaction n’est pas
violer un autre petit ensemble de règles imposant un bon comportement du réseau. Cette
est le IsStandard () test, et les transactions qui réussissent sont appelées
transactions standard.

Les transactions non standard – celles qui échouent au test – peuvent être acceptées
par des noeuds n'utilisant pas les paramètres Bitcoin Core par défaut. Si ils sont
inclus dans les blocs, ils éviteront également le test IsStandard et seront
traité.

En plus de rendre plus difficile l'attaque de Bitcoin par quelqu'un
libre en diffusant des transactions préjudiciables, la transaction standard
test permet également d’empêcher les utilisateurs de créer des transactions
rendrait l'ajout de nouvelles fonctionnalités de transaction à l'avenir plus
difficile. Par exemple, comme décrit ci-dessus, chaque transaction comprend
un numéro de version – si les utilisateurs ont commencé à changer la version de manière arbitraire
nombre, il deviendrait inutile comme outil pour introduire
fonctionnalités incompatibles avec les versions antérieures.

A partir de Bitcoin Core 0.9, les types de script pubkey standard sont les suivants:

Payer au hachage de clé publique (P2PKH)

P2PKH est la forme la plus courante de script pubkey utilisée pour envoyer une transaction à un
ou plusieurs adresses Bitcoin.

Script Pubkey: OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG
Signature script:  

Payer pour le hachage de script (P2SH)

P2SH est utilisé pour envoyer une transaction à un hachage de script. Chacun des standards
Les scripts pubkey peuvent être utilisés en tant que script d'échange P2SH, à l'exclusion de P2SH lui-même.
À partir de Bitcoin Core 0.9.2, les transactions P2SH peuvent contenir n’importe quel script de rachat valide,
rendant la norme P2SH beaucoup plus flexible et permettant une expérimentation avec
nombreux types de transactions nouvelles et complexes. L'utilisation la plus courante de P2SH est la norme
script multisig pubkey, la deuxième utilisation la plus courante étant le protocole Open Assets.

Un autre script de rachat commun utilisé pour P2SH est le stockage de données textuelles sur la chaîne de blocs.
La toute première transaction bitcoin a jamais fait du texte inclus, et P2SH est une méthode pratique
de stocker du texte sur la blockchain car il est possible de stocker jusqu’à 1,5 Ko de données texte. Un
Vous trouverez un exemple de stockage de texte dans la blockchain à l'aide de P2SH dans ce référentiel.

Script Pubkey: OP_HASH160  OP_EQUAL
Signature script:  [sig] [sig...] 

Cette combinaison de scripts convient parfaitement aux anciens nœuds tant que le hachage de script correspond au script de rachat. Cependant, après l'activation du logiciel Soft Fork, les nouveaux nœuds effectuent une vérification supplémentaire du script de rachat. Ils extrairont le script de rachat du script de signature, le décoderont et l'exécuteront avec les éléments de pile restants ( [sig] [sig..]partie). Par conséquent, pour utiliser une transaction P2SH, l’expéditeur doit fournir une signature valide ou une réponse en plus du script d’échange approprié.

Cette dernière étape est similaire à l’étape de vérification dans les scripts P2PKH ou P2Multisig, où la partie initiale du script de signature ( [sig] [sig..]) agit en tant que “script de signature” dans P2PKH / P2Multisig, et le script de rachat agit en tant que “script de clé publique”.

Multisig

Bien que le multisig P2SH soit maintenant généralement utilisé pour les transactions multisig, ce script de base
peut être utilisé pour exiger plusieurs signatures avant de pouvoir dépenser un UTXO.

Dans les scripts multisig pubkey, appelés m-of-n, m est le le minimum nombre de signatures
qui doit correspondre à une clé publique; n est le nombre des clés publiques étant
à condition de. Tous les deux m et n devrait être des opcodes OP_1 par OP_16,
correspondant au numéro désiré.

En raison d'une erreur par un dans l'implémentation Bitcoin d'origine
qui doit être préservé pour la compatibilité, OP_CHECKMULTISIG
consomme une valeur de plus de la pile que celle indiquée par m, alors le
la liste des signatures secp256k1 dans le script de signature doit être précédée d'une valeur supplémentaire
(OP_0) qui sera consommé mais non utilisé.

Le script de signature doit fournir les signatures dans le même ordre que le
les clés publiques correspondantes apparaissent dans le script pubkey ou racheter
scénario
. Voir la description en OP_CHECKMULTISIG
pour plus de détails.

Script Pubkey:   [B pubkey] [C pubkey...]     OP_CHECKMULTISIG
Signature script: OP_0  [B sig] [C sig...]

Bien qu’il ne s’agisse pas d’un type de transaction distinct, il s’agit d’un multisig P2SH à 2 sur 3:

Script Pubkey: OP_HASH160  OP_EQUAL
Utiliser le script:         OP_CHECKMULTISIG
Signature script: OP_0   

Pubkey

Les sorties de Pubkey sont une forme simplifiée du script de pubkey P2PKH,
mais ils ne sont pas aussi
sécurisé en tant que P2PKH, ils ont donc généralement
ne sont plus utilisés dans les nouvelles transactions.

Script Pubkey:  OP_CHECKSIG
Signature script: 

Données nulles

Données nulles
type de transaction relayé et exploité par défaut dans Bitcoin Core 0.9.0 et
plus tard, qui ajoute des données arbitraires à un script pubkey irréprochable
Les nœuds complets ne doivent pas être stockés dans leur base de données UTXO. Il est
préférable d'utiliser des transactions de données nulles sur les transactions qui gonflent
la base de données UTXO car ils ne peuvent pas être automatiquement élagués; cependant,
il est généralement encore plus préférable de stocker des données en dehors des transactions
si possible.

Les règles de consensus autorisent les sorties de données nulles jusqu'au maximum autorisé pubkey
scénario
taille de 10 000 octets à condition qu'ils suivent tous les autres consensus
règles
, comme ne pas avoir de données enfoncées plus de 520 octets.

Bitcoin Core 0.9.x à 0.10.x sera, par défaut, relais et mine données nulles
transactions
avec jusqu'à 40 octets en une seule transmission de données et une seule valeur null
sortie de données qui paie exactement 0 satoshis:

Script Pubkey: OP_RETURN <0 to 40 bytes of data>
(Les scripts de données Null ne peuvent pas être utilisés, il n'y a donc pas de script de signature.)

Bitcoin Core 0.11.x augmente cette valeur par défaut à 80 octets, l’autre
les règles restent les mêmes.

Bitcoin Core 0.12.0 par défaut
pour relayer et extraire des sorties de données nulles avec un maximum de 83 octets avec
nombre de données envoyées, à condition que la limite totale d'octets ne soit pas dépassée.
Il ne doit toujours y avoir qu'une seule sortie de données nulle et elle doit quand même payer
exactement 0 satoshis.

le -datacarriersize L’option de configuration Bitcoin Core vous permet de
définir le nombre maximal d'octets dans les sorties de données nulles que vous allez relayer
ou le mien.

Transactions non standard

Si vous utilisez autre chose qu'un script pubkey standard dans une sortie, les pairs
et les mineurs utilisant les paramètres par défaut de Bitcoin Core ne
accepter, diffuser, ni exploiter votre transaction. Quand vous essayez de diffuser
votre transaction à un pair exécutant les paramètres par défaut, vous
recevoir une erreur.

Si vous créez un script de rachat, hachez-le et utilisez-le
dans une sortie P2SH, le réseau ne voit que le hachage, il accepte donc le
sortie valide, peu importe ce que dit le script de rachat.
Cela permet de payer des scripts non standard et à partir de Bitcoin Core.
0,11, presque tous les scripts de rachat valides peuvent être dépensés. L'exception est
scripts qui utilisent des opcodes NOP non attribués; ces opcodes sont
réservé aux futures fourchettes et ne peut être relayé ou exploité que par des nœuds
qui ne suivent pas la politique standard de mempool.

Remarque: les transactions standard sont conçues pour protéger et aider le
réseau, ne vous empêche pas de faire des erreurs. Il est facile de créer
transactions standard qui rendent les satoshis qui leur sont envoyés imbattables.

À partir de Bitcoin Core 0.9.3, les transactions standard doivent également respecter les critères suivants:
conditions:

Types de hachage de signature

OP_CHECKSIG extrait un argument non pile de chaque signature
évalue, permettant au signataire de décider quelles parties de la transaction
signer. Puisque la signature protège ces parties de la transaction
modification, les signataires peuvent choisir sélectivement de laisser les autres
les gens modifient leurs transactions.

Les différentes options pour quoi signer sont
appelé signature types de hachage. Il y a trois types de base SIGHASH
actuellement disponible:

Les types de base peuvent être modifiés avec le SIGHASH_ANYONECANPAY (n'importe qui peut
pay), créant trois nouveaux types combinés:

Chaque entrée étant signée, une transaction à entrées multiples peut
avoir plusieurs types de hachage de signature signant différentes parties de la transaction. Pour
Par exemple, une transaction à entrée unique signée avec AUCUN pourrait avoir son
la sortie est modifiée par le mineur qui l'ajoute à la chaîne de blocs. De l'autre
Si une transaction à deux entrées a une entrée signée avec AUCUN et
une entrée signée avec TOUT, le TOUT le signataire peut choisir où passer
les satoshis sans consulter le AUCUN signataire, mais personne d'autre ne peut
modifier la transaction.

Heure de verrouillage et numéro de séquence

Une chose que tous les types de hachage de signature signent est le locktime de la transaction.
(Appelé nLockTime dans le code source de Bitcoin Core.)
Le locktime indique la première heure à laquelle une transaction peut être ajoutée à
la chaîne de bloc.

Locktime permet aux signataires de créer des transactions bloquées dans le temps qui
ne deviennent valables qu'à l'avenir, donnant aux signataires une chance de changer
leurs pensées.

Si l’un des signataires change d’avis, ils peuvent créer un nouveau
transaction non-locktime. La nouvelle transaction utilisera, comme l’un des
ses entrées, une des mêmes sorties qui a été utilisée comme entrée pour
la transaction de locktime. Cela rend la transaction locktime
non valide si la nouvelle transaction est ajoutée à la chaîne de blocs avant
le délai expire.

Des précautions doivent être prises près de l'heure d'expiration d'un verrou horaire. le d'égal à égal
réseau
permet au temps de blocage d’être en avance de deux heures
temps réel, afin qu'une transaction locktime puisse être ajoutée à la chaîne de blocs
à deux heures avant l'expiration officielle du verrou. Aussi, les blocs sont
pas créé à intervalles garantis, donc toute tentative d'annuler une valeur
La transaction doit être effectuée quelques heures avant l’expiration du verrouillage.

Les versions précédentes de Bitcoin Core fournissaient une fonctionnalité qui empêchait
les signataires de transaction d’utiliser la méthode décrite ci-dessus pour annuler une
transaction bloquée dans le temps, mais une partie nécessaire de cette fonctionnalité a été
désactivé pour empêcher les attaques par déni de service. Un héritage de ce système sont quatre octets
numéros de séquence dans chaque entrée. Les numéros de séquence étaient destinés à permettre
plusieurs signataires d'accepter de mettre à jour une transaction; quand ils ont fini
lors de la mise à jour de la transaction, ils pourraient accepter de définir les paramètres de chaque entrée.
numéro de séquence au maximum non signé de quatre octets (0xffffffff),
permettant à la transaction d'être ajoutée à un bloc même si son horloge est verrouillée
n'avait pas expiré.

Même aujourd'hui, définir tous les numéros de séquence sur 0xffffffff (valeur par défaut dans
Bitcoin Core) peut toujours désactiver le verrouillage de l'heure, donc si vous voulez utiliser
locktime, au moins une entrée doit avoir un numéro de séquence inférieur au
maximum. Comme les numéros de séquence ne sont utilisés par le réseau
Dans un autre but, la mise à zéro d’un numéro de séquence suffit à
Activer le locktime

Locktime lui-même est un entier non signé de 4 octets qui peut être analysé de deux manières:

  • Si moins de 500 millions, locktime est analysé comme une hauteur de bloc. le
    La transaction peut être ajoutée à n’importe quel bloc ayant cette hauteur ou plus.

  • Si supérieur ou égal à 500 millions, locktime est analysé à l'aide du
    Format de temps Unix (le nombre de secondes écoulées depuis
    1970-01-01T00: 00 UTC – actuellement plus de 1,395 milliard). La transaction
    peut être ajouté à n'importe quel bloc dont la durée est supérieure
    que le locktime.

Frais de transaction et changement

Les transactions paient des frais en fonction de la taille totale en octets de la transaction signée. Les frais par octet sont calculés en fonction de la demande actuelle d'espace dans des blocs minés. Les frais augmentent en fonction de la demande. Les frais de transaction sont versés au
Bitcoin mineur, comme expliqué dans la section Chaîne de blocs, et il est donc
finalement à chaque mineur de choisir les frais de transaction minimums
va accepter.

Il existe également un concept de «transactions à priorité élevée» qui utilise des satoshis qui n'ont pas bougé depuis longtemps.

Dans le passé, ces transactions «prioritaires» étaient souvent dispensées des frais normaux. Avant Bitcoin Core 0.12, 50 Ko de chaque bloc étaient réservés pour ces transactions hautement prioritaires, mais cette valeur est désormais définie sur 0 Ko par défaut. Après le domaine prioritaire, toutes les transactions sont classées par ordre de priorité en fonction de leurs frais par octet, les transactions les mieux payées étant ajoutées en séquence jusqu'à ce que tout l'espace disponible soit rempli.

À partir de Bitcoin Core 0.9, une redevance minimale (actuellement 1 000 satoshis) est requise pour
diffuser une transaction sur le réseau. Toute transaction ne payant que le montant minimum
être prêt à attendre longtemps avant de disposer de suffisamment d’espace disponible
dans un bloc pour l'inclure. Veuillez consulter la section relative à la vérification du paiement.
pour pourquoi cela pourrait être important.

Étant donné que chaque transaction dépense des sorties de transaction non dépensées (UTXO) et
puisqu’un UTXO ne peut être dépensé qu’une seule fois, la valeur totale du
Les UTXO doivent être dépensés ou donnés à un mineur en tant que frais de transaction. Peu
les gens auront des UTXO qui correspondent exactement au montant qu’ils veulent payer,
la plupart des transactions incluent donc une sortie de modification.

Les sorties de changement sont des sorties régulières qui dépensent les satoshis excédentaires
des UTXOs au dépenseur. Ils peuvent réutiliser le même hachage P2PKH
ou un hachage de script P2SH tel qu'il était utilisé dans UTXO, mais pour les raisons
décrit dans la sous-section suivante, il est fortement recommandé que changement
les sorties
être envoyé à une nouvelle adresse P2PKH ou P2SH.

Eviter la réutilisation des clés

Lors d’une transaction, l’envoyeur et le destinataire se dévoilent tous les
clés publiques ou adresses utilisées dans la transaction. Cela permet soit
personne à utiliser la chaîne de bloc publique pour suivre le passé et l'avenir
transactions impliquant les mêmes clés ou adresses publiques de l’autre personne.

Si la même clé publique est souvent réutilisée, comme cela arrive quand les gens utilisent
Adresses Bitcoin (clés publiques hachées) en tant qu’adresses de paiement statiques,
d’autres personnes peuvent facilement suivre les habitudes de réception et de consommation de cette
personne, y compris le nombre de satoshis qu’ils contrôlent dans des adresses connues.

Ce ne doit pas être comme ça. Si chaque clé publique est utilisée exactement
deux fois – une fois pour recevoir un paiement et une fois pour le dépenser – le
l’utilisateur peut obtenir une part importante de la confidentialité financière.

Mieux encore, en utilisant de nouvelles clés publiques ou unique
adresses
en acceptant des paiements ou en créant
les sorties de changement peuvent être combinées avec d'autres techniques discutées plus tard,
comme CoinJoin ou fusion par évitement, il est extrêmement difficile de
utiliser la chaîne de blocs par elle-même pour suivre de manière fiable la façon dont les utilisateurs reçoivent et
passer leurs satoshis.

Eviter la réutilisation des clés peut également fournir une sécurité contre les attaques pouvant
permettre la reconstruction de clés privées à partir de clés publiques (hypothèse) ou
des comparaisons de signature (possible aujourd'hui dans certaines circonstances)
décrit ci-dessous, avec des attaques plus générales supposées).

  1. Les adresses uniques (non réutilisées) P2PKH et P2SH protègent contre la première
    type d'attaque en gardant les clés publiques ECDSA cachées (hachées) jusqu'à la
    les premiers satoshis envoyés à ces adresses sont dépensés, donc les attaques
    sont effectivement inutiles à moins de pouvoir reconstruire des clés privées
    moins que l'heure ou deux qu'il faut pour qu'une transaction soit bien
    protégé par la chaîne de bloc.

  2. Des clés privées uniques (non réutilisées) protègent contre le second type de
    attaque en générant une seule signature par clé privée, afin que les attaquants
    ne jamais obtenir une signature ultérieure à utiliser dans des attaques basées sur des comparaisons.
    Les attaques existantes basées sur la comparaison ne sont pratiques que de nos jours
    une entropie insuffisante est utilisée dans la signature ou lorsque l'entropie est utilisée
    est exposé par certains moyens, comme un
    attaque par canal latéral.

Donc, pour la vie privée et la sécurité, nous vous encourageons à construire votre
applications pour éviter la réutilisation de la clé publique et, dans la mesure du possible, pour décourager
les utilisateurs de réutiliser les adresses. Si votre application doit fournir une
adresse URI fixe à laquelle les paiements doivent être envoyés, veuillez consulter le
bitcoin: Section URI ci-dessous.

Malléabilité de la transaction

Aucun type de hachage de signature de Bitcoin ne protège le script de signature, laissant
la porte ouverte pour une attaque par déni de service limitée appelée transaction
malléabilité
. Le script de signature
contient la signature secp256k1, qui ne peut pas se signer elle-même, permettant aux attaquants de
apporter des modifications non fonctionnelles à une transaction sans la rendre
invalide. Par exemple, un attaquant peut ajouter des données au script de signature.
qui seront supprimés avant le traitement du script pubkey précédent.

Bien que les modifications ne soient pas fonctionnelles, elles ne changent pas
quels intrants la transaction utilise ni quels extrants elle paie – ils le font
changer le hachage calculé de la transaction. Depuis chaque transaction
des liens vers des transactions précédentes utilisant des hachages comme transaction
identifiant
(txid), une transaction modifiée n'aura pas le txid son
créateur attendu.

Ce n'est pas un problème pour la plupart des transactions Bitcoin conçues pour
être ajouté à la chaîne de bloc immédiatement. Mais cela devient un problème
lorsque la sortie d'une transaction est dépensée avant que cette transaction ne soit
ajouté à la chaîne de blocs.

Les développeurs de Bitcoins ont travaillé pour réduire la malléabilité des transactions
parmi les types de transaction standard, l’un des résultats de ces efforts est
BIP 141: témoin séparé,
qui est soutenu par Bitcoin Core et a été activé en août 2017.
Lorsque SegWit n’est pas utilisé, les nouvelles transactions ne doivent pas dépendre
transactions précédentes qui n'ont pas encore été ajoutées à la chaîne de blocs,
surtout si de grandes quantités de satoshis sont en jeu.

La malléabilité des transactions affecte également le suivi des paiements. Bitcoin Core’s
L’interface RPC vous permet de suivre les transactions par leur txid, mais si cela
txid change parce que la transaction a été modifiée, il peut sembler que
la transaction a disparu du réseau.

Les meilleures pratiques actuelles pour le suivi des transactions dictent qu’un
La transaction doit être suivie par les sorties de transaction (UTXO)
dépense en entrée, car ils ne peuvent pas être modifiés sans invalider le
transaction.

Les meilleures pratiques dictent en outre que si une transaction semble
disparaître du réseau et doit être réédité, qu'il soit réédité
d'une manière qui invalide la transaction perdue. Une méthode qui va
toujours travailler est de s'assurer que le paiement réémis dépense tout de même
les sorties que la transaction perdue a utilisées comme entrées.



Traduit depuis https://bitcoin.org/en/transactions-guide

Carte de paiement Crypto

Demandez votre Carte de paiement Crypto ici

Recevez 8 € de BTC gratuitement


Inscrivez-vous à CoinBase