Según entendí en su momento, a Gavin le llevaban buscando las cosquillas desde antes de 2014 porque consideraban que la forma de administrar el repositorio de GitHub era demasiado autoritaria pues empleaba un proceso de desarrollo denominado 'straw-man' para incluir las propuestas en el repositorio de Bitcoin, una vez migrado a GitHub (https://archive.is/XgQY7); si no recuerdo mal difería de cómo actuaba Satoshi pues le enviaban las sugerencias por correo electrónico y éste las validaba ó no.
Hasta finales de 2014 el 'straw-man' era la forma de proceder y es entonces cuando Gavin anuncia a van der Laan como nuevo 'lead developer' para que le ayude en las tareas del repositorio de Bitcoin (https://archive.ph/h0izI) pues Gavin se ocupaba de la Fundación Bitcoin y comenzaba a recibir consultas de las primeras empresas que se creaban alrededor del sistema no teniendo tiempo para revisar todas las proposiciones que llegaban a través de los 'branches' de los desarrolladores de Bitcoin en GitHub; es necesario señalar que Gavin no deja de contribuir al mismo, se observa un trabajo continuo entre 2014 y 2015, siendo su última interacción el 19 de Abril de 2016, menos de un mes antes de que le apartasen tras apoyar a Craig, (https://archive.is/ycCMP).
Tras la entrada de van der Laan, la forma de administración de los cambios en el repositorio de Bitcoin en GitHub cambia poco a poco: primero introduce un sistema de firmado de 'commits' en GitHub mediante gpg (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005881.html), después se elimina el proceso 'straw-man' de Andresen donde los desarrolladores trabajaban en sus propuestas en distintos 'branches' (ramas) dentro de GitHub, que eran discutidos y aceptados en la 'master branch' por Gavin tras un proceso de verificación y prueba de estabilidad y funcionamiento, y se introduce un sistema de claves compartido entre varios desarrolladores que administra los privilegios para fusionar ramas en la 'master branch' (https://github.com/bitcoin/bitcoin/commits/master/contrib/verify-commits/trusted-keys); ¿el por qué de este cambio? la falta de confianza en que GitHub no fuese a inyectar código malicioso en el repositorio de Bitcoin sin el consentimiento de los mantenedores siendo poco probable que pudiesen comprometer la clave GPG de alguno de ellos... Suena enrevesado, ¿no? Porque lo es, no es más que una excusa barata para subvertir la cadena de mando y entregársela a los 'desarrolladores proxy' de Blockstream.
Mientras estos cambios se introducen poco a poco, Gavin comienza a exponer en 2015 su preocupación sobre la continuidad en el tiempo de Bitcoin a medida que la recompensa disminuye y la urgencia por aumentar el límite de bloque (http://gavinandresen.ninja/time-to-roll-out-bigger-blocks, http://gavinandresen.ninja/bigger-blocks-another-way, http://gavinandresen.ninja/block-size-and-miner-fees-again, http://gavinandresen.ninja/are-bigger-blocks-dangerous, http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent). Dada la rotunda negativa del equipo de Core a eliminar el límite (véase la BIP 100, 101 que formaría parte de Bitcoin XT, 102 y 103; y probablemente me dejaré otras tantas), cambiado el proceso de desarrollo y el carácter demasiado conciliador de Gavin, éste decide ayudar a otras implementaciones que van naciendo en ese tiempo como Classic, Unlimited y XT, a la vez que sigue revisando código a nivel de protocolo y errores de implementación en Core pero esta situación genera desconfianza en la comunidad (idea implantada por Core) que comienza a verlo como un problema y un vector de ataque contra los "principios" defendidos por BTC (BlocksTream Coin) como él mismo señala en su publicación del 13 de Enero de 2016 (http://gavinandresen.ninja/classic-unlimited-xt-core) y aparece pormenorizado en este artículo de Hackernoon sobre la cuestión del escalado que ocurrió en 2015-2016 (hasta 2017): https://hackernoon.com/the-great-bitcoin-scaling-debate-a-timeline-6108081dbada.
Hasta finales de 2014 el 'straw-man' era la forma de proceder y es entonces cuando Gavin anuncia a van der Laan como nuevo 'lead developer' para que le ayude en las tareas del repositorio de Bitcoin (https://archive.ph/h0izI) pues Gavin se ocupaba de la Fundación Bitcoin y comenzaba a recibir consultas de las primeras empresas que se creaban alrededor del sistema no teniendo tiempo para revisar todas las proposiciones que llegaban a través de los 'branches' de los desarrolladores de Bitcoin en GitHub; es necesario señalar que Gavin no deja de contribuir al mismo, se observa un trabajo continuo entre 2014 y 2015, siendo su última interacción el 19 de Abril de 2016, menos de un mes antes de que le apartasen tras apoyar a Craig, (https://archive.is/ycCMP).
Tras la entrada de van der Laan, la forma de administración de los cambios en el repositorio de Bitcoin en GitHub cambia poco a poco: primero introduce un sistema de firmado de 'commits' en GitHub mediante gpg (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005881.html), después se elimina el proceso 'straw-man' de Andresen donde los desarrolladores trabajaban en sus propuestas en distintos 'branches' (ramas) dentro de GitHub, que eran discutidos y aceptados en la 'master branch' por Gavin tras un proceso de verificación y prueba de estabilidad y funcionamiento, y se introduce un sistema de claves compartido entre varios desarrolladores que administra los privilegios para fusionar ramas en la 'master branch' (https://github.com/bitcoin/bitcoin/commits/master/contrib/verify-commits/trusted-keys); ¿el por qué de este cambio? la falta de confianza en que GitHub no fuese a inyectar código malicioso en el repositorio de Bitcoin sin el consentimiento de los mantenedores siendo poco probable que pudiesen comprometer la clave GPG de alguno de ellos... Suena enrevesado, ¿no? Porque lo es, no es más que una excusa barata para subvertir la cadena de mando y entregársela a los 'desarrolladores proxy' de Blockstream.
Mientras estos cambios se introducen poco a poco, Gavin comienza a exponer en 2015 su preocupación sobre la continuidad en el tiempo de Bitcoin a medida que la recompensa disminuye y la urgencia por aumentar el límite de bloque (http://gavinandresen.ninja/time-to-roll-out-bigger-blocks, http://gavinandresen.ninja/bigger-blocks-another-way, http://gavinandresen.ninja/block-size-and-miner-fees-again, http://gavinandresen.ninja/are-bigger-blocks-dangerous, http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent). Dada la rotunda negativa del equipo de Core a eliminar el límite (véase la BIP 100, 101 que formaría parte de Bitcoin XT, 102 y 103; y probablemente me dejaré otras tantas), cambiado el proceso de desarrollo y el carácter demasiado conciliador de Gavin, éste decide ayudar a otras implementaciones que van naciendo en ese tiempo como Classic, Unlimited y XT, a la vez que sigue revisando código a nivel de protocolo y errores de implementación en Core pero esta situación genera desconfianza en la comunidad (idea implantada por Core) que comienza a verlo como un problema y un vector de ataque contra los "principios" defendidos por BTC (BlocksTream Coin) como él mismo señala en su publicación del 13 de Enero de 2016 (http://gavinandresen.ninja/classic-unlimited-xt-core) y aparece pormenorizado en este artículo de Hackernoon sobre la cuestión del escalado que ocurrió en 2015-2016 (hasta 2017): https://hackernoon.com/the-great-bitcoin-scaling-debate-a-timeline-6108081dbada.
Comments
Be the first to add a comment
Log in to comment