https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html

https://twitter.com/kanzure/status/1136591286012698626

No hay mucho nuevo de que hablar. No está claro lo de CODESEPARATOR. Se quiere convertir en regla de consenso que las transacciones no pueden ser mayores de 100 kb. ¿No hay reacciones a eso? De acuerdo. Bien, lo haremos. Hagámoslo. ¿Todos saben cuál es esta propuesta?

El tiempo de validación para cualquier bloque, éramos perezosos a la hora de arreglar esto. Segwit fue un primer paso para arreglar esto, dando a la gente una manera de hacer esto de una manera más eficiente. Así que el objetivo de la gran limpieza consensuada es arreglar eso, y también arreglar el timewarp, lo sabemos desde hace mucho tiempo y deberíamos arreglarlo. Tres, deberíamos hacer un soft-fork que no es lo más crítico y por lo tanto puede ser bikeshedded un poco y si no se activa entonces nadie es demasiado triste. Podemos hacerlo por el mero hecho de hacer un soft-fork y sacar algo adelante y solucionar los problemas que puedan surgir, antes de hacer algo más complicado como las firmas Schnorr.

¿Existe el riesgo de normalizar los soft-forks? Tal vez, pero no es una frivolidad.

El soft-fork fix para timewarp es realmente simple. Me gustaría hacer ese pull request. ¿Cuál es la solución exactamente? El problema en timewarp es que hay un error en el cálculo de la altura para el ajuste de dificultad. Puedes saltar hacia atrás o hacia adelante significativamente, no estoy seguro, sólo en el cambio de bloque de ajuste de dificultad. Si sólo restringes esos dos bloques para que estén bien ordenados, entonces bien, el timewarp desaparece. Así que sólo tienes que añadir una nueva regla diciendo que estos bloques deben estar bien ordenados. Si estableces esa regla de tal manera que pueda ir hacia atrás hasta 2 horas, entonces no debería haber ningún impacto donde un minero genere tal bloque. La marca de tiempo no puede retroceder más de 7200 segundos.

Tener una regla entre los dos periodos de dificultad, y cualquier límite constante sobre cuánto puede retroceder el tiempo, arregla el ataque timewarp. En función de cuántos segundos se permite ir hacia atrás, hay un pequeño factor de aceleración de bloque que se puede lograr, pero siempre está limitado. Si se retrocede 600 segundos, el límite es exactamente el que queríamos, es decir, 2016 bloques cada 2 semanas. Si permites que retroceda más, permites un poco más de bloques. Si permites menos, curiosamente, tienes menos bloques.

¿Qué pasa con el uso de timewarp para bloques hacia adelante? Alguien preguntó acerca de hacer bloques hacia adelante en litecoin. Pero litecoin había fusionado una corrección de timewarp hace mucho tiempo.

¿Deberíamos corregir el error de timewarp? Slushpool ha dado su opinión. ¿Es sólo Mark quien quiere usarlo?

El mejor nrolling que tienes es generar un montón de midstates, e incrementar el temporizador en un segundo. Nadie hace n rolling en hardware todavía, pero la gente quiere hacerlo. Probablemente por eso la gente de slushpool estaba preocupada. La mediana del tiempo pasado podría estar en el pasado, y el bloque anterior podría estar 2 horas en el futuro, y por lo tanto estás más de 2 horas por detrás del bloque anterior. Por eso se permite retroceder 2 horas. La mediana del tiempo pasado puede estar en el pasado, y el bloque anterior puede estar 2 horas en el futuro. Si quisieras la mayor cantidad posible de n time rolling, empezarías con la mediana del tiempo pasado, y ahora mismo la gente empieza con el tiempo actual y realmente no hacen n time rolling. Básicamente no hay razón para n time roll significativamente en el futuro, siempre y cuando usted puede almacenar un montón de midstates por cada 1 segundo. Se podría argumentar que no hay razón para hacer esto, o no se puede hacer esto. No hay ninguna razón para hacer esto, y nadie lo está haciendo por lo que yo puedo decir.

