Pocas personas entienden los problemas técnicos clave que enfrenta actualmente la criptomoneda dominante en el mundo Andrew Chow es uno de ellos.
Chow es uno de los cuatro «mantenedores» de Bitcoin Main (o simplemente «Core»), el software más well known para conectarse a la red de Bitcoin.
Los mantenedores revisan los cambios en Bitcoin Core conocidos como «confirmaciones», que son enviados, por otros desarrolladores de Bitcoin, como «solicitudes de extracción» o «PR». Chow y otros mantenedores luego aprueban o «fusionan» esos cambios en el código fuente de Main. La «revisión de código» es basic para garantizar que no se fusione ningún código con errores.
Chow es un jugador de corazón, y solo ingresó a Bitcoin en la escuela secundaria para pagar los videojuegos que de otro modo no podría pagar. Sus padres no le dieron una tarjeta de crédito, ni le abrieron una cuenta bancaria, ni siquiera le dieron una mesada. Recurrió al trabajo independiente en el foro BitcoinTalk y comenzó a escribir código a cambio de bitcoin (BTC).
Chow, que dice que ahora tiene veintitantos años, recibe un salario como ingeniero en la empresa de infraestructura de Bitcoin Blockstream, donde además de algunas tareas corporativas, su principal prioridad es trabajar en Bitcoin Core.
Él dice que la revisión del código es uno de los mayores desafíos que enfrenta Bitcoin en la actualidad. La mayoría de los desarrolladores de Main están interesados en escribir código para nuevas funciones, pero pocos disfrutan de la tarea más mundana de revisar el código enviado por sus compañeros. Chow dice que más contribuyentes deben centrarse en la revisión del código para abordar los más de 300 PR en el repositorio GitHub de Main. La comunidad tiene un Club de revisión de relaciones públicas de Bitcoin Main que se reúne semanalmente para ayudar a los contribuyentes más nuevos a aprender sobre el proceso de revisión.
Chow accedió a una entrevista con CoinDesk en la conferencia Advancing Bitcoin en Londres. Explicó por qué la revisión del código es tan crítica, explicó lo que hacen los contribuyentes de Bitcoin Main todos los días y analizó el debate actual sobre op_vault y Fast Trial. Aquí hay una transcripción parcial de esa entrevista.
CoinDesk: ¿Cómo descubrió Bitcoin?
Andrés Chow: Cuando era más joven, en la escuela secundaria, no tenía una cuenta bancaria porque tenía menos de 18 años. Mis padres no me abrieron una. No tenía tarjeta de crédito, ni siquiera una tarjeta de crédito supervisada, y no tenía una asignación. Pero Steam estaba vendiendo juegos por bitcoin. Si juegas en la Computer, puedes descargar Steam y tiene básicamente todos los juegos de Pc.
Además, en monedero.io, podrías vender bitcoins por cosas. Bueno, yo quería jugar juegos. Quería comprarlos. Quiero decir que estoy de acuerdo con piratear, pero ya sabes, piratear cosas es un poco incompleto. No sabes lo que estás descargando. Podría ser malware completo.
Así que pensé, esto de bitcoin es completamente electrónico. Tal vez pueda usar eso para comprar juegos, pero ¿cómo obtengo bitcoins? Tal vez pueda hacer algún trabajo y que me paguen en bitcoins.
Conozco a algunas personas que hicieron eso. Así fue como aprendí a programar. Entraría en BitcoinTalk y la gente diría: «Te pagaré lo que sea para que me escribas un script que haga esto».
Bueno, eso parecía bastante straightforward. Yo también tenía un amigo en la escuela secundaria. Él estaba como, “Oye, ¿has oído hablar de esto de Bitcoin? Creo que te puede gustar. Definitivamente estaba comprando drogas con bitcoin.
Así es como entré en Bitcoin. Y finalmente dije: “Bueno, estoy usando esta billetera y me estoy encontrando con estos problemas. Claramente sé cómo escribir un programa. Tal vez pueda arreglar esta billetera”. Así es como me metí en el desarrollo.
Dirigía esta cosa llamada Armory. Que básicamente no se mantuvo. Quiero decir, todavía lo mantiene un tipo, así que apenas.
Cuando lo estaba usando, period un desastre y no siempre funcionaba. Descubrí que algunos de los problemas que estaban ocurriendo en Armory eran causados por cosas que estaba haciendo Bitcoin Main. Así que comencé a ingresar a Bitcoin Core y a preguntar qué está haciendo Bitcoin Core. Oh, Bitcoin Core tiene este mistake que nos está causando un mistake.
Armory estaba haciendo algo no recomendado, que era leer los archivos de bloque directamente desde Bitcoin Main se supone que no debes hacer eso. Cuando cambiaron el formato, se rompió todo.
Estaba tratando de reconciliar los dos, y luego Armory simplemente se cayó de mi mapa. Así fue como hice la transición a Bitcoin Main. Eventualmente dejé de trabajar en Armory porque hice más en Core.
Ayer hablamos sobre la proporción de contribuyentes de Bitcoin que revisan código frente a los contribuyentes que escriben código. ¿Puedes compartir tus pensamientos sobre eso?
Nuestro principal cuello de botella en Bitcoin Core ha sido la revisión. Tenemos más de 300 relaciones públicas abiertas y deben revisarse. Ya sea solo para asegurarse de que el código sea bueno o solo conceptualmente como, «¿Queremos este cambio?»
El problema con cada PR es que generalmente una persona lo escribe, pero necesitamos varias personas para revisarlo, dar una aprobación o dejar comentarios. Por lo tanto, debemos tener más revisores que personas que escriben, pero no es así como funciona.
Personalmente, encuentro que la revisión del código es un poco aburrida. Es un poco molesto y puede ser un poco adormecedor. Pero todavía lo hago. Supongo que es como un mal necesario y es porque no lo encuentro divertido. Si lo hago lo suficiente, empiezo a sentir que me quemaré porque ya no es agradable.
Por lo tanto, debe encontrar un equilibrio entre escribir código y revisar código. Es un poco como un Catch-22. Tenemos que tener más revisores que codificadores, pero ¿cómo te vuelves lo suficientemente competente para revisar el código si no estás escribiendo código? Es un enigma.
Estamos en un mercado bajista y organizaciones como Brink que financian el desarrollo de Bitcoin dicen que la financiación se ha reducido en un 50%. ¿Por qué tenemos que pagar a los contribuyentes y desarrolladores de Bitcoin?
Fundamentalmente, cada pieza de software program tiene errores. Siempre habrá errores para encontrar y errores para corregir. Eso es solo el mantenimiento typical del software que debe suceder.
E incluso entonces, el software program que existe ahora no puede durar para siempre. Los sistemas operativos evolucionarán y las bibliotecas evolucionarán y cambiarán. Eventualmente, el software package simplemente dejará de compilarse en una computadora podría dejar de funcionar. Por lo tanto, debe haber un trabajo constante solo para mantenerlo actualizado.
Por lo tanto, siempre hay cosas que actualizar, incluso sin nuevas funciones. Pero hay nuevas características y queremos mejorar Bitcoin. No solo las reglas de consenso, sino también cómo retransmitimos las transacciones, qué tipo de transacciones aceptamos en el mempool y el protocolo peer-to-peer.
Puede haber vectores DoS que queramos corregir o cambiar y que tal vez aún no se hayan descubierto. Siempre hay algo.
Si soy un nuevo colaborador principal, ¿cuáles son algunos de los principales problemas que debería conocer?
Actualmente existen una serie de problemas, como los ataques de anclaje, que están bastante bien documentados. Parece ser que nadie los explota, pero esa no es una buena razón para no
Se ha trabajado mucho en el mempool: cómo y qué transacciones se aceptan en el mempool, qué métodos existen para aumentar las tarifas y cosas por el estilo. Es relevante para Lightning y otras redes L2.
¿Qué es un «ataque de fijación»?
Si ambos abrimos un canal Lightning juntos, puedo hacerlo para que nunca aumente la tarifa de esa transacción. Así que puedo hacerlo perpetuamente con una tarifa baja y nunca se extrae, luego trato de gastarlo dos veces más tarde.
Hay un montón de ataques que puedes hacer con las reglas de política de mempool existentes. Estos están documentados en la lista de correo y definitivamente son problemas. Si alguien intentara explotarlos, sería molesto, pero no creo que hayamos visto a nadie intentar explotarlos.
Todavía queremos corregirlos y se ha trabajado mucho para hacer mejoras para que no tengamos estos ataques de fijación, o al menos, si desea fijar una transacción, será muy costoso.
También hablamos ayer de op_vault y Speed Trial. Ha habido algunas tensiones en torno a la recomendación de James O’Beirne de implementar op_vault usando Fast Demo. ¿Algún comentario?
Con una nueva propuesta como esa, el despliegue debería ser lo último en lo que pensar.
Algunas concepts sobre cómo implementar las cosas son, por alguna razón, polémicas. Si desea tener una discusión sobre la propuesta, tener un despliegue allí hace que se descarrile.
Así que creo que James puso eso allí probablemente fue un mistake. La sección de implementación de Taproot no se definió hasta después de Taproot. Los cambios de código en sí mismos se fusionaron en Bitcoin Main pero no estaban activos. No es inusual decir simplemente que nos ocuparemos de la implementación después de que descubramos cuáles queremos que sean los cambios en el código.
Fast Demo fue un experimento para Taproot. Hemos probado diferentes métodos de implementación a lo largo de los años con diversos grados de éxito.
