Monero

Monero Research Lab Meeting – Wed 02 February 2022 @ 17:00 UTC #657

MRL 657

Cuando: 26 de Enero de 2022

Donde: Libera.chat, #monero-research-lab | Matrix

Artículo original: https://github.com/monero-project/meta/issues/657

Reunión anterior: https://satoshilov.com/mrl-654/

MRL Historial de Conversación:

[02-02-2022 17:00:44] <UkoeHB> hora de la reunión: https://github.com/monero-project/meta/issues/657
[02-02-2022 17:00:45] <UkoeHB> 1. saludos
[02-02-2022 17:00:45] <UkoeHB> hola
[02-02-2022 17:00:49] <ArticMine> Hola
[02-02-2022 17:00:55] <selsta> hola
[02-02-2022 17:00:58] <rbrunner> Hola
[02-02-2022 17:01:55] <netrik182> hola
[02-02-2022 17:02:09] <jberman[m]> hola
[02-02-2022 17:02:12] <Rucknium[m]> Hola
[02-02-2022 17:02:37] <carrington[m]> Saludos
[02-02-2022 17:02:44] <mj-xmr[m]> Buenos
[02-02-2022 17:02:55] <Escala> días.
[02-02-2022 17:03:42] <UkoeHB> Hoy deberíamos centrarnos en los cambios de tarifas para el próximo hardfork (y también mirar hacia el futuro). He resumido dos inquietudes aquí: https://github.com/monero-project/research-lab/issues/70#issuecomment-1024964432
[02-02-2022 17:05:01] <UkoeHB> Parece que ArticMine acordó reducir el factor de escalado a largo plazo de 1,4x -> 2x a 1,4x -> 1,7x (esto es el crecimiento máximo durante 69 días).
[02-02-2022 17:05:17] <ArticMine> Sí, eso es correcto https://github.com/monero-project/research-lab/issues/70#issuecomment-1025334284
[02-02-2022 17:05:19] <UkoeHB> reducir el próximo cambio*
[02-02-2022 17:05:46] <ArticMine> sgp valora 1,7 como compromiso
[02-02-2022 17:06:48] <ArticMine> Entonces podemos encontrar un consenso para el posterior HF
[02-02-2022 17:07:06] <UkoeHB> Sí, creo que está bien.
[02-02-2022 17:07:32] <carrington[m]> En general, creo que 1,7 es un compromiso decente para la tasa de crecimiento, pero creo que el límite de control de seguridad en el tamaño de los bloques debe ser reducido a algo con una base en la realidad (como jberman calculado)
[02-02-2022 17:07:56] <carrington[m]> También las tasas deberían ser más altas en general
[02-02-2022 17:09:00] <ArticMine> <carrington[m]> En general, creo que 1,7 es un compromiso decente para la tasa de crecimiento, pero creo que el límite de control de seguridad en el tamaño de los bloques debe ser reducido a algo con una base en la realidad (como jberman calculó) <--- hay maneras de tratar con esto sin codificar la obsolescencia en el consenso 
[02-02-2022 17:09:18] <UkoeHB> ArticMine: ¿cuál es tu respuesta a la preocupación de estabilidad que planteé?
[02-02-2022 17:11:07] <ArticMine> Hay muchas maneras de lidiar con esto, incluyendo la fijación de precios del ancho de banda de los nodos. Esto no requiere consenso 
[02-02-2022 17:11:33] <jberman[m]> Hay un punto en el que no se puede resolver retroactivamente una cadena que ha crecido demasiado para verificarla y sincronizarla en un hardware básico, que imo es la única manera de llevar a la obsolescencia
[02-02-2022 17:11:35] <Rucknium[m]> ¿Todavía no tenemos una estimación del coste de un incidente de spam deliberado de hinchamiento de la cadena de bloques?
[02-02-2022 17:12:06] <carrington[m]> Sí, a largo plazo los nodos "se ponen al día" no serían un problema si tuviéramos algún tipo de historial desechable, pero por ahora considerando que ya hay una comprobación de cordura codificada creo que ajustarla no es un problema permanente
[02-02-2022 17:12:11] <UkoeHB> sí que hace falta (yo podría hacerlo, pero estoy ocupado con seraphis... ¿alguien se apunta?)
[02-02-2022 17:13:39] <jberman[m]> yo puedo encargarme si no hay más interesados, parece que es la prioridad nº 1 para el fork en este momento + de todas formas estoy estudiando más a fondo los cambios de tarifas en este momento
[02-02-2022 17:14:07] <ArticMine> El coste de spam es algo que estoy dispuesto a hacer, pero no de manera forzada antes del próximo HF
[02-02-2022 17:14:18] <ArticMine> Este es el punto del compromiso
[02-02-2022 17:14:36] <UkoeHB> ArticMine: sí, hay formas de mejorar el rendimiento de los nodos. Sin embargo, esos métodos no son una "solución", son sólo una "tirita" al problema principal. El problema principal es el crecimiento ilimitado del tamaño de los bloques, que no puede ser soportado por los usuarios comunes (en algún momento sólo los centros de servidores podrían manejar la carga).
[02-02-2022 17:14:48] <carrington[m]> ¿Qué quieres decir con "poner precio a la velocidad de carga de los nodos"?
[02-02-2022 17:15:21] <ArticMine> Priorizar las transacciones para la retransmisión en función de la tarifa
[02-02-2022 17:15:43] <rbrunner> ¿También conocido como mercado de tarifas?
[02-02-2022 17:15:44] <ArticMine> manteniendo constante el número de nodos de transmisión
[02-02-2022 17:16:14] <ArticMine> Para los nodos de bajo ancho de banda, esto crea efectivamente un mercado de tarifas
[02-02-2022 17:16:43] <UkoeHB> ¿Qué hace un nodo de bajo ancho de banda si recibe un gran bloque válido de un pool de minería?
[02-02-2022 17:16:51] <UkoeHB> ¿Simplemente se queda atrás y bueno?
[02-02-2022 17:16:56] <ArticMine> Ten en cuenta que muchas conexiones de internet pueden tener una diferencia de 30x en el ancho de banda de subida y bajada
[02-02-2022 17:17:26] <ArticMine> y un nodo de Monero necesita fácilmente 12 veces más ancho de banda de subida que de bajada
[02-02-2022 17:17:39] <jberman[m]> El ancho de banda no es el problema en mis cálculos: https://github.com/monero-project/research-lab/issues/70#issuecomment-1027806393
[02-02-2022 17:18:32] <jberman[m]> incluso si asumes un ancho de banda de coste 0 (es decir, infinitos mb/s de subida y bajada), el tiempo de verificación + los requisitos de almacenamiento para ejecutar un nodo podado que verifique la cadena acabaría siendo demasiado grande 
[02-02-2022 17:18:51] <ArticMine> ^ Tengo serias dudas sobre eso. La verificación por lotes es algo que se puede ejecutar en paralelo
[02-02-2022 17:18:53] <LyzaL> el tiempo de propogación de los bloques aumenta los huerfanos no? El tiempo de carga de los bloques de 5 a 10 segundos no parece muy grande, incluso si hay otros requisitos de hardware - ¿cuánto tiempo tarda un bloque en propogarse completamente en esta situación?
[02-02-2022 17:19:20] <carrington[m]> Creo que el problema es la verificación más que el ancho de banda.
[02-02-2022 17:19:21] <UkoeHB> ArticMine: esto es un problema tanto teórico como numérico.
[02-02-2022 17:19:22] <jberman[m]> el tiempo de verificación se divide entre 8, el número de hilos de mi máquina. el paralelismo se tiene en cuenta
[02-02-2022 17:19:24] <ArticMine> Hay una solucion aqui que no involucra hard caps
[02-02-2022 17:19:42] <Rucknium[m]> Puedo revisar el trabajo de jberman y/o trabajar con él en la estimación del coste de spam. 
[02-02-2022 17:20:47] <UkoeHB> LyzaL: ese es un buen punto, ya que dandelion++ aumenta el tiempo de propagación
[02-02-2022 17:20:51] <ArticMine> No veo el argumento para correr la verificación en un solo hilo si hay muchas txs
[02-02-2022 17:21:38] <rbrunner> Me pregunto qué tan alto nos gustaría ver las tarifas para escenarios extremos como para sentirse seguro. Incluso con 10s de miles de USD todavía podría temer un enemigo dedicado con bolsillos profundos.
[02-02-2022 17:21:42] <ArticMine> Si la tasa de huérfanos aumenta entonces los mineros requerirán una tasa más alta. Hay una investigación existente sobre el fpor Bitcoin / Bitcoin cash
[02-02-2022 17:21:45] <jberman[m]> los números no asumen que la verificación se ejecuta en un solo hilo
[02-02-2022 17:22:07] <ArticMine> ^ Es crítico aclarar esto
[02-02-2022 17:22:12] <ArticMine> aclarar
[02-02-2022 17:22:49] <carrington[m]> Por un lado, las soluciones contra un ataque de big bang en el número 70 ya dependen de la capacidad de la comunidad para reaccionar dentro del marco temporal de la ventana de largo plazo
[02-02-2022 17:22:50] <ArticMine> UkoeHB fue muy claro en la simulación sobre esto
[02-02-2022 17:22:52] <UkoeHB> sólo es crítico cuando se está definiendo un número hardcodeado... es irrelevante para mis objeciones teóricas que están siendo ignoradas
[02-02-2022 17:23:37] <jberman[m]> las tasas de huerfanos aumentarían como consecuencia de los bloques más grandes
[02-02-2022 17:23:55] <carrington[m]> Así que en cierto sentido estamos eligiendo entre hornear la obsolescencia y hornear las actualizaciones centralizadas
[02-02-2022 17:24:22] <UkoeHB> ¿a qué te refieres con reaccionar? iirc esos comentarios no tuvieron en cuenta ArticMine y mis análisis
[02-02-2022 17:24:36] <rbrunner> ¿No es la "obsolencia" un poco dura para un límite máximo duro en el número de transacción?
[02-02-2022 17:24:37] <LyzaL> personalmente soy partidario de un ritmo de crecimiento conservador, tener un mercado de honorarios durante unos meses en un periodo de gran crecimiento no es el fin del mundo, pero la centralización masiva sí
[02-02-2022 17:24:50] <carrington[m]> rbrunner: mi opinión es que los ataques de spam deberían costar lo mismo que los ataques del 51% para tener garantías de seguridad equivalentes
[02-02-2022 17:24:59] <LyzaL> también L2 parece posible en algún momento
[02-02-2022 17:25:06] <ArticMine> No lo es. Bitcoin es un ejemplo claro 
[02-02-2022 17:25:24] <ArticMine> Bandwith ha aumentado 200x en el bloque gensis de Bitcoin
[02-02-2022 17:25:37] <ArticMine> mientras la gente sigue con el debate sobre el tamaño del bloque
[02-02-2022 17:26:10] <rbrunner> Entonces, ¿por qué no tener límites que suban en mayor o menor medida junto con la evolución de la tecnología?
[02-02-2022 17:26:12] <UkoeHB> Bitcoin no tiene bloques enormes y caros...
[02-02-2022 17:26:33] <ArticMine> He posteado en el hilo orginat BCT que se inició en 2010 sobre el aumento del tamaño de los bloques
[02-02-2022 17:27:04] <ArticMine> <rbrunner> Entonces, ¿por qué no tener límites que suban en mayor o menor medida junto con la evolución de la tecnología? <--- Bingo Eso es en lo que quiero trabajar para el próximo HF
[02-02-2022 17:27:34] <ArticMine> Por eso 1.7 es un compromiso razonable
[02-02-2022 17:27:44] <carrington[m]> Para mi comentario sobre "reaccionar" mira los comentarios de Artic en el 70 sobre "ataques recientes a la red"
[02-02-2022 17:28:16] <LyzaL> a mis ojos incluso el 1,4 parece una tasa de crecimiento masiva
[02-02-2022 17:29:15] <ArticMine> A largo plazo si, en un periodo de 2 a 5 meses no
[02-02-2022 17:31:32] <jberman[m]> Si confiamos en el hecho de que podemos adaptarnos y reaccionar y cambiar el protocolo en caso de circunstancias imprevistas, ¿por qué no apostar por mantener el ritmo de crecimiento más conservador que tiene ahora y reaccionar en la dirección que permita un mayor crecimiento, en la posibilidad de que no encontremos un acuerdo y el largo plazo se nos escape?
[02-02-2022 17:32:21] <rbrunner> Porque quizás eso se sienta un poco como una derrota :)
[02-02-2022 17:32:40] <ArticMine> Porque se puede controlar el crecimiento de muchas maneras
[02-02-2022 17:32:49] <ArticMine> si hay un problema
[02-02-2022 17:32:56] <rbrunner> Más un problema psicológico que técnico...
[02-02-2022 17:33:31] <ArticMine> ^ Estoy de acuerdo y Bitcoin es el ejemplo por excelencia
[02-02-2022 17:34:34] <carrington[m]> para mi tiene sentido jberman , una tasa de crecimiento conservadora no es nada como bloquear las cosas a topes fijos durante una década
[02-02-2022 17:35:37] <ArticMine> Tenemos un compromiso. No voy a volver a pedir el 2 pero no voy a apoyar menos de 1,7 1,7 ha estado sobre la mesa durante más de un año
[02-02-2022 17:36:07] <ArticMine> Este es el promlem psicológico crítico 
[02-02-2022 17:36:24] <merope> Quizás una pregunta tonta: ¿por qué el crecimiento tiene que ser exponencial? ¿Por qué no lineal?
[02-02-2022 17:37:04] <LyzaL> o logarítmico
[02-02-2022 17:37:40] <UkoeHB> bastante seguro de que el cambio de adopción es proporcional a la adopción existente
[02-02-2022 17:37:58] <ArticMine> en las etapas iniciales sí
[02-02-2022 17:41:17] <rbrunner> "no apoyaré menos de 1,7" ¿Cómo podría verse eso a la luz de un posible resultado de costos sorprendentemente bajos - todavía, después de la subida de tasas - para los ataques de spam?
[02-02-2022 17:41:36] <rbrunner> Sólo hipotéticamente, no lo sabemos todavía después de todo
[02-02-2022 17:41:52] <ArticMine> porque esto se ha discutido hasta la muerte
[02-02-2022 17:42:00] <Rucknium[m]> Creo que es una buena idea leer unos cuantos mensajes en el hilo de la primera sugerencia de aumentar el tamaño de los bloques de bitcoin. 
[02-02-2022 17:42:00] <Rucknium[m]> https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366
[02-02-2022 17:42:00] <Rucknium[m]> "Si actualizamos ahora, no tendremos que convencer a tanta gente después si la economía de bitcoin sigue creciendo."
[02-02-2022 17:42:27] <Rucknium[m]> merope: Eso es más o menos lo que yo pienso también. Las formas funcionales que se están eligiendo son una especie de forzarnos a un espacio que tal vez no queremos ser. Pero si cambiáramos las formas funcionales, tendríamos que reformular muchas cosas.
[02-02-2022 17:43:01] <ArticMine> Mis opiniones en ese hilo siguen siendo válidas 
[02-02-2022 17:43:19] <ArticMine> Es la razón por la que abandoné Bitcoin en 2015
[02-02-2022 17:43:44] <ArticMine> y el resto es historia
[02-02-2022 17:44:00] <rbrunner> Sí, pero vamos, incluso con 1,1 en lugar de 1,7 o lo que sea somos mucho mejores que Bitcoin. ¿Es esa una comparación justa?
[02-02-2022 17:44:41] <ArticMine> Sí lo es
[02-02-2022 17:44:50] <ArticMine> mira la historia de Bitcoin
[02-02-2022 17:44:54] <ArticMine> historia
[02-02-2022 17:45:37] <ArticMine> 1.7 estuvo en la tabla durante un año
[02-02-2022 17:45:52] <ArticMine> tabla
[02-02-2022 17:45:57] <carrington[m]> No es una comparación justa, sobre todo viendo que Monero en general se sigue actualizando regularmente
[02-02-2022 17:46:12] <ArticMine> También lo es Bitcoin
[02-02-2022 17:46:12] <rbrunner> Te entiendo, pero ¿cómo puede esto ayudarnos ahora a llegar a un "consenso suelto" y seguir adelante con el HF?
[02-02-2022 17:46:39] <ArticMine> Yo pensaba que teníamos consenso en 1.7 hasta esta mañana
[02-02-2022 17:46:49] <rbrunner> Parece que ahora estamos en algo parecido a un punto muerto, si quieres ser tremendamente honesto
[02-02-2022 17:47:14] <ErCiccione> ¿No tenemos que hacer 2 hard forks de todas formas? Quizás mejor ser conservador para esta y en caso de aumento en la siguiente? ¿Tiene sentido?
[02-02-2022 17:47:34] <ArticMine> No
[02-02-2022 17:47:56] <rbrunner> Bueno, hace 7 horas jberman descubrió que incluso 1,4 puede ir a 4,5 TB por año, en el peor de los casos ...
[02-02-2022 17:48:03] <ErCiccione> me refiero al segundo hard para seraphis
[02-02-2022 17:48:09] <ArticMine> Hubo un trabajo crítico que se hizo en un período de dos años 
[02-02-2022 17:48:18] <ErCiccione> pero si no tiene sentido se callará 🙂 .
[02-02-2022 17:48:37] <UkoeHB> ErCiccione: seraphis puede ser 3 hardforks en el futuro, si tarda lo suficiente. El siguiente hardfork después de este es probable que sea muy pequeño (si es que lo tenemos).
[02-02-2022 17:49:34] <UkoeHB> ArticMine: podría ayudar si publicas tu investigación numérica para que la examinemos. Tu presentación de "necesitamos 2x" sólo estaba respaldada por un par de párrafos.
[02-02-2022 17:50:02] <ArticMine> No estoy convencido de que sirva de algo
[02-02-2022 17:50:20] <ArticMine> No he recibido ninguna respuesta a mis comentarios sobre el 70 hasta el último minuto
[02-02-2022 17:50:24] <ArticMine> 'las
[02-02-2022 17:50:29] <ArticMine> último
[02-02-2022 17:51:04] <ArticMine> Mira la fecha del post en el número 70
[02-02-2022 17:51:17] <ArticMine> Hubo tiempo suficiente para hacer preguntas, etc.
[02-02-2022 17:51:45] <carrington[m]> El escenario de hinchamiento máximo es poco probable, según la OMI, por la forma en que funciona la penalización. Una tasa de crecimiento de "velocidad media" probablemente proporcionará números más útiles para un determinado "crecimiento máximo anual"
[02-02-2022 17:51:53] <UkoeHB> ok claro, pero estamos hablando de ello ahora... más vale tarde que nunca
[02-02-2022 17:53:17] <ArticMine> Para kii toda la propuesta
[02-02-2022 17:53:18] <UkoeHB> Personalmente no tengo mucho interés en el número elegido, pero estaría bien desde un punto de vista de ingeniería entender el argumento con más precisión. Ahora mismo parece que hay mucha imprecisión
[02-02-2022 17:54:23] <rbrunner> Me parece que eso es casi un hecho, porque se puede trabajar fácilmente con supuestos bastante diferentes sobre el crecimiento, el comportamiento del mercado, de los mineros, de los usuarios...
[02-02-2022 17:54:44] <rbrunner> Lo cual puede llevar a una tasa de crecimiento "óptima" diferente
[02-02-2022 17:55:09] <ArticMine> Se puede argumentar en contra de cualquier número tomando casos extremos
[02-02-2022 17:56:13] <rbrunner> Siendo realistas, si vamos ahora con 1,7 y se nos echa encima algo malo, probablemente podamos hacer una emergencia-HF en un mes o incluso menos. Con esto en mente, no deberíamos permitir que un estancamiento arruine nuestro bonito HF. IMHO.
[02-02-2022 17:56:15] <selsta> Yo me quedaría con el 1.7, aún tendremos tiempo suficiente para investigar más sobre las tasas en el futuro
[02-02-2022 17:56:52] <ArticMine> ^ Estoy de acuerdo
[02-02-2022 17:57:57] <ArticMine> Este es el punto del compromiso
[02-02-2022 17:58:39] <jberman[m]> Ok
[02-02-2022 17:59:19] <selsta> además mooo ya se actualizó a PR así que hay que ir con eso ahora :D
[02-02-2022 17:59:30] <UkoeHB> lol
[02-02-2022 17:59:33] <rbrunner> lol
[02-02-2022 17:59:42] <rbrunner> El mejor argumento de hoy :)
[02-02-2022 17:59:52] <mj-xmr[m]> ^ Convencido
[02-02-2022 17:59:57] <rbrunner> Ingeniería sólida
[02-02-2022 18:00:08] * moneromooo tecleó a 2.7 en lugar de 1.7 así que supongo que vamos con eso.
[02-02-2022 18:00:26] <ArticMine> lol
[02-02-2022 18:01:54] <rbrunner> Así que tal vez esta vez no es nuestro famoso "consenso flojo", sino sólo uno muy flojo, pero el comprimiso puede pasar - apenas?
[02-02-2022 18:02:04] <carrington[m]> Si estamos en un "consenso aproximado" sobre la cifra de 1,7, ¿alguien tiene alguna idea sobre esta preocupación mía:
[02-02-2022 18:02:04] <carrington[m]> ¿sabemos con certeza que las implementaciones de los mineros están realmente configuradas para actuar " de forma racional" una vez que estamos en el régimen de tamaño de bloque dinámico? es decir, ¿el software como XMRig tiene en cuenta la penalización que se aplicará correctamente y se permite construir bloques de más de 300kb en entornos de tasas óptimas, o simplemente sigue añadiendo ingenuamente las transacciones de mayor tasa más allá del límite de 300kb? Me parece por tanto que si la minería
[02-02-2022 18:02:04] <carrington[m]> el software no está configurado para resolver estas cosas, el sistema de tamaño de bloque dinámico no funcionará bien.
[02-02-2022 18:03:02] <ArticMine> El tamaño de bloque dinámico ha entrado en funcionamiento antes
[02-02-2022 18:03:18] <ArticMine> se ha puesto en marcha
[02-02-2022 18:03:42] <ArticMine> después de la bifurcación de RingCT en 2017
[02-02-2022 18:03:44] <rbrunner> No sé, no puedo imaginar que los mineros aguanten esto durante mucho tiempo antes de rebelarse
[02-02-2022 18:04:01] <moneromooo> xmrig no tiene que preocuparse por esto.
[02-02-2022 18:04:01] <UkoeHB> Ok estamos al final de la reunión. Parece que hay un consenso general para que 1.7 entre en el fork. Espero que para el verano haya un entendimiento más fuerte y preciso sobre el escalamiento, la estabilidad y los costos de spam alrededor del tamaño de los bloques y el crecimiento de los mismos. De esta manera podremos tener argumentos convincentes sobre los factores de escalado y la presencia/ausencia de un límite superior duro.
[02-02-2022 18:04:11] <merope> Xmrig no sabe nada acerca de las transacciones ni de las tasas, sólo las plantillas de bloques de hashing
[02-02-2022 18:04:50] <rbrunner> Bien dicho, UkoeHB.
[02-02-2022 18:04:54] <merope> Las tasas y txes son responsabilidad de los nodos (o de quien genere la plantilla de bloques a minar)
[02-02-2022 18:05:09] <carrington[m]> OK supongo que me refiero a los operadores del pool (o los algoritmos que utilicen)
[02-02-2022 18:05:17] <UkoeHB> gracias por asistir a todos