Puisqu’on aime tous parler de quantique… Cet article fait suite à la proposition d’une modification de Bitcoin pour le rendre quantique résistant et il fait suite à l’article : Bitcoin face à l’ordinateur quantique : évaluation raisonnée d’un risque souvent exagéré. Je vous invite fortement à le lire avant.
En résumé : je crois qu’il serait plus dangereux de faire quelque chose sur le quantique que l’inverse. Et ce BIP apporte des différences politiques notables, compréhensibles mais à débattre.
La vraie menace n’est pas (encore) quantique, mais dans la normalisation silencieuse. Parfois, ne rien implémenter trop tôt est un acte de résistance (à la finance et aux institutions).
Un BIP né dans un climat de pression post-quantique croissante
Le BIP-360, intitulé “Add support for post-quantum signatures”, a été soumis en 2024 et vise à introduire un format extensible permettant l’ajout progressif de signatures cryptographiques résistantes aux ordinateurs quantiques dans le protocole Bitcoin. Ce BIP ne propose pas encore un schéma cryptographique post-quantique spécifique (comme Dilithium ou Falcon), mais constitue un cadre de compatibilité et de transition technique.
Sa genèse s’inscrit dans un contexte de pression politique, économique et institutionnelle croissante autour de la cryptographie post-quantique (PQC). Depuis 2022, le NIST a accéléré la standardisation de ces nouveaux algorithmes (FIPS 203, 204, 205), avec une implication massive de géants technologiques (Google, IBM, AWS) et de groupes financiers (BlackRock, Mastercard, PayPal), souvent engagés dans le financement ou la validation des projets.
Le dépôt du BIP-360 ne peut donc être interprété isolément. Il s’inscrit dans une trajectoire systémique où plusieurs signaux faibles convergent :
- des avertissements publics (souvent alarmistes) de grands acteurs institutionnels évoquant une menace « imminente » sur ECDSA (ex : iShares Bitcoin Trust, mai 2025) ;
- une volonté des États-Unis et de l’Union européenne de normaliser la PQC dans toutes les infrastructures critiques, y compris les monnaies numériques et les blockchains publiques ;
- une convergence entre les préoccupations de conformité réglementaire et les opportunités de déploiement industriel massif d’infrastructures cryptographiques standardisées ;
- une dynamique d’alignement progressif des protocoles libres avec les standards étatiques, parfois en contournant le processus de débat démocratique (ex : adoption silencieuse de courbes NIST dans de nombreux wallets grand public).
Un changement de nature du débat cryptographique
Historiquement, les évolutions cryptographiques du protocole Bitcoin ont toujours été guidées par une double exigence :
- Robustesse empirique éprouvée dans le temps (SHA-256, ECDSA, puis Schnorr) ;
- Prudence extrême dans l’introduction de nouveaux formats, chaque ajout potentiel devant être motivé par un gain fonctionnel, une réduction de la complexité ou une mitigation d’un risque immédiat.
Le BIP-360 rompt avec cette tradition sur plusieurs points :
- il propose une structure sans urgence technique démontrée, alors même que la cryptographie post-quantique est encore sujette à débats sur sa fiabilité, ses performances et ses vulnérabilités pratiques (cf. articles précédents sur les attaques side-channel, le bruit quantique et les failles des implémentations) ;
- il anticipe une menace hypothétique à échéance inconnue, ce qui ouvre la porte à une politique de précaution normative (préparer le terrain réglementaire), plus qu’à une réponse à une attaque concrète ;
- il crée une architecture potentiellement ouverte à des primitives normalisées sans validation communautaire approfondie, en risquant d’intégrer passivement des schémas validés par des institutions non neutres.
Ce déplacement du débat, du risque technique avéré vers l’anticipation réglementaire structurée, modifie la nature même du processus d’évolution du protocole.
Un précédent : Taproot comme cadre de transition
Le BIP-360 tire parti des possibilités offertes par Taproot (BIP-341/342), qui a introduit des scripts plus flexibles et une structure de clé publique unifiée (Pay-to-Taproot). Cette architecture permet désormais d’intégrer de nouveaux schémas de signature, sans modifier le format d’adresse.
Ainsi, le BIP-360 se présente non comme une transformation du consensus, mais comme un ajout optionnel, utilisable uniquement par ceux qui le souhaitent. Cela le rend moins disruptif que des changements plus profonds, comme le passage à de nouvelles courbes ou l’introduction de contrats intelligents complexes.
Mais cette subtilité est ambivalente : elle permet d’introduire silencieusement des évolutions profondes, sous couvert de neutralité technique. L’argument d’« opt-in » a déjà servi dans l’histoire de Bitcoin pour désamorcer certaines oppositions, avant que les changements ne deviennent progressivement la norme (ex : SegWit).
Analyse technique et critique raisonnée du BIP-360
P2QRH : vers une résistance quantique dans Bitcoin
Introduction : contexte du BIP-360
Le BIP-360 propose un nouveau type de script de paiement dans Bitcoin : P2QRH, ou Pay to Quantum-Resistant Hash. Son objectif est de préparer le protocole Bitcoin à une éventuelle menace posée par des ordinateurs quantiques capables de compromettre les schémas cryptographiques classiques utilisés aujourd’hui, notamment ECDSA (Elliptic Curve Digital Signature Algorithm) et les dérivés de Schnorr.
Ce BIP introduit un format de sortie basé sur un hash de clé post-quantique, qui ne révèle jamais la clé publique directement, afin de protéger les utilisateurs d’éventuelles attaques à long terme. Il fait partie d’un ensemble de travaux plus larges sur l’adaptation du protocole Bitcoin aux futurs standards post-quantiques, notamment en lien avec les algorithmes Dilithium (ML-DSA) et SPHINCS+ (SLH-DSA), tous deux sélectionnés par le processus NIST.
L’intention affichée est de permettre aux utilisateurs d’anticiper l’avenir, sans changer le fonctionnement par défaut de Bitcoin, en introduisant un nouveau format de sortie optionnel.
Objectifs et portée technique du BIP
Format des adresses et scripts proposés
Le BIP-360 introduit des adresses de type bc1r…, qui correspondent à des sorties Taproot modifiées, utilisant SegWit version 3. Contrairement aux adresses bc1p… (Taproot, SegWit v1), ces sorties :
- Ne comportent pas de clé publique dans le witness program ;
- N’utilisent pas de voie « keypath » pour la dépense ;
- Se fondent uniquement sur des scripts de type tapscript ;
- Intègrent des algorithmes de signature post-quantique (non obligatoires mais recommandés) ;
- Bénéficient des règles Taproot (taille, vérification, hash Merkle), mais sans utiliser la clé publique dans l’arbre Merkle.
Justification cryptographique
L’objectif est de réduire l’exposition des clés publiques en supprimant complètement leur présence du protocole visible, car une attaque quantique ne devient réaliste qu’à partir du moment où la clé publique est exposée, par exemple :
- Lorsqu’un utilisateur dépense une sortie par signature (ECDSA ou Schnorr) ;
- Lorsqu’une adresse contient la clé publique directement (ex. : P2PK).
Le format P2QRH repose donc sur un tapscript Merkle pur, sans raccourci keypath. Cela empêche toute récupération anticipée de la clé par observation, même en cas de stockage à froid.
Comparaison avec Taproot (BIP-341)
Version SegWit
- Taproot (P2TR)v1
- P2QRH (BIP-360) v3
Keypath (voie par clé)
- Taproot (P2TR) Oui (optionnelle)
- P2QRH (BIP-360) Non (forcée à off)
Witness program
- Taproot (P2TR) Clé publique
- P2QRH (BIP-360) Hash du tapleaf
Tapscript obligatoire
- Taproot (P2TR) Non
- P2QRH (BIP-360) Oui
Merkle path
- Taproot (P2TR) Optionnel
- P2QRH (BIP-360) Obligatoire
Portée réelle sur l’écosystème Bitcoin
Impact sur les portefeuilles
La proposition repose sur un nouveau format (v=3) qui ne sera pas reconnu par les versions antérieures de Bitcoin Core ou des portefeuilles tiers non mis à jour. De fait :
- Les portefeuilles précédents à Taproot (Bitcoin Core ≤ v0.21.1, avant novembre 2021) ne reconnaissent ni Taproot, ni P2QRH ;
- Les portefeuilles Taproot-compatibles actuels, s’ils ne sont pas mis à jour pour reconnaître SegWit v3, ignoreront ou rejèteront les sorties de type bc1r… ;
Il est probable que les portefeuilles visés (cold storage, SPV, hardware wallets) soient précisément ceux que P2QRH veut protéger, ce qui crée un paradoxe de compatibilité.
Transition cryptographique
Le BIP-360 n’impose aucun algorithme post-quantique. Il crée un cadre dans lequel les scripts (tapscript) peuvent inclure n’importe quelle logique de vérification, y compris des signatures Dilithium, SPHINCS+, ou d’autres constructions hybrides.
Il ne s’agit donc pas d’un changement obligatoire mais d’une ouverture à la migration sécurisée, en amont d’un éventuel futur BIP définissant des algorithmes PQ par défaut dans les scripts.
Résistance quantique : clarification des risques
Attaques à exposition longue vs exposition courte
La cryptographie post-quantique distingue généralement deux types d’attaques potentielles sur Bitcoin :
- Attaque à exposition longue : Exploite le fait qu’une clé publique est visible longtemps (ex : sur une adresse non encore dépensée). Elle pourrait être factorisée par un ordinateur quantique une fois celui-ci disponible, compromettant la sécurité future des fonds. → Le BIP-360 cherche à supprimer complètement l’exposition initiale des clés publiques dans les scripts, même de manière indirecte.
- Attaque à exposition courte : Vise une clé publique visible pendant une transaction en attente dans le mempool, par exemple entre le moment de l’émission et celui de l’inclusion dans un bloc. → Le BIP-360 ne protège pas contre cette classe d’attaques. Seuls des mécanismes d’agrégation, de confidentialité ou de minage rapide pourraient limiter ce risque.
Comportement visé par le BIP-360
Pour qu’une sortie P2QRH soit considérée comme « quantum resistant » dans le cadre du BIP-360, il est explicitement recommandé que :
- L’utilisateur évite la réutilisation d’adresses ;
- Les scripts soient strictement sans clé publique visible ;
- Aucune donnée de type « pubkey » ne soit intégrée, même indirectement, dans le contrôle de dépense ;
- Seules des fonctions de hachage non-inversibles soient utilisées.
Ces conditions doivent être respectées par le portefeuille de l’utilisateur. Le protocole lui-même ne peut pas garantir que la sortie sera sécurisée si le script inséré est mal construit.
Contraintes techniques et impacts sur l’implémentation
Format witness : plus lourd
Le témoin (witness) d’une sortie P2QRH est plus lourd que celui de P2TR, car il ne peut utiliser de raccourci de type key-spend. Il implique toujours :
- Une preuve Merkle complète (hashes intermédiaires) ;
- Une signature PQ (potentiellement volumineuse selon l’algorithme) ;
- Des scripts plus longs, en tapscript uniquement.
Conséquences :
- Taille : signatures Dilithium peuvent faire entre 2–3 kB, contre 64–128 octets pour Schnorr.
- Temps de vérification : plusieurs millisecondes, voire plus sur certains matériels embarqués.
- Compatibilité : les wallets légers (SPV, hardware wallets, PSBT) nécessiteront des mises à jour importantes.
Discount SegWit
Les outputs P2QRH étant de type SegWit (v3), ils continuent de bénéficier du witness discount introduit avec BIP-141 : la taille du témoin est pondérée pour éviter une trop forte pression sur la bande passante. Mais :
- Si les scripts deviennent très volumineux (plusieurs kB), le gain relatif diminue ;
- Cela pourrait, à terme, modifier la structure incitative des mineurs ou des utilisateurs ;
- Des arbitrages devront être faits entre la taille des signatures, la fréquence d’usage et les coûts de transaction.
Une logique de construction script-only
Le BIP-360 interdit implicitement la voie de dépense par clé (keypath spending) en Taproot. Il généralise donc une logique « tout par script« , y compris pour des usages simples.
Conséquences techniques :
- Fin des constructions compactes type key-spend Schnorr, très économes en taille et temps ;
- Multisigs simples (2-of-3, 3-of-5…) devront obligatoirement passer par des scripts explicites ;
- La suppression de la voie par clé peut être vue comme une régression pour certains usages.
En pratique, P2QRH recentralise l’ingénierie des scripts : chaque dépense devra s’effectuer par un chemin Merkle valide, avec inclusion des scripts nécessaires dans la dépense. Cette structure renforce la robustesse, mais augmente la complexité.
Compatibilité ascendante et portefeuilles concernés
Portefeuilles non compatibles (pré-Taproot)
Les versions de Bitcoin Core antérieures à v0.21.1 (novembre 2021) et les portefeuilles dérivés n’intègrent pas :
- Le support de Taproot (BIP-341) ;
- Le décodage d’adresses bc1p… (P2TR) ;
- La reconnaissance des scripts tapscript.
Conséquence : ces portefeuilles ne reconnaîtront pas davantage les sorties P2QRH (bc1r…). En l’absence de support explicite, ces sorties peuvent apparaître comme :
- Non reconnues ;
- Ou dans certains cas comme « anyone-can-spend » (selon le code de traitement) ;
- Mais elles ne seront pas relayées ni incluses dans les blocs par ces nœuds, conformément au BIP-141 (validation limitée aux versions reconnues).
Ce risque ne peut être ignoré si des fonds de long terme sont stockés via des portefeuilles obsolètes, ce qui est le cas des adresses les plus exposées.
Portefeuilles post-Taproot mais pré-BIP-360
Les portefeuilles modernes, intégrant Taproot, reconnaissent :
- Les adresses bc1p… (P2TR) ;
- Les scripts tapscript ;
- Les versions SegWit 0 (P2WPKH/P2WSH) et 1 (P2TR).
Mais si le BIP-360 était activé, il introduirait SegWit version 3, inconnue de tous les clients actuels. Ainsi :
- Les portefeuilles ne reconnaîtront pas les adresses bc1r… ;
- Ils n’interpréteront pas correctement les scripts tapscript associés ;
- Les transactions vers ces sorties seront rejetées ou ignorées, sauf mise à jour.
Ce constat est important, car ces portefeuilles intermédiaires sont largement utilisés pour des stockages longue durée, des coffres-forts matériels (hardware wallets), des portefeuilles mobiles SPV, ou des infrastructures semi-connectées.
Sans mise à jour explicite de ces logiciels, une partie de l’écosystème serait exclue du nouveau format, y compris des acteurs pourtant soucieux de sécurité.
Déploiement, activation et gouvernance
Mécanisme d’activation envisagé
Le BIP-360 étant un soft fork, son activation dans le réseau Bitcoin nécessiterait une procédure analogue aux BIP-341/BIP-342, c’est-à-dire :
- Une proposition formelle validée dans le dépôt bitcoin/bips ;
- Une implémentation de référence dans Bitcoin Core (ou un dérivé reconnu) ;
- Un consensus large, matérialisé par un mécanisme de signalement minier (ex : Speedy Trial, ou Version bits) ;
- Une fenêtre d’activation selon les règles de validation de blocs (BIP-8 ou BIP-9).
À ce jour, aucun calendrier d’activation n’a été proposé, et le BIP reste en phase de discussion technique et expérimentale.
Prérequis d’écosystème
L’activation pratique suppose :
- La mise à jour des bibliothèques de validation (libwally, trezor-crypto, btcd, rust-bitcoin…) ;
- L’ajustement des wallets matériels pour la gestion des scripts volumineux, la saisie des messages à signer, la vérification des hashs dans des arbres Merkle ;
- La mise à jour des noeuds complets et légers (Bitcoin Core, Electrum, etc.) ;
- Des outils de test pour les algorithmes PQ : génération, signature, validation.
Le passage à des signatures PQ massivement plus lourdes implique également des questions de stockage (backup, mnémotechniques, PSBT), de bande passante (envoi sur Tor ou réseau lent) et de temps de validation (sur appareils à ressources limitées).
Conséquences sur l’architecture Taproot
Le BIP-360, tout en s’intégrant dans le paradigme Taproot, en modifie significativement l’intention initiale.
Cela revient à désactiver un des apports majeurs de Taproot : l’efficacité et la compacité du key-spend.
La voie proposée est donc volontairement plus conservatrice : elle privilégie la non-exposition des clés à la compacité du code de validation. Ce choix peut se justifier dans un contexte post-quantique, mais implique de renoncer à certains bénéfices du modèle Taproot original.
Normes cryptographiques et centralisation des standards
Sélection des algorithmes : Dilithium et SPHINCS+
Le BIP-360 propose d’intégrer deux algorithmes de signature post-quantique :
- ML-DSA (Dilithium) : basé sur des structures à réseaux (lattice-based), sélectionné par le NIST pour son efficacité, mais avec des clés publiques de taille moyenne (1,3 à 1,6 kB) et des signatures de 2 à 3 kB ;
- SLH-DSA (SPHINCS+) : schéma de signature hash-based, plus lent mais considéré comme plus robuste à long terme. Signatures de l’ordre de 8 à 17 kB selon les paramètres.
Ces deux schémas font partie de la suite standardisée NIST PQC (Post-Quantum Cryptography), et sont désormais intégrés dans le corpus CNSA 2.0 (Commercial National Security Algorithm Suite), notamment recommandé par la NSA pour les infrastructures critiques à partir de 2025–2030.
Référencement exclusif au NIST
Le BIP-360 ne propose pas d’algorithmes alternatifs hors NIST. Il ne cite ni CRYSTALS-Kyber (clé d’échange), ni Falcon (également standardisé), ni les travaux en cours d’autres institutions (ex : ISARA, PQClean, OpenQuantumSafe).
Cette dépendance pourrait poser plusieurs questions :
- Interopérabilité privilégiée avec les portefeuilles réglementés (banques, entités sous régulation FIPS) ;
- Adoption asymétrique : certains pays ou structures méfiantes envers les standards américains pourraient se détourner de ces choix ;
- Difficulté d’évolution : une fois intégrés, ces formats deviendraient difficiles à changer sans casser la compatibilité.
À ce jour, aucun algorithme sélectionné par d’autres autorités (EU Cybersecurity Agency, ANSSI, etc.) n’est évoqué comme alternative ou future extension.
Souveraineté cryptographique et architecture technique
Réduction de la souveraineté individuelle
Le modèle Taproot permet à l’utilisateur de choisir entre plusieurs voies de dépense ;: clé directe (keypath), script complexe, multisig, etc. Le BIP-360 :
- Implique une voie unique : par script ;
- N’autorise pas d’utilisation directe de clé ;
- Ne prévoit pas d’obfuscation ou d’agrégation des scripts, rendant leur contenu public.
Cela peut être perçu comme une réduction du spectre décisionnel des utilisateurs avancés. En particulier :
- Il n’est plus possible de construire une structure P2TR avec fallback keypath invisible ;
- L’ajout d’un script signifie une révélation totale de sa structure lors de la dépense ;
- Le modèle SPV (vérification légère) devient plus lourd à implémenter.
Impacts sur l’écosystème « legacy »
L’introduction d’un nouveau type de sortie (bc1r…, SegWit v3) rend incompatibles :
- Les PSBT (Partially Signed Bitcoin Transactions) générés avant 2022–2023 ;
- Les cold storage non mis à jour (ledger v1, Trezor Model T sans firmwares récents) ;
- Les outils de backup mnémotechniques utilisant des formats compressés.
Cette incompatibilité n’est pas un problème en soi, mais elle implique une migration lente, coûteuse, et souvent peu visible, notamment pour les utilisateurs de longue date.
Elle contraste également avec le modèle « opt-in backward-compatible » qui avait prévalu avec SegWit v0 puis Taproot.
Conclusion : un BIP-charnière entre protection cryptographique et normalisation institutionnelle
Le BIP-360 constitue une étape structurante dans l’évolution du protocole Bitcoin. Sous son apparence technique — celle d’un ajout optionnel de compatibilité avec des signatures post-quantiques — il opère en réalité une redéfinition profonde des équilibres cryptographiques, des interfaces entre protocoles et normes, et des responsabilités des développeurs et utilisateurs.
Une innovation technique légitime mais partiellement prématurée
Sur le fond, l’anticipation d’un risque quantique est compréhensible : le protocole Bitcoin, pour rester résilient à l’échelle des décennies, doit intégrer la possibilité que certaines primitives actuelles (ECDSA, SHA256) soient un jour rendues vulnérables.
Le format P2QRH apporte à ce titre des protections structurelles fortes :
- suppression de l’exposition des clés publiques en amont,
- renforcement des scripts par construction Merkle,
- résistance accrue aux attaques dites à exposition longue.
Mais l’absence actuelle d’attaques effectives sur ECDSA, la difficulté à évaluer la maturité des calculateurs quantiques généralistes, et les coûts significatifs du format (bande passante, performances, compatibilité) rendent la proposition prématurée à l’échelle du réseau.
Une rupture de compatibilité sans précédent
Le fait que P2QRH ne soit reconnu ni par les portefeuilles legacy, ni par les versions Taproot non mises à jour, entraîne une discontinuité fonctionnelle historique. Ce format impose une refonte quasi totale de l’infrastructure logicielle, matérielle et transactionnelle — y compris pour les cold storage, les PSBT pré-Taproot, et les outils de signature indépendants.
Loin d’être anodin, ce basculement soulève des questions sur l’inclusivité réelle de l’évolution : qui pourra suivre ? qui sera laissé derrière ? Et quels seront les coûts de cette transition forcée pour les utilisateurs souverains ou non techniques ?
Une insertion discrète mais structurante des normes NIST
Le fait que les algorithmes mis en avant soient issus exclusivement du processus de sélection du NIST, organisme gouvernemental américain historiquement associé à des mécanismes de standardisation controversés, n’est pas neutre.
Le choix de ML-DSA (Dilithium) et SLH-DSA (SPHINCS+) s’explique techniquement, mais il ouvre la porte à une normalisation par le haut : celle d’un alignement implicite sur les standards CNSA 2.0, qui visent à rendre interopérables toutes les infrastructures de sécurité nationale et commerciale américaines.
Sans encadrement communautaire strict, cette normalisation cryptographique pourrait conduire à une centralisation juridique, économique et logicielle contraire à l’esprit original de Bitcoin.
Une neutralisation implicite des apports de Taproot
En désactivant définitivement la voie par clé (key-spend), en forçant l’usage de scripts explicites, le BIP-360 affaiblit les logiques d’optimisation et de confidentialité introduites par Taproot : dépenses compactes, multisig simples, signatures agrégées.
Cette transformation, présentée comme un progrès en sécurité, peut aussi être lue comme un abandon discret d’un paradigme cypherpunk au profit d’une architecture plus observable, plus réglementable, plus conforme.
Nécessité d’un débat communautaire structuré
Aucun des éléments techniques du BIP-360 ne constitue une faute en soi. L’ensemble est rigoureux, extensible, et bien formulé.
Mais la portée politique, cryptographique et économique de ses choix justifie un débat communautaire de fond — qui ne doit pas être biaisé par :
- des annonces alarmistes sur le risque quantique,
- des incitations institutionnelles à la conformité,
- des effets de réseau liés aux implémentations précoces dans Core.
Ce débat ne doit pas opposer les « progrès » aux « conservatismes », mais interroger les finalités :
- Protéger Bitcoin contre le quantique, oui. Mais à quel coût pour la décentralisation, l’auditabilité et la continuité du protocole ?
- Intégrer la cryptographie PQC, oui. Mais avec quelles garanties sur l’indépendance des primitives, leur gouvernance, et leur usage optionnel ?
- Préparer l’avenir de Bitcoin, oui. Mais sans effacer, par précaution mal orientée, les libertés cryptographiques qui en font la force.
Annexe Les auteurs du BIP : Profil des auteurs du BIP-360 (Pay-to-Quantum-Resistant-Hash, P2QRH)
Hunter Beast (alias « cryptoquick »)
Identité et pseudonyme : Hunter Beast, également connu sous le pseudonyme cryptoquick, est l’auteur principal du BIP‑360. Il signe ses publications sous ce nom et l’utilise dans ses projets open source et sur les réseaux sociaux techniques. Aucun autre nom civil n’est publiquement associé à son profil.
Contributions aux BIPs : Il est à l’origine du BIP‑360 intitulé Pay to Quantum Resistant Hash, proposé en 2024 et enregistré officiellement comme Draft à la fin de la même année. Ce BIP introduit une nouvelle structure d’adresse Bitcoin censée résister à des attaques futures d’origine quantique. En parallèle, il a rédigé un brouillon alternatif, P2TRH, pour renforcer temporairement les sorties Taproot.
Par ailleurs, il intervient dans les discussions communautaires relatives à la migration post-quantique des anciennes adresses Bitcoin. Il s’est notamment exprimé sur la proposition Quantum-Resistant Address Migration Protocol de Jameson Lopp, exprimant une préférence pour une approche sans contrainte forcée de migration, illustrant un positionnement libéral sur la gestion des fonds exposés.
Travaux techniques et logiciels : Il développe une bibliothèque de signatures post-quantiques dédiée à Bitcoin (libbitcoinpqc), implémente des prototypes sur Rust-Bitcoin et explore la compatibilité avec les schémas de signature standardisés. Par le passé, il a dirigé l’ingénierie du portefeuille BitMask chez DIBA (2022–2023), utilisé pour la gestion d’actifs RGB. Il est également à l’origine de Carbonado (stockage résilient) et Layered Bitcoin (infrastructure de couches). Bien qu’il soit actif dans l’écosystème technique de Bitcoin, aucun commit n’indique à ce jour une contribution directe au dépôt principal de Bitcoin Core.
Affiliations professionnelles : En 2025, il rejoint l’équipe Anduro (filiale de Marathon Digital Holdings) pour piloter l’implémentation du BIP‑360. Il est aussi le fondateur de Surmount Systems, projet lancé en 2024. Auparavant, il a occupé un poste de direction technique chez DIBA et semble avoir travaillé chez Microsoft, selon ses propres mentions professionnelles.
Lien avec le NIST et les standards : Hunter Beast n’est membre d’aucun comité normatif, mais son travail se base explicitement sur les standards post-quantiques validés par le NIST (FALCON, Dilithium, SPHINCS+), ce qui vise à garantir la compatibilité avec les environnements de sécurité industriels (FIPS, HSM, etc.). Il ne participe pas à des travaux IETF ou ISO connus, concentrant son activité normalisatrice sur le processus BIP de Bitcoin.
Ethan R. Heilman (pas de pseudonyme connu)
Contributions aux BIPs : Co‑auteur du BIP‑360, il a apporté une expertise complémentaire sur la cohérence du format avec Taproot, ainsi que sur l’intégration script/Schnorr. Il est également l’auteur du BIP‑347 (OP_CAT in Tapscript), visant à réintroduire un opcode supprimé pour enrichir les capacités des scripts Taproot.
Travaux sur Bitcoin et la cryptographie : Il est un chercheur actif sur les structures Taproot/Tapscript, notamment sur la scalabilité et la sécurité. Il a récemment proposé des mécanismes de compression non-interactive des transactions post-quantiques, pour réduire les coûts liés aux grandes tailles de signatures. Il contribue aux discussions de fond sur la scalabilité des signatures post-quantiques dans Bitcoin Core.
Affiliations académiques et professionnelles : Ethan Heilman est chercheur chez Cloudflare (depuis 2024), Research Fellow au MIT DCI (Digital Currency Initiative), et ancien doctorant à l’Université de Boston (PhD 2022) avec spécialisation en sécurité réseau, attaques P2P et cryptanalyse. Il a été CTO de BastionZero, entreprise acquise par Cloudflare.
Expertise reconnue : Il est auteur de publications scientifiques majeures (> 3000 citations), incluant des travaux sur la sécurité des blockchains, les attaques réseau (ex. eclipse attacks), et la cryptanalyse de fonctions de hash (Curl-P, SHA‑3).
Lien avec le NIST et la normalisation : Sans être formellement affilié au NIST, il s’inscrit dans une logique de compatibilité avec les algorithmes post-quantiques validés (Dilithium, SPHINCS+, Falcon). Il soutient l’adoption raisonnée de ces standards dans Bitcoin, notamment en combinant sécurité et scalabilité. Il ne dépend pas d’une autorité réglementaire mais suit de près les travaux NIST/CNSA.
Kyle Crews (rôle éditorial uniquement)
Rôle dans le BIP-360 : Mentionné comme relecteur et éditeur du BIP‑360, Kyle Crews a contribué à la lisibilité et à la cohérence linguistique du document. Il n’est pas co-auteur formel ni contributeur technique aux aspects cryptographiques.
Contributions au développement : Aucune trace de contribution à Bitcoin Core, Lightning ou aux projets de normalisation. Il n’est pas connu pour avoir rédigé de BIP ou participé à des dépôts publics (GitHub, etc.).
Affiliations : Présenté comme « co‑founder » avec Hunter Beast, il pourrait être impliqué dans Surmount Systems. Aucune trace publique n’atteste d’un rôle technique actif ni d’une affiliation à une institution académique ou normative.
Lien avec le NIST : Aucun lien connu, ni dans les travaux de standardisation, ni dans la cryptographie post-quantique.
Article publié originellement le 18 juillet 2025 sur linkedin.
A propos de l’auteur
Cofondateur de 4NK, Nicolas Cantu est entrepreneur, conférencier, enseignant et expert de Bitcoin de longue date.
