Aller au contenu
SATWEI

Développement

Versions, avis de sécurité et travaux sur le protocole, par ceux qui conçoivent les logiciels Bitcoin.

121 publications

Développement2 min de lecture

Podcast récapitulatif de la newsletter Bitcoin Optech #429

Greg Sanders, Antoine Poinsot, Elias Rohrer, Oleksandr Kurbatov et Nishant Bansal rejoignent les animateurs d’Optech pour revenir sur le numéro #429. L’émission s’ouvre sur Bitcoin Core #36665, #36667 et #36669, puis aborde la politique de sécurité mise à jour. Viennent ensuite les paiements silencieux multipartites, une faille DoS de Core Lightning rendue publique et Eclair 0.14.6 ; la transcription se fait encore attendre.

Bitcoin Optech

Développement14 min de lecture

Newsletter Bitcoin Optech #429

Il suffisait d’une annonce de canal désignant le même nœud aux deux extrémités pour faire planter Core Lightning, de 25.02 à 26.04, à chaque redémarrage, le tout pour le seul prix de frais on-chain ; le correctif est arrivé avec 26.04.1. La newsletter #429 présente aussi le protocole d’Oleksandr Kurbatov pour des entrées multipartites en paiements silencieux, ainsi que les versions correctives accélérées de Bitcoin Core face aux bugs faciles à découvrir.

Bitcoin Optech

Développement1 min de lecture

Bitcoin Core 29.5 disponible

