Jason Cox extiende invitación abierta para asistencia con el desarrollo y revisión del Código de Bitcoin cash

Las conversaciones de desarrolladores de BCH han tenido lugar antes de la próxima actualización de mayo de 2019. En su última reunión de video, los desarrolladores acordaron que necesitan saber cuánto BCH está encerrado en las direcciones de seguridad de p2sh. También se acordó que Andrea Suisani se hará cargo del límite del tamaño de la transacción del byte y Mark Lundeberg revisará el código de Amaury Sechet en las firmas Schnorr. Por último, Jason Cox extendió una invitación abierta para que el calificado ayude con el desarrollo y la revisión del código BCH.

Una reunión de desarrolladores de BCH se llevó a cabo recientemente para comenzar la próxima actualización de mayo de 2019. La reunión fue moderada por David R Allen y consistió en el desarrollador líder de Bitcoin ABC Amaury Sechet, el desarrollador de Bitcoin Unlimited Andrea Suisani, el desarrollador de Bitcoin ABC Antony Zegers, el desarrollador de Bitcoin ABC Jason B. Cox, el desarrollador de Openbazaar Chris Pacia, CTO de Bitcoin.com Emil Oldenburg, y el desarrollador de Bitcoin Cash, Mark Lundeberg.

Después de las presentaciones, la reunión se inició con discusiones sobre BIP 62. Zegers señaló que algunos usuarios de BCH no pueden recuperar sus fondos porque están enviando BCH a BTC en las direcciones P2SH de Segwit. Luego, Cox preguntó si era posible identificar el alcance de este problema. En respuesta, Oldenburg propuso indexar todas las direcciones segwit y luego verificar los UTXO, un proceso extremadamente lento.

Alternativamente, Lunderberg propuso una manera de corregir la maleabilidad de terceros mediante la aplicación de la regla de pila limpia al pago múltiple a clave pública y al pago múltiple a la secuencia de comandos de secuencia de comandos. De esa manera, todos los demás scripts tendrían que comprobarse manualmente utilizando OP_DEPTH. Sin embargo, señaló que su solución requeriría otra horquilla dura sobre la horquilla dura de mayo de 2019.

En conclusión, los desarrolladores concluyeron que necesitan medir la cantidad de monedas que están bloqueadas en las direcciones de seguridad de p2sh antes de continuar en BIP 62.

Lunderberg señaló que desde la bifurcación dura de agosto de 2017, se han registrado diez transacciones que tenían menos de 100 bytes. Dado que un límite de 100 bytes podría afectar algunas transacciones, propuso que se relajara a 64 bytes.

Curiosamente, Cox señaló que es más fácil reducir el límite de tamaño de la transacción de bytes que hacerlo. Suisani se sumó al punto de Cox y explicó que el aumento del límite de tamaño de la transacción de bytes debería ser implementado por la bifurcación.

Al final de la discusión, Suisani se ofreció a liderar la segunda agenda manteniendo una corriente de comunicación entre los desarrolladores y escribiendo notas para racionalizar la modificación de la restricción.

Sobre el tema de las firmas de Schnorr, Sechet señaló que Schnorr tiene ventajas de costos debido a la validación por lotes. Por ejemplo, calcular y verificar ocho firmas como un lote es más rentable que verificar ocho firmas individualmente. Luego señaló que Schnorr ayudará con la privacidad del usuario y es mejor para la propia red Bitcoin.

Aunque Sechet había implementado Schnorr hace poco más de un año, su código aún no se ha revisado a fondo. El desarrollador líder de Bitcoin ABC advirtió que el código tendría que revisarse más de lo habitual e implementarse con cuidado, de lo contrario, la red se volvería susceptible a ataques de canal lateral a través del predictor de ramificación de la CPU y a través de la jerarquía de caché de la CPU.

Después de la explicación de Sechet, Lunderberg acordó revisar el código del primero dentro de un mes y medio. Al darse cuenta de que todos los integrantes del grupo se habían estirado, Cox lanzó una invitación abierta a los criptógrafos y desarrolladores para ayudarles a desarrollar y revisar el código de Bitcoin Cash.

Como este punto, la mayoría de los desarrolladores en la reunión tenían sus platos llenos. En respuesta, Suisani explicó que contactaría a los otros desarrolladores de Bitcoin Unlimited para ver si estaban interesados en trabajar en los códigos de operación anteriores. Suisani explicó que los desarrolladores de Bitcoin Unlimited eran la elección lógica, ya que anteriormente habían incluido la implementación de Nchain en el cliente SV que producían.

Hacia el final de la reunión, Oldenburg mencionó que actualmente hay un límite de 25 cadenas de transacciones no confirmadas que está afectando a varios protocolos en este momento, que deben solucionarse. También mencionó que Bitcoin.com estaba trabajando actualmente en su propio juego de dados en cadena similar a Satoshidice. En respuesta, news.Bitcoin.com se acercó a Oldenburg para reflexionar sobre la reunión de desarrolladores. El CTO de Bitcoin.com fue positivo acerca de la reunión en general, especialmente porque «la limitación de las transacciones encadenadas no confirmadas se eliminará a largo plazo».

Fuente: Bitcoin.com 

Descargo de responsabilidad: InfoCoin no está afiliado con ninguna de las empresas mencionadas en este artículo y no es responsable de sus productos y/o servicios. Este comunicado de prensa es sólo para fines informativos, la información no constituye consejo de inversión o una oferta para invertir