« Irréaliste » : James Hilliard, créateur de BIP 91, a des mots choisis pour Segwit2x

"Dingue."

Non, le développeur James Hilliard ne décrit T son déjeuner.

C'est plutôt son choix de description pour Segwit2x, le controverséfeuille de route technique annoncé par les startups et les mineurs de Bitcoin en mai, et qui a été au centre d'un large débat depuis.

Comme de nombreux développeurs, Hilliard estouvertement critiquede la proposition et des délais qu'elle cherche à imposer au développement. Pourtant, son scepticisme est particulièrement notable car il a peut-être joué le plus grand rôle dans l'amélioration de la perception que le plan avance.

Si vous alliez jusqu’à prétendre qu’il est la raison pour laquelleChronologie de Segwit2x est atteint (et que le Bitcoin ne s'est T divisé en deux actifs concurrents), vous ne trouverez T beaucoup de détracteurs.

C'est parce que Hilliard a été la force motrice derrière une proposition de code appeléeBIP 91. Destiné à coordonner les mineurs pour faire avancer l'optimisation du code tant attendue Segregated Witness (SegWit), il a été qualifié de premier des deux éléments de la feuille de route Segwit2x, bien que cela puisse obscurcir le fait qu'il s'agissait en fait d'une idée extérieure.

Après l'approbation du BIP 91 par les mineurs la semaine dernière, etsauf bossesSegWit pourrait être activé d'ici fin août. Il ne faut pas sous-estimer cette étape majeure pour le réseau, ONE permet à un développement technique annoncé depuis longtemps de sortir de l'impasse politique et de se rapprocher de son activation.

Et pour beaucoup, c’est Hilliard qui mérite le crédit.

Ce qu'il pense vraiment

Étant donné la forte politisation du développement ces derniers temps, il ne devrait T être surprenant que les motivations de Hilliard pour son rôle dans la mise à niveau du code aient été remises en question.

Soutient-il une éventuelle et controversée mise à niveau vers une taille de bloc de 2 Mo ? Le fait-il en grande partie pour éviter une scission ? Quelle équipe de développeurs préfère-t-il ?

Dans une nouvelle interview, Hilliard a toutefois clairement indiqué qu'il n'était pas un fan de l'accord complet Segwit2x, en particulier du passage à 2 Mo qu'il cherche à mettre en œuvre plus tard cette année.

La prochaine étape pour Segwit2x est d'augmenter la taille des blocs via un hard fork, un processus qui a été fortement débattu (sans parler du fait qu'il a été dénoncé comme dangereux s'il n'est pas correctement implémenté).

Déjà, le développeur de Segwit2x, Jeff Garzik, estorganiser la chargeVers cette étape importante. Cependant, Hilliard s'inquiète de cette approche. Par exemple, il estime que le délai de trois mois prévu pour Segwit2x est pour le moins trop court.

« Trois mois pour un hard fork, c'est complètement irréaliste », a-t-il déclaré à CoinDesk, ajoutant :

« Même le codage et les tests, sans parler du déploiement… c'est assez difficile. »

De nombreux autres développeurs

Ils soutiennent qu'il y a peu de chances qu'un hard fork de 2 Mo puisse être exécuté en toute sécurité en trois mois, car il s'agit d'un changement qui pourrait conduire les utilisateurs à perdre des Bitcoin s'il n'est pas mis en œuvre correctement.

« Inconnus inconnus »

Et Analyses de Hilliard devrait compter sur cette question.

Lorsqu'il ne travaille pas comme technicien pour la société minière BitmainWarranty, Hilliard consacre du tempsrecherche de hard forks sûrs. Par conséquent, il estime que les changements apportés au code « consensuel » de Bitcoin (les règles qui KEEP le réseau en un ONE morceau) sont naturellement difficiles.

« Rien n'est simple en matière de code consensuel, surtout pas celui- ONE. Ça LOOKS simple en apparence, mais quand on y réfléchit, c'est vraiment compliqué », a-t-il déclaré, ajoutant :

« Il y a tellement de choses qui pourraient mal tourner. »

Il a cité SegWit comme exemple, soulignant qu'il avait fallu des mois pour corriger tous les problèmes « connus » du code. Mais les développeurs, a-t-il souligné, doivent composer avec «inconnus inconnus."

« Au fur et à mesure que vous le mettez en œuvre, vous réalisez : "Voilà un problème à régler." Et un autre surgit, puis un autre encore », a-t-il déclaré.

C'est pourquoi de nombreux La rédaction de Bitcoin CORE se méfient des délais stricts, comme ceux préconisés par l'accord Segwit2x. « On ne sait T vraiment combien de temps il faudra pour que le changement soit effectif », a-t-il ajouté.

Et certains diront que le groupe Segwit2x ne prend T très au sérieux ces problèmes de sécurité logicielle.

Comme preuve que d'autres commencent à penser de la même manière, Hilliard est allé jusqu'à affirmer que les pools de minage de Bitcoin pourraient ne pas Réseaux sociaux le code créé par les développeurs de Segwit2x, même si ils se sont engagés à.

En d'autres termes, ils pourraient simplement revenir au logiciel de Bitcoin Core avant le hard fork, car ils n'ont T nécessairement besoin de s'engager dans un nouveau logiciel.

En effet, le pool minier F2pool, et peut-être d'autres pools miniers, exécutent déjà Bitcoin CORE avec BIP 91 au lieu du logiciel Segwit2x, une démarche qui contribue grandement à indiquer quel code est fiable.

Examen clos

Un problème qui va de pair avec cela est que certains utilisateurs ont critiqué le groupe Segwit2xpour se fermerde certains des développeurs les plus compétents du secteur.

Seuls quelques développeurs et entreprises ont initialement été invités à rejoindre la liste de diffusion et le groupe Slack, où les tests sont effectués et discutés. (Cependant, Slack est ouvert aux nouveaux membres depuis hier.)

Et même si son idée a été acceptée par le groupe, Hilliard pense qu'il est vrai que le processus d'évaluation de Segwit2x est fermé.

La rédaction de Bitcoin CORE rejeter à l'unanimitéla proposition, par exemple, mais leurs commentaires ont été ignorés (ou carrément rejetés).

Il a déclaré à CoinDesk:

« La raison pour laquelle ces types de projets n'ont T de modèles de développement ouverts est que lorsque vous proposez des idées potentiellement mauvaises – par exemple, proposer un hard fork en trois mois – le faire en public est assez difficile car lorsque les mauvaises idées sont exposées à la critique publique, elles sont détruites. »

Même si cela peut sembler être une réaction importante à une petite chose, il n'est pas le seul à penser que l'objectif de Segwit2x est de faire passer les besoins des startups à haut risque avant ceux des utilisateurs d'une véritable monnaie en ligne décentralisée.

Le PDG de Blockstream, Adam Back, qui a été un autre opposant déclaré de Segwit2x pour une raison similaire, a déclaré à CoinDesk qu'il pensait que le processus de développement fermé était « hautement contraire à l'éthique » et « pas du tout dans l'esprit du développement d'un protocole Internet ouvert ».

De tels commentaires soulignent la probabilité que les débats techniques se poursuivent, même si la capacité du bitcoin pourrait bientôt augmenter.

Déclaration de transparence:CoinDesk est une filiale de Digital Currency Group, qui a aidé à organiser la proposition Segwit2x.

Image de James Hilliard via Flickr