Si tu es déjà à l’aise avec le web, Polkadot Products ne demande pas d’apprendre un autre métier. Tu builds ton front comme d’habitude. La différence, c’est ce qui remplace l’hébergeur, le DNS et le login. À la place d’un bucket S3 ou d’un Vercel, tes fichiers partent sur Bulletin : une parachain de stockage. Ce ne sont plus des "dossiers sur un serveur", ce sont des octets identifiés par leur empreinte (un CID). Pour le nommage, plus de DNS vers une IP : DotNS fait pointer un nom .dot vers ce contenu. Le nom dit quoi servir, pas sur quelle machine. Côté identité, plus d’extension navigateur ou d’OAuth classique : comptes et signatures passent par le host Polkadot, surtout Mobile. La puissance, c’est ça : hébergement, nommage et identité dans le même modèle permissionless. Pas de cloud "à toi" au milieu pour faire tourner l’app. Ce n’est pas magique non plus. Il y a des quotas, une durée de rétention, et un renew pour prolonger ce qui doit rester dispo. Comme un vrai système, pas un disque infini. En résumé : tu codes comme un front. Tu publies comme un Product.

En septembre 2018, un développeur signale à Bitcoin Core ce qui semble n'être qu'un simple bug capable de faire crasher certains nœuds. Il suffit d'une transaction particulière pour provoquer le problème. Grave, mais pas inédit. Puis, en analysant le problème plus en profondeur les développeurs réalisent quelque chose de beaucoup plus inquiétant. Une transaction peut contenir deux fois la référence au même UTXO. Sa valeur peut alors potentiellement être comptée deux fois. Si cet UTXO contient 1 BTC, le logiciel vulnérable peut alors considérer qu'il dispose de 2 BTC en valeur d'entrée, alors qu'un seul bitcoin existe réellement. Le plus intéressant c'est que ce n'était pas un bug volontairement introduit pour modifier Bitcoin. C'était le résultat d'une succession de changements et d'hypothèses dans le code. Une vérification avait été optimisée. Une autre partie du code était supposée garantir l'invariant. Puis une refonte avait subtilement changé ce comportement. Et donc une règle fondamentale n'était plus correctement garantie : un même UTXO ne doit jamais pouvoir être dépensé deux fois dans une même transaction. Pendant quelques jours, des versions vulnérables de Bitcoin Core étaient déployées sur le mainnet. La vulnérabilité était potentiellement exploitable. Mais publiquement, elle n'était initialement présentée que comme un problème de crash. Pourquoi ? Parce qu'annoncer immédiatement : « Bitcoin contient peut-être une vulnérabilité permettant de créer des bitcoins à partir de rien » aurait également donné une information précieuse à quelqu'un cherchant à l'exploiter. Il fallait donc gagner du temps. Corriger le logiciel. Faire mettre à jour les acteurs les plus importants. Protéger suffisamment le réseau. Puis raconter toute l'histoire. Et c'est peut-être la partie la plus dingue : pendant quelques jours, Bitcoin mainnet avait potentiellement une vulnérabilité d'inflation exploitable. Personne ne sait exactement combien de personnes avaient compris ce que ce bug permettait réellement. Et personne ne sait si quelqu'un l'avait découvert indépendamment avant que le correctif soit déployé. Aucune exploitation connue n'a finalement eu lieu sur le mainnet. Mais le bug a ensuite été démontré sur testnet. Un bloc contenant une transaction avec le même UTXO référencé deux fois a été miné. Certains nœuds crashaient. D'autres acceptaient le bloc. Les nœuds corrigés le rejetaient. Même bloc. Même transaction. Trois comportements différents. Et c'est peut-être là que cette histoire devient plus profonde qu'une simple faille de sécurité. Bitcoin n'est pas sécurisé parce que son code ne contient jamais de bugs. Il est sécurisé parce que lorsqu'une règle critique est découverte comme incorrecte, le réseau doit réussir à converger de nouveau vers une même réalité. En 2010, un bug avait créé 184 milliards de BTC sur le mainnet. En 2018, Bitcoin a évité ce qui aurait pu devenir une seconde crise inflationniste majeure. La différence ? En 2010, le bug avait déjà été exploité. En 2018, Bitcoin a évité ce qui aurait pu devenir une seconde crise inflationniste majeure. Et cela soulève une question assez intéressante : Combien de vulnérabilités critiques ont existé dans Bitcoin sans que nous sachions jamais qui les avait comprises avant tout le monde ? La prochaine grande vulnérabilité de Bitcoin est peut-être déjà là. Pas nécessairement cachée dans une ligne de code évidente, mais dans une hypothèse que tout le monde considère aujourd'hui comme acquise.

Je viens de découvrir un truc sur Bitcoin que je trouve vraiment sous-coté : les Silent Payments (BIP-352). Le principe est assez fou. Tu peux publier une seule adresse Bitcoin permanente, qui commence par sp1q..., et la donner à tout le monde. Contrairement à une adresse Bitcoin classique, quelqu’un ne peut pas simplement copier cette adresse dans un explorer et voir tout ce que tu as reçu. Techniquement, quand quelqu’un t’envoie des BTC, il ne paie pas directement ton adresse sp1q.... Son wallet utilise les données cryptographiques de ton Silent Payment et de la transaction pour dériver un nouvel output Taproot unique. Donc si 10 personnes m’envoient du Bitcoin, la blockchain verra 10 outputs différents, sans lien public évident entre eux. Mon wallet peut reconnaître ceux qui m’appartiennent grâce à une clé de scan. J’aime beaucoup l’idée : une identité Bitcoin permanente que tu peux afficher publiquement, sans transformer ton historique financier en information publique. Évidemment, ça ne rend pas Bitcoin totalement anonyme et tu peux toujours recréer des liens en dépensant tes UTXO d’une mauvaise manière. Mais pour la réception, je trouve le concept incroyablement élégant. Je viens de le tester directement avec Cake Wallet. Silent Payments / BIP-352. Clairement une fonctionnalité Bitcoin dont je n’entendais quasiment jamais parler.

[#99]🧵L'étrange absence d'Adam Il y a une chose qui me paraît de plus en plus étrange chez Adam Back. Il échange avec Satoshi avant Bitcoin. Il reçoit le pré-release. Il connaît Hashcash et b-money. Et pourtant, au lancement : il ne mine pas.