Cuando: 15 de Diciembre de 2021
Donde: monero-research-lab (liberachat/matrix)
Artículo original: https://github.com/monero-project/meta/issues/640
MRL Historial de conversación:
[15-12-2021 17:00:57] <UkoeHB> ok, hora de la reunión https://github.com/monero-project/meta/issues/640 [15-12-2021 17:00:57] <UkoeHB> 1. saludos [15-12-2021 17:00:57] <UkoeHB> hola [15/12/2021 17:01:22] <Rucknium [m]> Hola! [15-12-2021 17:01:28] <ArticMine> Hola [15-12-2021 17:01:32] <rbrunner> Grüezi [15-12-2021 17:01:55] <sethsimmons> Hola a todos [15-12-2021 17:04:28] <jberman [m]> Hola [15/12/2021 17:04:29] <maxwellsdemon [m]> hola [15-12-2021 17:05:05] <UkoeHB> 2. A continuación, pongámonos al día, ¿en qué han estado trabajando todos? [15-12-2021 17:06:01] <Rucknium [m]> La semana pasada estuve trabajando principalmente en proyectos de BCH. No hay mucho que informar sobre Monero. [15-12-2021 17:06:53] <Rucknium [m]> Me he estado involucrando en el análisis de cadenas, supongo. [15-12-2021 17:06:58] <UkoeHB>: trabajé en la revisión de vtnerd de mi PR sobre dirección multifirma, y discutí el PR de construcción de tx múltifirma de wfaressuissia con él (ahora disponible aquí: https://github.com/ proyecto-monero / monero / pull / 8114). [15-12-2021 17:07:41] <ArticMine> Entonces, ¿está listo? [12-15-2021 17:07:46] <jberman [m]> Hice un poco más de pruebas de etiquetas de vista para obtener ganancias óptimas según la opinión de UkoeHB sobre el PR, y volví a trabajar en el algoritmo de selección de señuelos [12-15-2021 17:08:11] <mj-xmr [m]> He estado trabajando para hacer que mi simulador de análisis de blockchain esté ampliamente disponible: no solo para Linux, sino también para Mac y Windows. Rucknium ha informado que la funcionalidad básica se puede ejecutar en su sistema operativo dev: Mac. Necesitaré al menos la mitad de enero para poder entregar las piezas restantes del código que ya funciona. [15-12-2021 17:08:36] <jberman [m]> Sobre el trabajo de selección de señuelos: [12-15-2021 17:08:36] <jberman [m]> - Creé un fragmento de código muy crudo que demuestra una forma de implementar un componente de la selección de anillo determinista, específicamente sobre cómo mapear valores generados aleatoriamente a partir de una semilla en el gamma CDF (o cualquier otra distribución). Creo que es un poco crudo para compartir en este punto, pero todo va por buen camino. [12-15-2021 17:08:36] <jberman [m]> - Revisé el PR para detener la selección de salidas duplicadas en los anillos al construir un tx (https://github.com/monero-project/monero/pull/ 8047) [12-15-2021 17:08:36] <jberman[m]> - Se compartió la idea detrás de la elección de un parámetro sobre cuán amplios deben ser los bins en el binning del lado de la billetera (creo que cuanto más estrechos sean los bins, más efectivos serán los bins para dificultar el análisis de tiempo, pero más propensos a que alguien haga spam con muchas salidas bloqueadas) [12-15-2021 17:09:16] <mj-xmr[m]> También estoy trabajando con un amiga para escribir una propuesta de CCS para ella, ya que podría hacer un montón de cosas 1) Más barato 2) En paralelo [12-15-2021 17:10:10] <UkoeHB> ArticMine: sí, aunque los revisores deberían contactar conmigo, luigi1111, wfaressuissia, o selsta si quieren más detalles sobre los problemas solucionados en ese PR (se revelarán públicamente en algún momento después de que el PR sea fusionado). [12-15-2021 17:10:55] <ArticMine> Gracias [12-15-2021 17:11:10] <rbrunner> estoy un poco perdido sobre cómo tu PR y el 8114 se relacionan, o dependen el uno del otro, o si resuelven diferentes problemas [12-15-2021 17:12:21] <maxwellsdemon[m]> actualmente estoy tratando de entrar en la versión web de esto porque sería mucho más fácil de comunicar:actualmente en mi teléfono [12-15-2021 17:12:27] <UkoeHB> rbrunner: resuelven problemas diferentes. Mi PR es para hacer una cartera multisig, este nuevo PR es para hacer transacciones multifirma. [15-12-2021 17:13:17] <rbrunner> Ya veo. ¿Tendría sentido entonces probar el 8114 de forma similar a como he probado tu PR, sólo para comprobar si "todo sigue funcionando"? [12-15-2021 17:13:18] <maxwellsdemon[m]> estoy aquí para que me den su opinión sobre la idea que propuse hace dos semanas, y hacer un seguimiento con respecto a un problema de procesamiento de señales para estimar la tasa de hadh rate [12-15-2021 17:13:28] <maxwellsdemon[m]> hash* [12-15-2021 17:14:20] <UkoeHB> rbrunner: sí, creo que sí [15-12-2021 17:14:31] <rbrunner> Ok, gracias [12-15-2021 17:14:34] <UkoeHB> maxwellsdemon[m]: ¿podrías recordarnos tu idea? para los registros también [12-15-2021 17:16:07] <UkoeHB> jberman[m]: ¿ese PR causa problemas si el número de salidas disponibles es demasiado bajo, por lo que los anillos duplicados cruzados son inevitables? [12-15-2021 17:16:44] <maxwellsdemon[m]> estoy de vuelta [12-15-2021 17:16:52] <maxwellsdemon[m]> tuve que restablecer mi contraseña... [12-15-2021 17:17:01] <UkoeHB> maxwellsdemon[m]: ¿podrías recordarnos tu idea? para los registros también [15-12-2021 17:17:51] <maxwellsdemon[m]> claro, la idea era sencilla: ajustar adaptativamente el número de hilos mientras se minaba para maximizar las métricas de rendimiento, como el desgaste de la CPU/fuente de alimentación o la gestión de la energía [12-15-2021 17:18:32] <maxwellsdemon[m]> La idea la obtuve al minar en mi portátil, donde rápidamente aumentaba la temperatura de la CPU. Me di cuenta muy rápido de que no sería viable a menos que regulara los hilos utilizando alguna información de la máquina [12-15-2021 17:19:06] <maxwellsdemon[m]> en mi caso consideré la temperatura, pero el consumo de energía también sería una consideración - realmente se reduce a la información disponible de los sensores que pueden ser instalados o utilizados en el sistema [12-15-2021 17:20:09] <maxwellsdemon[m]> Recordando la discusión, se pensó que esto ayudaría a las personas que no son mineros "serios", pero probablemente no será un beneficio para las personas que están más involucradas a menos que pueda demostrar una mayor eficiencia [12-15-2021 17:20:38] <UkoeHB> ¿Es este un proyecto en el que quieres trabajar? [12-15-2021 17:20:39] <maxwellsdemon[m]> entonces se propuso que buscara mejorar el esquema de estimación para conocer la tasa de hash de la red [15-12-2021 17:20:54] <mj-xmr[m]> ¿Puedo sugerir que se dé una opción para una señal externa abstracta? Esto sería por ejemplo la energía acumulada en su batería solar. [15-12-2021 17:21:48] <Rucknium[m]> En mi opinión, un objetivo principal del trabajo propuesto por maxwellsdemon sería aumentar la tasa de hash de los mineros aficionados. A medida que nos acercamos a la emisión de cola el próximo año, exprimir la mayor tasa de hash de los mineros aficionados honestos será cada vez más importante. [12-15-2021 17:22:08] <merope> maxwellsdemon[m]: (Más exactamente: mejorar el algoritmo de ajuste de la dificultad) [15-12-2021 17:24:03] <rbrunner> ... lo cual es bastante polémico, porque creo que muchos ven que funciona lo justo para "no tocar nunca un sistema en funcionamiento" [12-15-2021 17:24:06] <maxwellsdemon[m]> 1) una señal externa es viable, pero el problema con eso es que tienes que tener algún tipo de uniformidad en el hardware para que el firmware y el software sean compatibles con los algos de control, 2) dudo que aumente la tasa de hash tanto como para evitar que alguien queme su máquina y tal vez ahorrar algo de energía, tal vez el aumento de la eficiencia energética, 3) sí estás en lo correcto esto fue para mejorar el ajuste de dificultad [12-15-2021 17:24:06] <maxwellsdemon[m]> algoritmo. Mi entendimiento es que el método actual utilizando un promedio de la ventana móvil, que tiene problemas con las oscilaciones transitorias y los retrasos [12-15-2021 17:27:21] <mj-xmr[m]> 1) Es tan simple para el usuario como escribir un mapeo como 80% de potencia -> 40% de núcleos, 40% de potencia -> 20% de núcleos [15-12-2021 17:27:21] <mj-xmr[m]> 2) Es mejor minar en un núcleo toda la noche, que 2 núcleos la mitad del día y 0 núcleos por la noche, ya que esto no es perfectamente escalable [12-15-2021 17:27:21] <mj-xmr[m]> 3) Autopromoción descarada - tal vez mi simulador será de alguna ayuda, una vez que esté listo. Tendré en cuenta este caso de uso. [12-15-2021 17:28:24] <Rucknium[m]> Bueno, si aumenta la eficiencia energética eso podría traer más poder de hash de todos modos ya que la minería se volvería más viable económicamente para algunos mineros aficionados - el costo de la electricidad es una preocupación, por supuesto. [12-15-2021 17:29:12] <sethsimmons> También consideraría enfocar este trabajo más bien en XMRig ya que siempre es la recomendación para alguien que se preocupe más por la minería. [15-12-2021 17:29:23] <sethsimmons> O al menos ver si el trabajo se puede portar a XMRig también si es viable. [12-15-2021 17:30:07] <maxwellsdemon[m]> mi formación es en teoría de control y modelado matemático, así que donde mis habilidades sean más útiles. [12-15-2021 17:30:58] <mj-xmr[m]> maxwellsdemon[m]: Yo también soy ingeniero de control. El modelado matemático es mi hobby, así que te contactaré :) [12-15-2021 17:31:22] <maxwellsdemon[m]> lol bien [15-12-2021 17:31:22] <Rucknium[m]> Sí, supongo que el software de maxwellsdemon estará incluido o conectado a xmrig ya que es el minero más utilizado, y creo que el más eficiente. [12-15-2021 17:33:02] <jberman[m]> <UkoeHB> "jberman: ¿ese PR causa..." <- Imagino que sí, dificultaría la construcción de anillos cuando hay menos salidas disponibles. Tal vez tenga sentido que sólo se impidan los duplicados entre anillos cuando haya suficientes salidas gastables en la cadena [15-12-2021 17:33:12] <merope> Personalmente, dudo que reducir el número de hilos aumente realmente la eficiencia. En todo caso, la bajaría, porque el hashrate es más o menos directamente proporcional al número de hilos, pero el consumo de energía no lo es - porque tienes la energía consumida por el propio minado que es proporcional, pero también una cantidad fija de energía consumida por el resto del sistema para mantenerse encendido (placa base, ram, disco, otras cosas) [15-12-2021 17:34:00] <maxwellsdemon[m]> entiendo lo que quieres decir [15-12-2021 17:34:08] <merope> Así que para una eficiencia óptima, el objetivo es utilizar tantos hilos como sea posible para "repartir" ese coste de energía base fijo [15-12-2021 17:34:38] <Rucknium[m]> jberman: Sería bueno obtener estimaciones sobre esto. Yo podría ayudar con eso. [12-15-2021 17:35:00] <jberman[m]> Algo alto como 10.000 como lo que usa el sanity check al enviar un tx a un nodo con el sanity check activado podría tener sentido (https://github.com/monero-project/monero/blob/dcba757dd283a3396120f0df90fe746e3ec02292/src/cryptonote_core/tx_sanity_check.cpp#L84) [12-15-2021 17:35:09] <merope> En cuanto a la interacción con xmrig, podría hacerse fácilmente incluso a través de algún script externo que cambie dinámicamente el archivo de configuración. Lo único que tendrías que hacer entonces es implementar la lógica [12-15-2021 17:35:40] <mj-xmr[m]> merope: Sí, por la última parte, pero los PCs de escritorio no son los únicos mineros que hay. Esto no aplica tanto para las máquinas de baja potencia, donde el "costo estático" es relativamente menor. [15-12-2021 17:35:40] <mj-xmr[m]> La minería no es tan escalable a hilos, por desgracia. [12-15-2021 17:36:21] <merope> Pero mejorar el algoritmo de ajuste de la dificultad sería tener un impacto mucho mayor en la minería y en la red en general [12-15-2021 17:36:26] <UkoeHB> jberman[m]: si eso podría funcionar [12-15-2021 17:37:39] <maxwellsdemon[m]> quizás ese sea un mejor problema en el que centrarse entonces [12-15-2021 17:37:56] <merope> Asegurarse de que los tiempos de los bloqueos son más consistentes (especialmente en el caso de grandes oscilaciones de hashrate) mejoraría la experiencia del usuario para las personas que envían transacciones, e (idealmente) haría la red menos susceptible a los ataques de hashrate [12-15-2021 17:38:55] <merope> Por supuesto, un cambio tan crítico estaría sujeto a una revisión y prueba muy cuidadosa antes de ser lanzado en mainnet a través de un hardfork [12-15-2021 17:39:56] <UkoeHB> Antes de que se acabe la reunión, ¿alguien tiene preguntas/comentarios sobre otros temas? Tal vez del temario o de otro tipo. [12-15-2021 17:40:31] <maxwellsdemon[m]> tengo una respuesta pero la voy a posponer [12-15-2021 17:40:52] <Rucknium[m]> Permítanme señalar un reto clave para determinar un algoritmo de ajuste de la dificultad: No es sólo un reto de ingeniería. También hay teoría de juegos mezclada, ya que los jugadores, es decir, los mineros y las entidades maliciosas, pueden reaccionar por sí mismos a cualquier cambio en el sistema. [12-15-2021 17:41:18] <Rucknium[m]> jberman: ¿10.000 unidades de qué, exactamente? [15-12-2021 17:41:47] <maxwellsdemon[m]> Creo que lo importante es definir el problema con claridad, definir unos requisitos/metas para resolver el problema, y conseguir algunos datos respecto a las señales de interés para empezar a diseñar el esquema de estimación [15-12-2021 17:43:58] <jberman[m]> Rucknium[m]: Salidas gastables en la cadena. Actualmente hay más de 40mn de salidas RingCT gastables en la cadena por lo que no afectaría a las salidas RingCT gastables, pero algunas salidas pre-ringCT podrían tener conjuntos más pequeños (y en el cambio a Seraphis, esto sería algo a considerar también) [12-15-2021 17:43:59] <maxwellsdemon[m]> mis pensamientos son que deberíamos probar el esquema en un modelo primero, de-riesgo tanto como sea posible en un entorno seguro, antes de siquiera pensar en probar en una plataforma más realista [12-15-2021 17:44:53] <jberman[m]> En cuanto al binning del lado de la cartera, mi opinión empieza a ser que puede ser un reto conseguir que todo el mundo esté de acuerdo con ello para el próximo fork, teniendo en cuenta que hay opciones de parámetros bastante subjetivas en el algoritmo y que es un cambio bastante significativo en el algoritmo de selección de señuelos tal y como está. Empieza a parecerme que debería aprovechar parte de la idea para avanzar en el binning determinista (tema 84), que es el más largo de todos. [12-15-2021 17:44:53] <jberman[m]> dirección a largo plazo que estamos dirigiendo de todos modos. [12-15-2021 17:45:28] <Rucknium[m]> jberman: Recuérdame, ¿qué sucede bajo tu código cuando la selección aleatoria escoge un miembro del anillo que es un duplicado de otro anillo en el mismo tx? [12-15-2021 17:46:10] <Rucknium[m]> maxwellsdemon: El BCH ha hecho algunos trabajos en un algoritmo de ajuste de dificultad "mejorado" con ASERT: [12-15-2021 17:46:33] <Rucknium[m]> https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-8887b9c1 [15-12-2021 17:46:48] <Rucknium[m]> https://bitcoincashresearch.org/t/asert-before-and-after/312 [12-15-2021 17:48:31] <rbrunner> También algunas bifurcaciones de Monero con hashrates mucho más pequeños utilizan algún algoritmo diferente; pero como dije, cualquier cambio aquí será una *dura* venta :) [12-15-2021 17:49:09] <merope> Aunque vender a quién? ¿A los desarrolladores o a la comunidad en general? [15-12-2021 17:49:31] <jberman[m]> Rucknium[m]: En el PR de yorha-0x (https://github.com/monero-project/monero/pull/8047), simplemente vuelven a seleccionar una salida cuando ya se ha visto/utilizado una en otro anillo. Lo que en realidad ahora me parece un problema potencial en ese PR (este comentario https://github.com/monero-project/monero/pull/8047#discussion_r769368957 puede ser aplicable al caso general también) [12-15-2021 17:49:49] <rbrunner> Creo que sobre todo la comunidad dev. La comunidad general probablemente no se preocupe lo suficiente. [12-15-2021 17:50:06] <jberman[m]> O estabas preguntando sobre cómo el binning del lado de la cartera maneja los duplicados Rucknium [12-15-2021 17:50:35] <UkoeHB> jberman[m]: Creo que estaría bien que cambiaras de enfoque. En última instancia, es tu decisión, ya que eres el "dueño del proyecto" (por así decirlo). [15-12-2021 17:50:53] <Rucknium[m]> jberman: No el binning. El tema de las salidas duplicadas. [12-15-2021 17:52:39] <merope> Yo diría que la DAA está más o menos en el mismo nivel de "importancia" que el protocolo de transacciones, en términos de su impacto crítico en el sistema - y siempre hay interés en hacer el protocolo tx mejor / más seguro (con toda la revisión y las pruebas que conlleva). Entonces, ¿por qué no aplicar el mismo nivel de escrutinio para otras partes del sistema? [12-15-2021 17:53:30] <maxwellsdemon[m]> Rucknium: He leído los enlaces que has proporcionado y la preocupación evidente que tengo es que no veo un análisis matemático claro para el esquema que están utilizando. Siento que estos escritos carecen de detalles y eso me preocupa [12-15-2021 17:53:40] <merope> Si alguien viene con una propuesta sólida y revisada a fondo para un mejor algoritmo, ¿por qué no adoptarlo? [12-15-2021 17:54:23] <maxwellsdemon[m]> Por ejemplo, el hecho de que la señal oscile no significa que esté necesariamente mal. Además, cualquier filtro FIR que implementes (una media móvil es el tipo más simple) tendrá oscilaciones. Eso es algo que no se puede evitar [12-15-2021 17:54:35] <jberman[m]> UkoeHB: tiene sentido, seguiré pensando en ello [12-15-2021 17:54:42] <rbrunner> Bueno, tendrás gente que esté de acuerdo en que es "mejor". Y efectivamente está lo de "no tocar nunca un sistema en funcionamiento", como he comentado, para muchos funciona "suficientemente bien" ahora [12-15-2021 17:55:15] <Rucknium[m]> Se necesitan algunos datos clave: En una semana típica, ¿cuál es la diferencia entre el pico y el valle de dificultad? Lo más preocupante de un DAA sería si abre el sistema a un ataque del 51% más fácilmente en virtud del hecho de que crea un gran margen entre el alza y la baja. [15-12-2021 17:55:36] <rbrunner> No es para desanimar a nadie, por supuesto. Sólo para estar preparados si la marcha se hace más bien rígida :) [15-12-2021 17:56:03] <UkoeHB> merope: Mi entendimiento general es que A) el algoritmo actual no tiene ninguna debilidad fundamental, B) no hay nadie que 'abogue' por la investigación del algoritmo (surae investigó sobre esto, iirc, pero no se hicieron recomendaciones para un nuevo algoritmo). [12-15-2021 17:56:31] <Rucknium[m]> maxwellsdemon: No digo que su DAA sea necesariamente bueno. Estoy diciendo que al menos han pensado en algunos de los problemas, así que tal vez se puede aprender algo de lo que han hecho. [12-15-2021 17:56:40] <atomfried[m]> en cuanto a la DAA, perdona mi ignorancia, pero ¿no es "sólo" la teoría del control? ¿tienes un objetivo y necesitas controlar el entorno para que se cumpla el objetivo? [12-15-2021 17:56:40] <atomfried[m]> ¿No se ha investigado esto ya por la cibernética y la robótica y demás? ¿no debería haber ya un controlador perfecto que lo resolviera? [12-15-2021 17:57:10] <UkoeHB> atomfried[m]: hay una dimensión adversarial que no está presente en la teoría de control normal [12-15-2021 17:57:19] <merope> ^ [15-12-2021 17:57:26] <rbrunner> Sí, la gente que intenta derribar el robot :) [15-12-2021 17:57:29] <atomfried[m]> ahhh ya veo gracias [15-12-2021 17:57:43] <Rucknium[m]> atomfried: No, no es sólo teoría de control. También es teoría de juegos, lo que complica bastante las cosas. [12-15-2021 17:58:36] <UkoeHB> Estamos llegando al final de la hora. ¿Alguna pregunta/comentario de última hora? [15-12-2021 17:58:50] <merope> Rucknium: Tengo un csv listo con la altura y la dificultad de los bloques (y los nonces, pero puedes ignorarlos). Te lo puedo enviar, y seguro que tienes mejores herramientas para evaluar los datos [12-15-2021 17:59:50] <Rucknium[m]> endor00: Bien. Por favor, envíalo. [15-12-2021 18:00:38] <Rucknium[m]> rbrunner: Una cosa clave es que ni siquiera tenemos una buena idea en este momento del riesgo al que nos expone la actual DAA con respecto a los ataques del 51%. [12-15-2021 18:01:07] <maxwellsdemon[m]> atomfried: las soluciones de control son únicas para la dinámica del sistema. La teoría de control no es sencilla salvo para aplicaciones no críticas como los termostatos domésticos [15-12-2021 18:01:33] <Rucknium[m]> Así que decir que "no está roto así que no lo arregles" no es realmente correcto ya que no sabemos si está roto. [12-15-2021 18:01:57] <maxwellsdemon[m]> Estaría bien que tuviéramos un simulador para probar el algoritmo primero [12-15-2021 18:02:08] <maxwellsdemon[m]> es muy arriesgado no tomar ese enfoque - yo no lo haría [12-15-2021 18:02:16] <atomfried[m]> maxwellsdemon[m]: se que es por eso que dije "solo" lol mi tio es profesor en la teoría de control pero no tengo ninguna comprensión de la misma por lo que pensé que sólo preguntaría por qué toda la teoría de control no se puede aplicar a la DAA [12-15-2021 18:02:20] <ArticMine> No tengo claro cómo el BCH apprach ayudaría aquí. El problema que tiene el BCH son las variaciones salvajes en el hashrate debido al uso de los mismos ASICs que BTC [12-15-2021 18:02:27] <merope> maxwellsdemon: tenemos redes de prueba que nos permiten probar estas cosas [12-15-2021 18:02:33] <ArticMine> Monero no tiene este problema [12-15-2021 18:03:53] <merope> Estamos en el "lado BTC" de ese problema [15-12-2021 18:04:03] <Rucknium[m]> Una red de prueba no es suficiente ya que el comportamiento de los mineros no sería el mismo que en mainnet [15-12-2021 18:04:41] <merope> Pero los tiempos de bloqueo pueden llegar a ser bastante sesgados durante/después de ráfagas repentinas de hashrate [12-15-2021 18:05:28] <Rucknium[m]> ArticMine: Sí, no estoy seguro de que algo en el enfoque de BCH nos ayude. Es el único caso en el que he visto que alguien se fija en la DAA, así que al menos es bueno tenerlo en cuenta. [12-15-2021 18:05:38] <maxwellsdemon[m]> Necesitamos algún tipo de modelo, de lo contrario, en mi opinión, cualquier solución que se nos ocurra es sólo una conjetura. Necesitamos una comprensión de la dinámica del sistema para proceder con una solución con sentido [12-15-2021 18:05:39] <merope> Especialmente en la última fase, cuando el pico ha desaparecido y ahora la dificultad tiene que ajustarse a la baja, pero está tardando más porque los bloques tardan más en aparecer porque la dificultad sigue siendo alta pero el hashrate ya no lo es [15-12-2021 18:06:25] <Rucknium[m]> maxwellsdemon: Cierto, cierto. Construir ese modelo sería parte de la tarea de desarrollar un DAA mejorado. [15-12-2021 18:06:55] <maxwellsdemon[m]> Rucknium: Yo recomendaría dividirlos porque eso de por sí es un gran esfuerzo y potencialmente tiene muchos usos [12-15-2021 18:07:29] <ArticMine> <merope> Lo sé pero con el BCH cotizando a ~0.009 BTC y usando el mismo algoritmo que el BTC esto es una prueba de estrés en la DAA [12-15-2021 18:07:29] <bbqcore[m]> UkoeHB: seth mencionó en twitter que seraphis podría permitir la eliminación del requisito de conf de 10 bloques [12-15-2021 18:07:31] <bbqcore[m]> por lo que he entendido no es posible [12-15-2021 18:07:32] <bbqcore[m]> puedes confirmarlo [15-12-2021 18:07:57] <atomfried[m]> maxwellsdemon[m]: estoy bastante seguro de que esas dos cosas podrían ser bonitas tesis de licenciatura o de máster para estudiantes de teoría de control... [12-15-2021 18:08:14] <sethsimmons> Sí, puede que haya malinterpretado una conversación anterior, también me gustaría confirmarlo. [12-15-2021 18:08:42] <Rucknium[m]> atomfried[m]: sgp_: Consigue subvenciones de MAGIC en él lol. [15-12-2021 18:08:55] <maxwellsdemon[m]> Rucknium: lo sería, terminé la escuela demasiado pronto para que la criptografía sea una discusión académica legítima :( [15-12-2021 18:09:43] <Rucknium[m]> En realidad se trata de diseño de mecanismos, con teoría de control anidada en ellos. Definitivamente _es_ un problema complejo, y por ahora tenemos una "heurística" muy aproximada [15-12-2021 18:09:57] <maxwellsdemon[m]> bueno, si hay una manera de ser pagado regularmente (digamos mensualmente), ciertamente doy la bienvenida al desafío [15-12-2021 18:09:59] <atomfried[m]> maxwellsdemon[m]: creo que este es un buen tema porque se aplica más a la teoría del control que a las cosas de blockchain-crypto-buzzwordy [12-15-2021 18:09:59] <UkoeHB> no, todavía no [12-15-2021 18:10:12] <sgp_> sí, MAGIC Grants está aquí para ayudar :) [15-12-2021 18:11:12] <bbqcore[m]> UkoeHB: eso pensé. ¿el chaining tx permitiría gastar una salida no confirmada una vez que se minen los 10 bloques? ¿permitiría ponerlo en cola hasta que esté listo para gastar? [12-15-2021 18:11:57] <UkoeHB> bbqcore[m]: si se pueden encadenar txs, sin embargo el coste es que quien tenga un tx en cola sabrá el gasto real de ese tx [12-15-2021 18:12:17] <bbqcore[m]> UkoeHB: por lo que no es una opción de privacidad [12-15-2021 18:12:24] <bbqcore[m]> 10 confs de bloque se quedan como están [12-15-2021 18:12:53] <UkoeHB> sí, sólo es útil cuando se trata de partes de confianza (o cuando el gasto real ya se conoce, como en los intercambios atómicos) [15-12-2021 18:14:19] <bbqcore[m]> UkoeHB: así que en teoría esto podría permitir a una cartera añadir la división automática de los XMR entrantes a una cantidad establecida de salidas [12-15-2021 18:14:54] <UkoeHB> bbqcore[m]: ¿por qué necesitarías encadenamiento de tx para eso? [12-15-2021 18:15:01] <bbqcore[m]> ya que esencialmente sería un gasto propio y estarías confiando en ti mismo [12-15-2021 18:15:25] <UkoeHB> cuando se terminan los 10 bloques, todavía tienes más trabajo que hacer para completar tu tx (es decir, construir pruebas de pertenencia) [12-15-2021 18:15:37] <UkoeHB> por cierto la reunión ha terminado, gracias por asistir a todos