SegWit, abréviation de Segregated Witness, est une modification du format des transactions Bitcoin proposée pour la première fois par le développeur Pieter Wuille. Activée sur le réseau en août 2017, cette mise à jour de type soft fork permet de séparer les données de signature (« witness ») du corps principal des transactions. Le résultat : correction de la malléabilité des transactions, capacité effective de bloc accrue et base technique permettant des solutions d’évolutivité comme le Lightning Network. Comprendre SegWit est essentiel pour qui s’intéresse à la scalabilité Bitcoin, aux frais de transaction et aux évolutions du protocole.
Pourquoi SegWit ? Les problèmes que la mise à jour résout
Avant SegWit, trois problèmes majeurs limitaient l’ergonomie et l’évolutivité de Bitcoin : la malléabilité des transactions, la limite stricte de taille de bloc à 1 Mo, et la difficulté à déployer des couches supérieures (off‑chain). La malléabilité permettait à un tiers de modifier l’identifiant (TXID) d’une transaction sans invalider sa signature, rendant délicates certaines constructions comme les paiements en chaîne. La limite de bloc imposait un goulot d’étranglement sur le nombre de transactions confirmées par unité de temps et contribuait à la hausse des frais lors des périodes de saturation. SegWit attaque ces points en redéfinissant où et comment sont stockées les signatures.
Technique : comment SegWit modifie le format des transactions
SegWit déplace les signatures (witness) hors du champ « transaction » traditionnel et les place dans une structure séparée. Techniquement, la transaction conserve ses entrées et sorties, mais les éléments de preuve cryptographique sont stockés à part et référencés différemment lors du calcul d’un identifiant de transaction. Ce recalcul empêche une modification mineure des signatures d’altérer le TXID : la source de malléabilité est ainsi supprimée. Par ailleurs, SegWit introduit la notion de « poids » (weight) des blocs : le poids maximal est fixé, ce qui permet de compter différemment les données witness et d’augmenter la capacité effective au‑delà de 1 Mo sans casser la compatibilité.
Avantages concrets de SegWit pour les utilisateurs et les développeurs
SegWit apporte plusieurs bénéfices concrets :
- Réduction de la malléabilité des transactions, facilitant la construction de solutions off‑chain sécurisées.
- Augmentation de la capacitéutile des blocs (plus de transactions par bloc) et, souvent, baisse des frais par transaction.
- Compatibilité ascendante : SegWit est un soft fork, donc les nœuds non mis à jour continuent de fonctionner (mais sans exploiter tous les avantages).
- Base technique pour le Lightning Network, qui repose sur des canaux de paiement nécessitant des transactions non malléables. Pour l’utilisateur lambda, cela se traduit généralement par des transactions plus rapides et moins coûteuses lorsqu’on utilise des wallets et services compatibles SegWit (adresses bech32, etc.).
Adresses SegWit : legacy, P2SH‑SegWit et bech32
Après l’activation, plusieurs types d’adresses coexistent :
- Legacy (P2PKH/P2SH ancien format) : solutions antérieures, non optimisées pour SegWit.
- P2SH‑SegWit (adresses commençant par 3) : méthode de compatibilité qui encapsule SegWit dans un script P2SH ; largement adoptée.
- bech32 (adresses commençant par bc1) : format natif SegWit, plus efficace et moins sujet aux erreurs de saisie, qui permet la plus faible taille de transaction. L’adoption de bech32 améliore le rendement et réduit encore davantage les frais, mais certains services plus anciens n’acceptent pas toutes les variantes, d’où la cohabitation des formats.
SegWit2x, forks et débats communautaires
SegWit2x est l’initiative controversée née de l’« Accord de New York » en 2017 : proposer l’activation de SegWit, puis augmenter la taille des blocs à 2 Mo via hard fork. Le projet visait à combiner les avantages de SegWit avec une hausse immédiate de capacité, mais il a été suspendu face à l’absence de consensus technique et social. Cette affaire illustre la difficulté d’opérer des changements majeurs sur Bitcoin : tandis que SegWit a été activé comme soft fork, tout hard fork nécessitant une large coordination peut conduire à des scissions (forks) et à la création de nouvelles chaînes (ex. Bitcoin Cash). Le débat SegWit vs augmentation de taille de bloc a marqué une fracture entre partisans de la réserve de valeur et partisans de l’usage p2p massif.
Impact sur les frais et la scalabilité : réalité et limites
SegWit améliore l’efficacité des blocs et peut réduire les frais moyens en optimisant la structure des transactions. Toutefois, l’effet n’est pas magique : la baisse dépend de l’adoption par les mineurs, wallets et services. Si le réseau est congestionné et que la demande dépasse la capacité, les frais peuvent encore grimper. SegWit facilite l’essor de solutions de seconde couche (Lightning), qui promettent une scalabilité significative pour les micro‑paiements et les échanges instantanés, mais leur déploiement complet demande une adoption large et une maturation des interfaces utilisateur.
Lightning Network : pourquoi SegWit est une brique essentielle
Le Lightning Network repose sur l’ouverture de canaux de paiement entre utilisateurs et sur la possibilité d’échanger des transactions hors‑chaîne tout en gardant la sécurité de la blockchain. Pour fonctionner de manière fiable, Lightning exige que les transactions sur la chaîne soient non malléables — condition résolue par SegWit. Sans SegWit, les canaux risqueraient de devenir vulnérables aux altérations d’identifiants de transaction. Ainsi, SegWit n’est pas seulement une optimisation : c’est la fondation technique qui a permis au Lightning Network d’exister en sécurité.
Adoption : combien de transactions utilisent SegWit et pourquoi migrer
L’adoption de SegWit dépend des wallets, exchanges et opérateurs de services. Migrer vers SegWit signifie que chaque transaction utilise moins d’espace et coûtera moins cher. Les développeurs et fournisseurs bénéficient d’une amélioration des performances et d’une réduction des coûts d’opération. Pour les utilisateurs, la recommandation générale est d’utiliser des services qui supportent bech32 ou P2SH‑SegWit, afin de profiter de frais réduits et contribuer à l’efficacité globale du réseau.
Risques et limites de SegWit
SegWit n’est pas exempt de risques ou de limitations :
- Complexité accrue pour certains développeurs et opérateurs non préparés.
- Adoption incomplète : si une large part des transactions reste en legacy, les gains sont limités.
- SegWit ne résout pas tous les problèmes de scalabilité : il crée une base pour des solutions off‑chain, mais l’échelle globale dépendra de l’écosystème (Lightning, agrégation, batching).
- Risques sociaux politiques : les forks et désaccords communautaires peuvent fragmenter le consensus.
Bonnes pratiques pour utilisateurs et services
Pour tirer parti de SegWit aujourd’hui :
- Choisissez un wallet compatible bech32 pour minimiser les frais.
- Préférez les exchanges et prestataires qui supportent SegWit pour dépôts/retraits.
- Si vous gérez un service ou un Node, activez le support SegWit et encouragez les clients à migrer.
- Pour développeurs : testez la compatibilité des scripts et la gestion des transactions witness. Ces mesures simples améliorent l’expérience utilisateur et diminuent les coûts pour l’ensemble du réseau.
FAQ
Qu’est‑ce que SegWit en une phrase ?
SegWit (Segregated Witness) sépare les signatures des transactions Bitcoin afin de corriger la malléabilité et d’augmenter la capacité utile des blocs.
SegWit augmente‑t‑il réellement la taille des blocs ?
Indirectement : SegWit n’augmente pas la limite de 1 Mo dans son format ancien, mais introduit le calcul du « poids » qui permet d’avoir une capacité effective supérieure (jusqu’à ~4 Mo de données « virtuelles » selon le poids).
Faut‑il utiliser bech32 ou P2SH‑SegWit ?
bech32 est le format natif SegWit, plus efficace et moins sujet aux erreurs. P2SH‑SegWit offre une compatibilité plus large. Préférez bech32 si vos correspondants et services le supportent.
SegWit est‑il une soft fork ou hard fork ?
SegWit a été activé comme soft fork, ce qui le rend rétrocompatible pour les nœuds non mis à jour.
SegWit2x était‑il une bonne idée ?
SegWit2x visait à combiner SegWit avec une augmentation de la taille de bloc via hard fork. L’idée avait des mérites techniques, mais l’absence de consensus social et de coordination a rendu l’exécution risquée et finalement abandonnée.
SegWit règle‑t‑il tous les problèmes de scalabilité ?
Non. SegWit améliore l’efficacité et permet des solutions off‑chain (Lightning), mais la scalabilité globale dépend d’un ensemble d’innovations et d’adoption généralisée.
Conclusion : SegWit, une évolution technique majeure mais pas une fin
SegWit a transformé la manière dont les transactions Bitcoin sont structurées et a levé un verrou technique majeur : la malléabilité. En tant que soft fork, il a montré qu’il est possible d’améliorer le protocole sans casser la compatibilité, tout en ouvrant la voie à des solutions d’échelle comme le Lightning Network. Cependant, sa valeur réelle dépend toujours de l’adoption par les wallets, exchanges et utilisateurs. SegWit n’est pas la panacée mais une brique essentielle dans l’édifice qui permet à Bitcoin d’évoluer vers des paiements plus rapides, moins coûteux et plus pratiques.
