<commit_before>---
layout: post
title: Bitcoin, Segwit Inside, Part 1 - Adresses P2WPKH natives
date: 2018-01-31 00:40:51.000000000 +01:00
type: post
published: true
status: draft
categories:
- Bitcoin
- Technologie
tags: []
meta:
  _edit_last: '1'
author:
  login: admin
  email: <EMAIL>
  display_name: Boussac
  first_name: ''
  last_name: ''
---
Segwit, abréviation de «Segregated Witness» ou “signatures séparées” en français, est un changement fondamental dans la manière dont les transactions Bitcoin sont construites à partir d’entrées (inputs) et de sorties (outputs).

Cet article décrit les nouvelles adresses Bitcoin Segwit et explique comment les développeurs peuvent générer des transactions vers et depuis ces nouvelles adresses.

Il y a 4 nouveaux types d'adresse Bitcoin Segwit, "native" ou contenue dans une adresse P2SH: P2WPKH natif, P2WSH natif, P2SH-P2WPKH, P2SH-P2WSH.

Avant de nous pencher sur ces nouvelles adresses, nous allons d'abord passer en revue les deux changements significatifs introduits par Segwit: inclure les valeurs d'entrée dans le hash de la transaction et séparer les signatures (“witness” en langage cryptographique) des entrées de transaction.



**Entrées et sorties d'une transaction**

Les entrées d’une transaction pointent vers des scripts dans des transactions précédentes où les coins sont bloqués jusqu'à ce que la transaction soit confirmée dans la blockchain.

Les entrées décrivent l'origine des fonds dépensés dans la transaction. Chaque entrée est constituée d'une référence à une sortie de transaction précédente (“unspent transaction output”, utxo en abrégé) ainsi que de toutes les données requises pour déverrouiller les coins.

Dans le cas de coins bloqués sur une adresse P2PKH ("pay-to-public-key-hash") standard, ces données, appelées "scriptSig", consistent en une signature suivie de son type de “sighash” suivi de la clé publique permettant de vérifier la signature et correspondant à l’adresse en question.

![P2PKH Sighash]({{ site.baseurl }}/assets/P2PKH_Sighash.png)

_Message à signer pour un transfert d'une adresse P2PKH vers une adresse P2SH_

Le “sighash” est l’empreinte du message de transaction: la signature consiste à chiffrer ce "sighash" avec la clé privée correspondant à la clé publique dont le hash figure dans le "Signature Script". 

Plusieurs types de “sighash” (ALL, NONE, SINGLE, etc..) permettent de spécifier le périmètre du message couvert par la signature. 

La valeur par défaut (ALL) signifie que la signature couvre toutes les entrées et toutes les sorties de la transaction. Les autres types de sighash sont utilisés dans des cas d’usage particuliers comme le crowdfunding

Les sorties déterminent la destination des fonds dépensés par la transaction. 

Les sorties d'une transaction consistent en un montant (exprimés en satoshis) suivi d'un "scriptPubKey", c'est-à-dire un script Bitcoin définissant les conditions pour que le montant en question soit débloqué par une transaction ultérieure.

Les entrées de transaction sont signées en chiffrant le “sighash" avec une clé privée.

Parce que les signatures ne peuvent pas exister avant de signer, pour le calcul de sighash, le scriptSig est remplacé par le "scriptCode". 
Pour une entrée P2PKH traditionnelle, le scriptCode est simplement le scriptPubKey de l'utxo (sortie de la transaction précédente) qui la finance:

`OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG`

Dans une transaction non-Segwit, le type de sighash est ajouté après la signature pour spécifier son périmètre. Dans une transaction Segwit, le type de sighash est ajouté à la fin de la pré-image du sighash pour éviter toute altération.

Une fois signée, une transaction non-Segwit est identifiée par son txid qui est un double hachage SHA256 de l'intégralité du message de transaction signé.


**Nouvelle empreinte de transaction**

Un nouvel algorithme de calcul de l’empreinte de transaction est défini qui inclut la valeur (en satoshis) de chaque entrée de sorte qu'un dispositif de signature hors ligne (par exemple un ledger) puisse signer en toute sécurité la transaction sans avoir besoin de vérifier la chaîne de blocs. <commit_msg>segwit fixed broken link<commit_after>---
layout: post
title: Bitcoin, Segwit Inside, Part 1 - Adresses P2WPKH natives
date: 2018-01-31 00:40:51.000000000 +01:00
type: post
published: true
status: draft
categories:
- Bitcoin
- Technologie
tags: []
meta:
  _edit_last: '1'
