Un PR intéressant de Bitcoin Core suscite l'attention : les développeurs soumettent un correctif pour la version v29, afin de corriger la vulnérabilité connue CVE-2025-46598.
La question est—pourquoi appliquer un correctif à une version ancienne ?
La raison fondamentale réside dans un changement majeur introduit par la v30 : la proposition #32406 a supprimé la limite de 80 octets pour l'opcode OP_RETURN. Cette modification a changé la stratégie de stockage par défaut, entraînant une différence de comportement entre différentes versions.
Certains opérateurs de nœuds utilisent encore la v29 ; ne pas appliquer ce correctif de sécurité pourrait entraîner des risques potentiels. Cela soulève un dilemme technique classique—comment trouver un équilibre entre l'innovation et la compatibilité rétroactive.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
21 J'aime
Récompense
21
5
Reposter
Partager
Commentaire
0/400
SellLowExpert
· 01-08 12:47
Haha, c'est le prix de la mise à niveau. Il y a toujours des gens laissés pour compte
Il y a encore beaucoup de personnes utilisant v29, les développeurs doivent prendre en compte ces "reliquats", c'est vraiment fatigant
Une fois la limite OP_RETURN brisée, il y a tout un tas de problèmes... C'est pourquoi je ne me précipite jamais à mettre à jour
Innover tout en assurant la compatibilité, c'est comme vouloir le beurre et l'argent du beurre, les équipes de développement doivent trouver un équilibre, c'est tellement difficile
Honnêtement, cette vulnérabilité est arrivée un peu de façon inattendue, pas étonnant qu'il faille un patch
Voir l'originalRépondre0
AirdropHunter007
· 01-06 12:25
Haha, il faut encore patcher v29, cette foutue histoire est toujours la même
Dès qu'on décompose la limite de 80 octets d'OP_RETURN, tout devient chaotique... Les nœuds doivent aussi se concurrencer chacun de leur côté
Voir l'originalRépondre0
RektRecorder
· 01-06 04:48
Cette histoire de patch v29, en réalité, c'est le vieux problème de compatibilité descendante
Y a-t-il encore des gens qui utilisent v30 ? Je vois que la plupart des pools miniers s'accrochent encore à v29...
La limite de 80 octets pour OP_RETURN, une fois levée, peut effectivement causer des problèmes, il faut gérer ce risque
Voir l'originalRépondre0
GhostChainLoyalist
· 01-06 04:33
Haha, c'est pourquoi beaucoup de gens restent bloqués à la version v29 et ne mettent pas à jour... il faut suivre les correctifs de sécurité
Un PR intéressant de Bitcoin Core suscite l'attention : les développeurs soumettent un correctif pour la version v29, afin de corriger la vulnérabilité connue CVE-2025-46598.
La question est—pourquoi appliquer un correctif à une version ancienne ?
La raison fondamentale réside dans un changement majeur introduit par la v30 : la proposition #32406 a supprimé la limite de 80 octets pour l'opcode OP_RETURN. Cette modification a changé la stratégie de stockage par défaut, entraînant une différence de comportement entre différentes versions.
Certains opérateurs de nœuds utilisent encore la v29 ; ne pas appliquer ce correctif de sécurité pourrait entraîner des risques potentiels. Cela soulève un dilemme technique classique—comment trouver un équilibre entre l'innovation et la compatibilité rétroactive.