La única evidencia que vimos de ntime rodando fue hasta tal vez 10 minutos o algo así, miramos. Los únicos tiempos que saltaron hacia atrás fueron probablemente otros problemas. ¿La gente mina bloques con marcas de tiempo en el pasado? Sí, pero eso es otra cosa. No, no lo es. Es trabajo antiguo. Sólo te actualizo cada 30 segundos. Alguien más puede joderte minando un bloque 2 horas en el futuro. Si empiezas en el momento actual y alguien mina un bloque 2 horas en el futuro, eso siempre está bien. Habrías rechazado un bloque más de 2 horas en el futuro. Cumplirás la regla. Sí minan en el pasado, pero empieza con la hora en la cabecera, pero lo encuentran más tarde en el futuro. ¿Nadie mina un bloque cuya marca de tiempo es más antigua que la hora real del bloque anterior? No, nadie lo hace. En el caso de los mineros, como stratum se actualiza periódicamente, casi todos los mineros minan con 15 segundos de retraso, ya que se actualizan cada 30 segundos, lo que supone una media de 15 segundos. Pero siempre se empieza con el tiempo actual cuando se genera el trabajo de stratum y se envía al cliente.

¿Cuánto varía la hora actual entre mineros? Unos pocos segundos. Harold rastreó la red bitcoin y encontró que el 90% de los nodos bitcoin que escuchan tienen una marca de tiempo que está dentro de la precisión de medición mía. Las personas sin un reloj preciso, están como 2 días fuera. Así que sí. Cuando te conectas, el mensaje de versión tiene la hora unix actual, la hora del sistema. Es la hora ajustada a la red, ¿eso creo? Eso sería infeccioso no. Anuncias la hora del sistema, pero usas la hora ajustada a la red. Tus datos de rastreo siguen siendo útiles porque te dicen la hora ajustada a la red. Los servidores de pool probablemente hacen lo suyo.

¿Tienen actualmente bfgminer o cgminer algún código para rechazar que su pool les diga que participen en un timewarp basándose en cabeceras anteriores? Los clientes no hacen nada, ni deberían hacerlo. Un ASIC no debería interpretar datos basándose en reglas de consenso. Es estúpido. bfgminer hace algunas locuras, pero eso es porque bfgminer es una locura. En general quieres que el minero sea tan tonto como un ladrillo, ellos solo tiran el trabajo a un ASIC. Ahora mismo son demasiado listos para su propio bien porque ven la transacción de coinbase.

Así que te arrastraste nodo veces, pero ¿te fijaste en los tiempos de la piscina? No, no llegué a hacerlo. Sólo miraba la red bitcoin y comparaba su reloj con mi reloj local. Casi todos los pools tienen un nodo bitcoin escuchando en la misma dirección IP, lo cual es raro. Pero para aquellos que no, tienen una piscina, y luego un nodo en el mismo rack o centro de datos que ejecuta un nodo bitcoin y luego tal vez un nodo bitcoin interno que no está escuchando. En general, los relojes parecen estar dentro de un segundo, que es más o menos lo que cabría esperar de NTP más o menos unos segundos. Un montón de gente tiene una hora de diferencia. Probablemente sea un error de zona horaria. Buggy horario de verano, probablemente. Y Windows configurando la hora local en lugar de UTC. Hay una zona horaria de 15 minutos. Corea del Norte tiene el peor huso horario de la historia. Bueno, eso es porque no se preocupan por el resto del mundo.

Hay un montón de reglas, incluyendo las transacciones de 64 bytes que afecta principalmente a las transacciones segwit. Sí, eso es otra cosa. Lo de codesep solo esta pensado para transacciones no segwit pero tal vez lo dejemos en favor de una regla de 100k. Pero, ¿la regla de los 100.000 es sólo para el legado? No he pensado en eso. Debería ser 100k tamaño base. Podrías decir simplemente 100k tamaño base, y entonces se aplica a segwit también. O 400k testigo, en realidad. 100k tamaño de la tira, es lo que quieres, ¿verdad? El tamaño base es un lenguaje raro para mi. Testigo tamaño de la tira, no más de 100kb debe ser la propuesta. Eso es lo unico que importa para las reglas de sighashing. Pero tambien podrias hacerlo por el peso del testigo porque asi es como calculamos el tamaño ahora. Tienes razón, si quieres atacar la cosa exacta que está causando problemas, lo harías por.... no queremos hacerlo a la otra cosa porque si tienes un testigo gigante. ¿Queremos testigos de más de 400 kb?