author:
  login: admin
  email: <EMAIL>
  display_name: Boussac
  first_name: ''
  last_name: ''
---
Segwit, abréviation de «Segregated Witness» ou “signatures séparées” en français, est un changement fondamental dans la manière dont les transactions Bitcoin sont construites à partir d’entrées (inputs) et de sorties (outputs).

Cet article décrit les nouvelles adresses Bitcoin Segwit et explique comment les développeurs peuvent générer des transactions vers et depuis ces nouvelles adresses.

Il y a 4 nouveaux types d'adresse Bitcoin Segwit, "native" ou contenue dans une adresse P2SH: P2WPKH natif, P2WSH natif, P2SH-P2WPKH, P2SH-P2WSH.

Avant de nous pencher sur ces nouvelles adresses, nous allons d'abord passer en revue les deux changements significatifs introduits par Segwit: inclure les valeurs d'entrée dans le hash de la transaction et séparer les signatures (“witness” en langage cryptographique) des entrées de transaction.



**Entrées et sorties d'une transaction**

Les entrées d’une transaction pointent vers des scripts dans des transactions précédentes où les coins sont bloqués jusqu'à ce que la transaction soit confirmée dans la blockchain.

Les entrées décrivent l'origine des fonds dépensés dans la transaction. Chaque entrée est constituée d'une référence à une sortie de transaction précédente (“unspent transaction output”, utxo en abrégé) ainsi que de toutes les données requises pour déverrouiller les coins.

Dans le cas de coins bloqués sur une adresse P2PKH ("pay-to-public-key-hash") standard, ces données, appelées "scriptSig", consistent en une signature suivie de son type de “sighash” suivi de la clé publique permettant de vérifier la signature et correspondant à l’adresse en question.

![P2PKH Sighash]({{ site.baseurl }}/assets/P2PKH_SigHash.png)

_Message à signer pour un transfert d'une adresse P2PKH vers une adresse P2SH_

Le “sighash” est l’empreinte du message de transaction: la signature consiste à chiffrer ce "sighash" avec la clé privée correspondant à la clé publique dont le hash figure dans le "Signature Script". 

Plusieurs types de “sighash” (ALL, NONE, SINGLE, etc..) permettent de spécifier le périmètre du message couvert par la signature. 

La valeur par défaut (ALL) signifie que la signature couvre toutes les entrées et toutes les sorties de la transaction. Les autres types de sighash sont utilisés dans des cas d’usage particuliers comme le crowdfunding

Les sorties déterminent la destination des fonds dépensés par la transaction. 

Les sorties d'une transaction consistent en un montant (exprimés en satoshis) suivi d'un "scriptPubKey", c'est-à-dire un script Bitcoin définissant les conditions pour que le montant en question soit débloqué par une transaction ultérieure.

Les entrées de transaction sont signées en chiffrant le “sighash" avec une clé privée.

Parce que les signatures ne peuvent pas exister avant de signer, pour le calcul de sighash, le scriptSig est remplacé par le "scriptCode". 
Pour une entrée P2PKH traditionnelle, le scriptCode est simplement le scriptPubKey de l'utxo (sortie de la transaction précédente) qui la finance:

`OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG`

Dans une transaction non-Segwit, le type de sighash est ajouté après la signature pour spécifier son périmètre. Dans une transaction Segwit, le type de sighash est ajouté à la fin de la pré-image du sighash pour éviter toute altération.

Une fois signée, une transaction non-Segwit est identifiée par son txid qui est un double hachage SHA256 de l'intégralité du message de transaction signé.


**Nouvelle empreinte de transaction**

Un nouvel algorithme de calcul de l’empreinte de transaction est défini qui inclut la valeur (en satoshis) de chaque entrée de sorte qu'un dispositif de signature hors ligne (par exemple un ledger) puisse signer en toute sécurité la transaction sans avoir besoin de vérifier la chaîne de blocs. 
{'fraction_non_alphanumeric': 0.04805738194859534, 'fraction_numerical': 0.011954572624028692, 'mean_word_length': 5.044797687861272, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 2, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4886583', 'n_tokens_mistral': 2604, 'n_tokens_neox': 2545, 'n_words': 1197}