D’après le sondage que nous avons effectué hier sur Twitter, les lecteurs de bitcoin.fr se déclarent à 61% favorables à l’accord conclu par Digital Currency Group en marge de la conférence Consensus 2017. Les experts français du Bitcoin semblent en revanche beaucoup plus réservés. Pierre-Marie Padiou d’Acinq, Pierre Noizat de Paymium, Nicolas Bacca de Ledger et Nicolas Dorier, contributeur de Core, ont accepté de nous donner leur point de vue sur ce sujet.
On mesure les enjeux d’une activation rapide de Segwit [1] pour l’équipe d’Acinq qui travaille sur Eclair, une implémentation du Bitcoin Lightning Network. Pour autant l’accord du 23 mai ne fait pas l’unanimité dans l’équipe : « Fabrice [Drouin] et moi avons un avis différent sur la question, donc Acinq n’a pas de position officielle. Preuve que le sujet n’est pas évident à trancher ! » – Pierre-Marie Padiou, CEO d’Acinq.
Côté Paymium le scepticisme est le même : « Je crois que SegWit devrait être activé via “soft fork” sans lien avec un “hard fork” futur. Un “hard fork” pour passer la “blocksize limit” à 2Mbyte n’est pas forcément consensuel et donc dangereux (risque de “split” du réseau) car il risque de favoriser encore la centralisation du minage et de réduire le nombre de “full nodes”. Donc pas d’avis définitif sur la question mais pas d’enthousiasme pour cette proposition : je reste attaché à une implémentation de référence (Bitcoin Core) qui reste la meilleure garantie de sécurité du réseau. Rappelons-nous que la sécurité consiste à empêcher certains de faire certaines choses. Permettre à tout le monde de faire n’importe quoi est excitant mais ce n’est pas le sujet de Bitcoin qui est la sécurité. L’UASF avec BIP 148 est à mon avis une idée plus intéressante que la proposition du DCG. » – Pierre Noizat, cofondateur et CEO de Paymium.
Sollicitée à de plusieurs reprises par Barry Silbert, la société Ledger n’a pas voulu signer le Bitcoin Scaling Agreement :
« Notre position vis à vis de cet accord est que nous ne le soutenons pas techniquement, mais acceptons de réaliser des tests et de l’intégration afin de limiter les dommages collatéraux potentiellement infligés à nos utilisateurs et les laisser libres de choisir leur “backend” parmi l’ensemble des propositions (soit principalement celle-ci, l’ensemble des propositions regroupées sous le sigle UASF, ou la chaine actuelle).
Mon opinion personnelle :
Même si cet accord ressemble beaucoup à la proposition de Hong Kong, des points fondamentaux restent flous : la limitation totale du “bloc” à 4 Mb (en conditions d’attaque, Segwit peut générer des “blocs” de 8 Mb avec une max blocksize de 2 Mb), l’engagement sur les extensions intéressantes de Segwit (MAST, Schnorr) qui n’est plus du tout pris en considération.
De plus l’accord intervient dans un contexte totalement différent sur le réseau : il y a déjà un Segwit en cours de signalisation, et resignaler la même chose autrement pose potentiellement des problèmes avec les nœuds actuels qui ne seront pas mis à jour – il faut bien réaliser que Segwit a été testé pendant un an et que la majorité de ces tests concernaient l’interopérabilité du protocole P2P avec l’ensemble des autres nœuds – l’implémentation des transactions en elle-même n’a pris que quelques semaines.
Je considère que cet accord représente assez bien ce qu’il faut éviter pour une bonne évolution du protocole : un compromis mal ficelé (cf https://tools.ietf.org/
Mes préférences concernant les choix à suivre iraient plutôt vers :
– ne toucher à rien sur la roadmap en cours (visiblement les mineurs sont prêts à accepter Segwit techniquement, ça ne devrait pas leur poser de soucis de le signaler) ;
– ou BIP 149 (changer la méthode de signalisation de Segwit une fois que la première période a expiré pour ne pas compliquer les cas de test).
S’il y a un problème urgent à régler sur Bitcoin, c’est plus l’estimation des “fees” que la taille maximale des blocs. Aujourd’hui les services d’estimations que tout le monde utilise (21, Core) sont trop conservateurs, et ont pour conséquence d’empirer le problème d’augmentation des “fees”. Des améliorations notables sont attendues pour la version 0.15 de Core (estimée en Septembre). » – Nicolas Bacca, CTO de Ledger.
Nicolas Dorier, qui fait partie de l’équipe qui a travaillé sur Segregated Witness avec Pieter Wuille, ne croit pas davantage à la solution proposée par Sergio Lerner : « Une fois qu’ils l’auront spécifiée correctement et que tout le monde sera d’accord, il faudra encore qu’ils la développent. Or ils ont laissé de côté les détails contentieux qui vont revenir sur la table quand ils vont vouloir avancer.
D’après ce que j’ai compris il y aura une taille de block effectif de 4MB qui est trop gros à mon goût (mon block explorer QBitNinja ne marchera peut être plus à ce niveau). Dans l’éventualité où ils arrivent à se mettre d’accord sur les détails techniques, le temps qu’ils développent la solution et qu’ils l’activent, je pense qu’il y aura bien encore au minimum 10 mois.
De l’autre coté, il y a BIP148 et BIP149 qui sont déjà développés et spécifiés… Je pense que BIP148 ou BIP149 ont beaucoup plus de chance de passer que l’accord à Consensus. »
À lire également sur le sujet : « Why I support BIP148 » par Eric Lombrozo.
[1] Segwit, qui corrige le « bug » de la malléabilité, est un préalable au déploiement du Bitcoin Lightning Network.