¿Estás proponiendo esto como el próximo soft-fork, o estás argumentando que esto debería ser el próximo soft-fork? Teniendo en cuenta dónde estamos con taproot, parece posible que intentar hacer algo antes sólo lo retrasaría aún más. Bueno, se pretendía que fuera más rápido, pero nadie lo revisó ni le importó una mierda, así que da igual. Es completamente ortogonal. Podría hacerse en paralelo, no hay nada malo en ello. Además, si existe un acuerdo comunitario, no hay razón por la que no puedan activarse al mismo tiempo.

Estos vectores DoS, el error timewarp y las cosas sighash- ¿cuánto tiempo tendríamos para desplegar un soft-fork como este y tenerlo listo? Si algo malo sucede... hemos visto cosas malas suceder, hemos visto bloques que tardan demasiado en validarse. Ha sido explotado antes. Timewarp es una pregunta diferente. ¿Podemos lidiar con el Timewarp cuando suceda? No, de repente aparece un bloque timewarp y entonces sabemos que ha ocurrido. Explotar el timewarp es un proceso muy lento. Es en varios meses, así que podríamos optar por desplegar el soft-fork entonces. Si el timewarp está ocurriendo es porque los mineros lo están haciendo, a quienes necesitas para la activación del soft-fork en ese caso. Para sighashes, es necesario configurar 100's de miles de UTXOs y podemos ver que en particular. Pero la limpieza de polvo estilo f2pool no es realmente tan malo, pero es bastante desagradable. Gran tamaño de scriptpubkey, 10 kb scriptpubkeys o algo así.

Si quieres hacer algo no controvertido y fácil de hacer un soft-fork, entonces creo que un límite de tamaño de 100kb lo hará muy controvertido. Cualquier tipo de límite de tamaño en las transacciones espero que sea controvertido. Lleva siendo no estándar desde hace 5-7 años. ¿Interferiría esto con las transacciones confidenciales? Bueno, podría decirse que no debería afectar a los datos de testigos. No se aplicaría a eso de todos modos.

¿Qué pasa con la gran transacción gigante por bloque, transacción gigante coinjoin con Schnorr? Si usted tiene un nuevo esquema de firma, y y y estas otras cosas, entonces tal vez. El nuevo tipo de sighash en segwit generalmente previene esto, así que podrías decir sólo no testigo... sólo los datos que son relevantes para las entradas no testigo, que mayormente corresponde al tamaño de la tira testigo. Sólo entonces se comprueba si es más de 100kb y si lo es, entonces usted falla. Quieres poder hacerlo sin validar los scripts. Contar el número de entradas heredadas y ponerle un límite. Puedes buscar los UTXOs, pero no tienes que validarlos. Un segundo tipo de testigo que se añade ... usted no estaría contando que, por lo que es un poco peligroso, si predecimos que.

Otro comentario, realmente necesitas números para mostrar a la gente que este cambio reduce el peor de los casos. Sí, tengo cifras. Tener esos números sería genial para convencer a la gente. Aún no me he puesto a reescribirlo. A nadie parece importarle.

Como no se ha violado la regla del timewarp, puede que nadie actualice- ¿cómo se sabe? Bueno, si minan bloques inválidos entonces no será aceptado por la red. Usted no tiene la seguridad, excepto que todo el mundo está ejecutando Bitcoin Core. Si empiezas a perder dinero, vas a arreglar tu mierda muy rápido.

El BIP dice usar bip9 versionbits con una promesa explícita de que si los nodos y el ecosistema parecen actualizarse robustamente, y bip9 se agota, entonces habrá una segunda ventana de señalización de bip9 en una futura versión donde esa ventana de señalización de bip9 se agota con una activación en lugar de un tiempo de espera. Con la señalización de bip9. Sí, eso es bip8. Así que sí, primero no lo hagas explícitamente activar, sólo ver que todo el mundo lo quiere, entonces usted podría ver la activación y ver en la red y todavía hay- todavía queremos usar bip9 pero usted tiene que cumplir con nosotros allí, de lo contrario bip8 y la zanahoria y el palo. Cliente podría tener una opción para que en la versión actual wihtout actualización para agregar los nuevos parámetros de señalización. Eso es una locura. Entonces podría haber gente demasiado impaciente para bip9 tiempo de espera ... consenso archivo de configuración no es el camino correcto a seguir.