Plus d’écart entre poll() et select() pour la surveillance des exceptions de socket dans Bitcoin Core 29.5 (#36665), et les pairs en pause d’envoi se voient imposer un délai d’expiration (#36667). Les positions des flatfiles passent en entiers 64 bits (#36669), les nœuds présument v2transport pour les adresses issues des seeds, et un seed DNS disparaît.

Bitcoin Core

Développement4 min de lecture

Débordement du fichier d’annulation dans des conditions extrêmes

Un mineur pouvait faire dépasser 4 Gio à un fichier d’annulation (undo) de Bitcoin Core : ses positions sur 32 bits repartaient alors de zéro et corrompaient les données, de sorte que les nœuds s’arrêtent si une réorganisation bien placée s’ensuit ; sous Windows et sur les systèmes 32 bits, l’échec survient dès 2 Gio, sans réorganisation. De faible gravité, CVE-2026-117346 exigerait environ un mois de la totalité des blocs du réseau. Les versions 32.1, 31.2, 30.4 et 29.5 corrigent les systèmes 64 bits ; les nœuds 32 bits et le stockage des blocs sur FAT32 restent concernés.

Bitcoin Core

Développement2 min de lecture

Hors Linux, les données urgentes TCP font gonfler la mémoire sans limite

Sous Windows, macOS et BSD, un pair connecté pouvait faire tomber un nœud en lui envoyant des données urgentes TCP : elles échappaient aux lectures en pause du backend select() et la mémoire s’accumulait sans limite (CVE-2026-117350). Les nœuds Linux, qui utilisent poll(), ne sont pas concernés. Bitcoin Core 32.1, 31.2, 30.4 et 29.5 corrigent ce bug de gravité moyenne, repéré par un LLM lors d’une analyse menée dans le cadre de Project Loupe.

Bitcoin Core

Développement1 min de lecture

Bitcoin Core 30.4 est sorti

Bitcoin Core 30.4 cesse de considérer les bits 5 à 28 de BIP 9 comme des signaux de soft fork, conformément à BIP 323 : les blocs qui les activent ne déclenchent plus d’alertes de déploiement inconnu (#34779). Côté réseau, un délai d’expiration s’applique désormais aux pairs en pause d’envoi (#36667), et les positions des flatfiles passent en entiers 64 bits (#36669).

Bitcoin Core

Développement1 min de lecture

Sortie de Bitcoin Core 31.2

La diffusion privée a désormais un plafond dans Bitcoin Core 31.2 : la file des transactions que le réseau n’a pas encore renvoyées s’arrête à 10 000 entrées et refuse tout nouvel envoi une fois pleine, à charge pour l’appelant de la vider avec abortprivatebroadcast (#35406). Conformément à BIP 323, les bits de version 5 à 28 ne comptent plus comme signaux de soft fork.

Bitcoin Core

Développement1 min de lecture

Bitcoin Core 32.1 est sorti

Plus de risque de voir l’adresse IP de l’expéditeur exposée par la diffusion privée dans Bitcoin Core 32.1 : la fuite pouvait survenir quand une connexion v2 ratée était retentée en v1 directement, et non via Tor. La valeur par défaut de -maxconnections passe de 125 à 200, et le débit du relais sortant des transactions est limité par une file globale plutôt que pair par pair.

Bitcoin Core

Développement1 min de lecture

Podcast récapitulatif de la newsletter Bitcoin Optech #428

Adam Gibson détaille Lichen, sa couche 2 à émetteur unique avec sorties unilatérales validées par BitVM, dans le récap du numéro #428. João Dias et Vincenzo Palazzo sont les autres invités de Gustavo Flores Echaiz et Brandon Black ; il est aussi question de syntaxe de descripteurs pour les préimages de hachage, de rbitcoin 0.8.0 et de LND v0.21.5-beta.rc1.

Bitcoin Optech

Développement11 min de lecture

Newsletter Bitcoin Optech #428

Avec Lichen, conçu par Adam Gibson, les utilisateurs d’une couche 2 à émetteur unique peuvent récupérer leurs bitcoins on-chain si le hub refuse ou se met hors ligne ; les litiges se règlent à coups de preuves Groth16 et de transactions BitVMX présignées. La newsletter #428 aborde aussi la proposition de João Dias pour une forme privée de préimage des fragments de hachage miniscript ; Ibis Wallet v5.0-beta et rbitcoin 0.8.0 figurent parmi les mises à jour logicielles.

Bitcoin Optech

Développement1 min de lecture

Podcast récapitulatif de la newsletter Bitcoin Optech #427

Deux bugs mémoire d’Eclair dans la poignée de main d’ouverture de canal sont au menu du récap #427, expliqués par Erick Cestari : l’un a été débusqué par le fuzzer de Matt Morehouse, l’autre à l’aide d’un LLM. Adam Gibson présente ensuite LN-GAP, illustré par une partie d’échecs jouée dans un canal Lightning. Bitcoin Core 32.0rc4 et une série de correctifs pour Eclair arrivent plus tard dans l’émission.

Bitcoin Optech

Développement11 min de lecture

Newsletter Bitcoin Optech #427

Eclair v0.14.0 et les versions antérieures pouvaient se retrouver à court de mémoire pendant l’ouverture d’un canal : un bug laissait fuir environ 1 Mo par seconde, un autre épuisait 4 Go en 48 minutes environ via une seule connexion, sans aucun coût on-chain. Les deux sont corrigés dans v0.14.1. La newsletter #427 les place à côté de LN-GAP, le schéma d’Adam Gibson pour des contrats à plusieurs tours au sein des canaux Lightning, qui repose sur un comité à majorité honnête.

Bitcoin Optech

Développement2 min de lecture

Podcast récapitulatif de la newsletter Bitcoin Optech #426

Clara Shikhelman ouvre le récap #426 avec Shielded Bitcoin, une proposition dont elle est coautrice pour déplacer des bitcoins sans diffuser expéditeur, destinataire ni montants, sans changement de consensus ni opérateurs. Elias Rohrer, de Spiral, enchaîne sur les versions LDK v0.3-rc3 et v0.2.7 et sur les modifications du code de LDK, avec Gustavo Flores Echaiz à l’animation.

Bitcoin Optech

Développement13 min de lecture

Newsletter Bitcoin Optech #426

Proposé par Misha Komarov avec Clara Shikhelman et Aleksei Moskvin, Shielded Bitcoin est un métaprotocole de transferts on-chain privés qui se passe de tout changement de consensus, mais exige une cérémonie d’initialisation unique et laisse une trace à l’entrée comme à la sortie. Anthony Towns rédige un BIP permettant aux pairs de choisir leurs propres identifiants de message sur un octet via le transport BIP324, tandis que Fabian Jahr demande si les tags des tagged hashes doivent porter un numéro de BIP.

Bitcoin Optech

Développement18 min de lecture

Newsletter Bitcoin Optech #425

Dans Eclair v0.13.1 et antérieures, une requête gossip de 64 ko pouvait enfler jusqu’à 64 Mo, et un message init de longueur maximale brassait quelque 300 Mo : Matt Morehouse a rendu publics ces deux bugs DoS, corrigés dans v0.14.0. Jakub sonde l’intérêt pour une synchronisation des étiquettes de portefeuille BIP329 via un stockage non digne de confiance, pendant que la rubrique consensus de la newsletter #425 revient sur les types de sorties post-quantiques.

Bitcoin Optech

Développement59 min de lecture

Podcast récapitulatif de la newsletter Bitcoin Optech #424

Ahmet Kurt explique PQLN, la sécurité post-quantique pour les surfaces off-chain de Lightning, dans le premier segment préenregistré de l’émission d’Optech. Jan B, contributeur de Bitcoin Core qui relit des PR et travaille sur le code du kernel, rejoint Gustavo Flores Echaiz et Mike Schmidt pour la partie en direct, où Bitcoin Core 32.0rc2 et son guide de test sont à l’ordre du jour.

Bitcoin Optech

Développement12 min de lecture

Newsletter Bitcoin Optech #424

PQLN, signé Ahmet Kurt et ses collaborateurs, met à l’abri des attaques quantiques le gossip, le transport, les factures, les offres et l’onion de Lightning, sans toucher aux opérations on-chain, qui nécessiteraient un changement de consensus. La bande passante en paie le prix : un nœud télécharge 10 fois plus de données et en stocke 9 fois plus, alors que la signature ML-DSA ne prend que 0,33 ms. Une implémentation fonctionnelle sur rust-lightning peut déjà être testée.

Bitcoin Optech

Développement68 min de lecture

Podcast récapitulatif de la newsletter Bitcoin Optech #422

Adam Gibson présente à Mark Erhardt et Mike Schmidt, animateurs d’Optech, Babilonia, son protocole de coinjoin déguisé en paris discrets, et cite un article de Ron Rivest de 1997 sur les micropaiements façon loterie comme lointaine racine des paiements probabilistes. Rob Segers revient ensuite sur ses mesures d’un client léger pour paiements silencieux.

Bitcoin Optech

Développement11 min de lecture

Newsletter Bitcoin Optech #422

Babilonia, proposition d’Adam Gibson, déguise les coinjoins en tirages à pile ou face on-chain qui, vus de l’extérieur, ressemblent à des paiements ordinaires, même si son article admet que l’efficacité du protocole n’a pas encore de mesure claire. D’après les benchmarks de Rob Segers, BlindBit Oracle v2 télécharge environ 2,1 fois plus qu’un filtre limité à taproot avec données de tweak, en échange de l’absence de faux positifs. LDK v0.2.6 colmate une vulnérabilité de déni de service.

Bitcoin Optech

Développement1 min de lecture

Sortie de Bitcoin Core 29.4

Les lectures et écritures disque intensives en fonctionnement normal venaient d’un bug corrigé dans Bitcoin Core 29.4 : la base chainstate réécrivait sans cesse de grandes parties d’elle-même. Le correctif désactive la seek compaction de LevelDB et compacte le chainstate à intervalles réguliers (#35465).

Bitcoin Core