No quiero entrar en una discusión sobre la UASF. Es mejor tener un enfoque conservador y lento para asegurarnos de que realmente tenemos consenso para estos cambios. ¿Por qué tanta prisa? ¿Habrá alguna resistencia a un tenedor blando? Creo que esto no es lo suficientemente simple. Lo del separador de código se va a eliminar de la propuesta. Todavía hay muchos detalles sin definir. Es una buena idea. Si no tuviéramos taproot potencialmente listo también cerrar... ten cuidado con cómo lo expresas. ¿Cuál es el razonamiento para arreglar múltiples vulnerabilidades en lugar de sólo una? Hay un montón de sobrecarga para hacer un soft-fork, y un soft-fork sólo para eliminar las transacciones de 64 bytes no creo que siente precedente sobre cómo ocurren los soft-forks. No deberíamos sentar un precedente de hacer un soft-fork cada 6 meses. Sí, hay sobrecarga y el riesgo de soft-fork. Si usted tiene un montón de cosas no controvertidas, entonces seguro que es útil para agruparlos. También estos tienen que ser super simple. Matt tiene algunas cosas que son bastante sencillas, y tienen que ser adecuadamente socializadas para decirle a la gente por qué es importante. Bueno, queremos evitar los soft-forks omnibus. No es que esto está sucediendo aquí. Hay un equilibrio, por supuesto.

Debe ser incontrovertible y sencillo, lo que hará que vaya más rápido. Pero también hay que estar muy motivado, lo que hace que vaya más rápido o más suave. Creo que este es un argumento a favor del taproot. Creo que eso se ha socializado durante mucho más tiempo. Creo que la gente entiende podría ser una palabra fuerte, entienden que hay un beneficio para ellos por esto, mientras que estas cosas pueden ser menos claras. Habrá drama en torno al método de activación. La comunidad de twitter son todos los imbéciles de la UASF.

¿No os gusta el bip8? Hacer bip8 desde el principio es una mierda. Es como decir que los desarrolladores de Bitcoin Core han tomado la decisión. Necesitas hacerlo real para la gente, antes de saber que hay consenso. Esto es lo que permite bip9. Creo que se lanza con bip9, y entonces debería ser probable ver la adopción de los nodos, los mineros podrían ser lentos, pero ¿quién va a oponerse a ello?

Si vamos a tirar mano de obra en algo, ¿por qué no algo como taproot? Bueno, tienes que arreglar estas vulnerabilidades reales en algún momento. Es una cuestión de secuenciación y de cuándo hacerlo. Esto podría ser cierto si hacemos un buen trabajo motivando esto y explicándoselo a la gente.

Yo haría una ventana bip9 superlarga. Si ocurre antes de taproot es genial, si ocurre después de taproot está bien. Diríamos que nos gustaría que esto saliera, pero no es urgente. No queremos sentar un precedente para establecer dos horquillas blandas porque si se actualiza se obtiene... empezamos con una, y más tarde hacemos la de taproot. Tienen que estar separados un año o lo que sea. Creo que esta discusión es prematura hasta que tengamos una idea clara de si el ecosistema quiere estos cambios. Se puede hablar de mecanismos de activación en abstracto, claro.

Los BIP de taproot son relativamente nuevos. Yo trataría de argumentar que no se tiene una imagen clara de ello hasta que se escriben los pull requests y se empieza a escribir código y a fusionar y es entonces cuando se consigue que la gente entienda que esto es real. Revisar, publicar y fusionar el código es independiente de la decisión de añadir un mecanismo de activación. ¿No necesitas al menos un plan? Supongo que puedes cambiar el mecanismo de activación va a ser.

Me gustaría ver más código para el soft-fork de limpieza. Sí, hay un parche y un pull request. Sólo estaba en un blob. No, hay pruebas y todo. El código es bastante legible. La última vez que miré no parecía separado. Fanquake, necesita ser etiquetado como «necesita acción del autor». Tiene 5 commits, lo estoy mirando ahora mismo.

También podría tirar de un Satoshi y hacer un commit «change makefile» ((risas)).

Hay un pool de mineros censurando transacciones blindadas para zcash. Los mineros de Bitcoin Cash ya han activado un fork para firmas Schnorr así que al menos hay algo de interés ahí.

Hacer un mecanismo de señalización bip9, hacer un lanzamiento con él, realmente publicitarlo. El potencial de controversia es mayor con la gran limpieza de consenso porque está más cerca de bikeshed. Pero Schnorr-Taproot es Pieter trayendo las tabletas de la montaña ((risas; nadie quiere eso)).

¿Y si dividimos la gran limpieza de consenso? Sobrevaloras cuánto sigue la gente cualquiera de estas cosas. En general, no lo hacen. ¿Qué tendría de terrible tener múltiples soft-forks? Bueno, se convierte en 32 combinaciones para probar. Pesadillas de activación parcial.

No creo que estas bifurcaciones suaves puedan hacerse en paralelo. No somos buenos gestionando las expectativas sociales en este proyecto ni comunicándolas de forma adecuada. Si intentamos hacer esto para dos cosas, creo que lo haremos aún peor. Creo que es mejor centrarnos en una cosa, centrarnos en cómo la estamos comunicando, cómo estamos señalando que hay consenso sobre esto primero antes de lanzarlo por ahí. Si estamos haciendo dos bifurcaciones suaves, va a ser confuso para nosotros si cada una de ellas tiene consenso o lo que sea, olvídate de cómo lo perciben los demás. Ninguno de los problemas del gran tenedor blando de limpieza es especialmente sexy, así que te costará motivar e interesar a alguien. Pero si tienes números, entonces tal vez. No sé cuánto priorizar esto porque no sé cuáles son los números. Es raro decir «es difícil de justificar, así que deberíamos hacerlo». No digo que sea difícil de justificar, simplemente no es sexy. Socialmente sería difícil conseguir que se desplegara la corrección de errores del soft-fork OP_CHECKMULTISIG, porque es sólo un byte y a la mayoría de la gente no le importa. Bueno, no hemos intentado entusiasmar a la gente. Es difícil incluso para mí esto es importante, simplemente no es un tema emocionante. Si este grupo no está superexcitado al respecto, entonces ¿cómo podría el mundo entusiasmarse? Ni siquiera puedo recordar el tema completo y lo escribí.

Es significativamente menos emocionante que la taproot, y podría ayudar a construir una comprensión de los soft-forks en el futuro, y luego haces algo que es más probable que resulte en drama. Este tenedor suave no tiene ningún beneficio directo por lo que es más fácil argumentar en contra de ella. Bueno, ni siquiera tenemos los números de rendimiento.

Si quieres el consentimiento de la comunidad para estos cambios, que es lo que necesitas para hacer los cambios, entonces a pesar de lo nuevo que es el taproot, la idea general ha sido socializada durante tanto tiempo que estamos en un buen lugar para avanzar, especialmente porque lleva mucho tiempo de todos modos. Pero estas ideas de limpieza no han sido socializadas, y empaquetarlas en algo como esto es reciente. Si dejáramos la limpieza por ahí durante un tiempo y señaláramos que como grupo pensamos que esto es algo que deberíamos hacer, que probablemente sea lo siguiente que hagamos después del taproot, entonces la gente lo esperaría. Ahora esperan Schnorr, y deberían esperar estas limpiezas. Si hay una oposición decidida a esos cambios, tendremos tiempo de ver cuáles son esos argumentos.

Sabemos que en el peor de los casos el rendimiento es malo, pero lo que no sabemos es cuánto mejoraría las cosas el soft-fork de limpieza, como los ataques de validación. ¿Qué pasa si esto fue explotado, y le decimos a la gente ah bueno, sabíamos de la vulnerabilidad y simplemente no hicimos nada al respecto. Timewarp ha sido bien documentado desde hace 8 años. Teóricamente es posible que alguien construya un bloque que tarde mucho tiempo en validarse y eso tenga repercusiones negativas. ¿Será un bloque, muchos bloques? ¿Qué probabilidades hay de que esto ocurra realmente? Para ser justos, se ha documentado durante años y la mayoría de las altcoins lo han solucionado. Bitcoin puede que nunca lo haga porque es un hard-fork solía ser el viejo argumento. Creo que al principio la gente pensaba que era un hard-fork, pero hace tiempo que ya no es así.

Hubo un gran ataque timewarp en 2013 contra una altcoin que no solucionó la vulnerabilidad timewarp. También hubo uno reciente, el de dos pruebas de trabajo y un ataque de timewarp.

En cuanto al orden de activación, creo que podría ser razonable porque es un patrón común al que la gente está acostumbrada, sugerir quizás hacer un tenedor de características, un tenedor de limpieza. Esto podría preparar a la gente de una manera sin tantos inconvenientes. Me gusta eso, y la sugerencia de socializarlo, que aún no ha sucedido. Hemos estado socializando la eliminación de CODESEPARATOR durante unos 4 años. En una reunión de desarrolladores en SF hace unos meses, CODESEPARATOR era nuevo para ellos. No hubo discusión sobre el arreglo del timewarp allí, pero sobre CODESEPARATOR y los modos sighash creo- ¿cuáles eran las tres cosas? 64 bytes, separador de códigos, requisito de pushdata, sólo scriptsig push. Creo que el 80% de la discusión fue sobre OP_CODESEPARATOR. Si eso es alguna indicación; pero podría ser el comportamiento de la multitud al azar. Creo que esa es la indicación correcta, creo. Es difícil entender la utilidad de OP_CODESEPARATOR, y mucha gente cree haber encontrado un caso de uso, pero casi nunca funciona para nadie. No es que sea útil, sino que alguien podría pensar que es útil y por lo tanto podría bloquear sus fondos permanentemente, lo que hace esta discusión aún más difícil. Usted podría conseguir alrededor de esto con bien cualquier transacción creada antes de este tiempo y después de este tiempo, y entonces usted tiene problemas del contexto...

Además, en cuanto al límite de transacciones de 100kb, hay que discutir sobre el establecimiento de precedencias. Ignorando OP_CODESEPARATOR por un momento, ¿qué haces si quieres eliminar algo así? Resulta que es una vulnerabilidad importante, pero algunas personas podrían tener fondos bloqueados con ella, así que ¿qué haces al respecto? No hemos hecho mucho con limpiezas de softforks o softforks de corrección de vulnerabilidades, así que ¿cómo sientas precedente para eliminar algo así? Yo era partidario de hacer algo como, desde la activación del soft-fork ahora son 5 años antes de la activación. O sólo se aplica a UTXOs creados después de la fecha de activación. También soy fan de activarlo para todos los UTXOs creados después del soft-fork, y luego 5 años después lo activamos para todos los UTXOs antiguos antes de que se activara el soft-fork.

Probablemente va a caer el cambio OP_CODESEPARATOR. Resulta que no es.... hay algunas clases de transacciones donde es realmente molesto para el uso total de datos hash, pero si quieres maximizar el uso total de datos hash, no es realmente lo inmediatamente peor, no es la forma en que realmente lo harías, especialmente si añades un límite de transacción de 100 kb. Tengo un documento de texto donde escribí todo esto, ha pasado un tiempo.

¿Alguien cree firmemente que esto debería desplegarse antes que el soft-fork taproot? Depende de la activación. La pregunta que más me interesa, ¿es una buena idea o no? Siento que esa pregunta no ha sido respondida. Si el soft-fork es útil, deberíamos hacerlo. ¿A alguien no le gusta la idea de hacer estas limpiezas? Depende de cuánto mejore la situación. Transacciones de 64 bytes, ¿no quieres hacer soft-fork? Definitivamente quiero eliminar las transacciones de 64 bytes. También quiero arreglar el timewarp. Tenemos que aclarar más las cosas, obtener algunas cifras y luego dejar que se asimilen. También tenemos que encontrar la manera de comunicar estas cosas a la comunidad Bitcoin. ¿Quién va a defender esto ante la comunidad? Puede que estemos sobrestimando cuánto les importa esto a los usuarios; ¿por qué no lo hemos arreglado antes? La forma de hacerlo es ponerle una marca, llamarlo time bleed ((risas; no hagas eso)). Timewarp es una marca bastante buena, excepto que suena guay o bueno.