Monero Research Lab Meeting – Wed 12 January 2022 @ 17:00 UTC #649

17:00:29 hora de la reunión: https://github.com/monero-project/meta/issues/649
17:00:36 1. saludos
17:00:36 hola
17:00:56 <ArticMine[m]> Hola
17:01:02 Hola
17:01:47 <Rucknium[m]> Hola
17:03:17 hola
17:03:31 <jberman[m]> hola
17:04:19 2. discusión; hoy quiero discutir sobre este https://gist.github.com/tevador/501.. y el siguiente comentario https://gist.github.com/tevador/50..
17:04:57 ¿Alguien tiene ideas/comentarios/preguntas aparte de tevador y yo?
17:05:58 <jberman[m]> Sobre el método 3: las claves de la cuenta deben ser precalculadas, lo que significa que las subdirecciones a nivel de “cuenta” (i) tendrían que ser precargadas en una tabla de búsqueda? No he tenido suficiente tiempo para comprender ese método.
17:06:21 <jberman[m]> (para los no-cambios/autogastos)
17:06:27 no las subdirecciones, la propia clave de la cuenta (utilizada para generar direcciones para esa cuenta)
17:06:45 ¿Entiendo que esto puede ser visto como una pregunta / decisión bastante amplia de cómo soportar las cuentas bajo Seraphis / JAMTIS, y si es así cómo?
17:06:50 Básicamente los usuarios tendrían que decirle a su software en qué cuentas buscar fondos.
17:07:39 rbrunner: el comentario de seguimiento es acerca de la posibilidad/cómo apoyar las cuentas. El post original es sobre cómo mapear eficientemente las salidas a las direcciones/cuentas al escanear.
17:07:43 rbrunner: se trata más bien de optimizar el reconocimiento de salidas (a qué accnt/addr corresponde la salida)
17:07:57 <jberman[m]> pero puede haber toneladas de claves de cuentas, lo cual tiene un problema similar al del método 1 donde se necesita una tabla de búsqueda, ¿no?
17:08:28 Sí, pero si básicamente te deshaces de los esquemas rígidos de cuentas, que ya no importa tanto, o se puede simplificar, ¿no?
17:08:47 jberman[m]: de ahí mi propuesta de eliminar las claves de las cuentas
17:09:41 después de enumerar los pros y los contras, creo que es una obviedad, pero me gustaría escuchar opiniones
17:10:13 Por lo que veo el uso de las cuentas se ha quedado más o menos en una característica de “usuario avanzado”, ni siquiera todos los monederos las soportan, no son precisamente un éxito rotundo si se quiere ser brutalmente honesto
17:10:20 jberman[m]: sí, pero en algún momento el propósito/utilidad de una ‘cuenta’ se pierde si estás generando muchas de ellas; siendo realistas, el conjunto de cuentas debería estar estrictamente limitado
17:10:26 Así que si podemos simplificar ahí, ¿por qué no?
17:10:55 sí, también hemos propuesto reducir el índice de cuentas a 16 bits
17:11:43 rbrunner: era sobre todo para los comerciantes
17:11:55 Creo que las cuentas deben ser totalmente soportadas, o no.
17:12:06 Interesante. ¿Tuvo éxito allí? ¿Lo sabemos?
17:12:08 pero incluso sin niveles de cuentas, todavía hay un nivel que puede generar direcciones, pero no puede ver las salidas
17:12:48 No tengo ni idea de cómo la gente o los comerciantes utilizan las cuentas actualmente
17:13:14 Aunque pensándolo bien, tal vez el apoyo parcial estaría bien… si los usuarios quieren categorizar sus fondos de alguna manera, ‘cuentas’ es la forma más razonable.
17:13:26 Creo que las cuentas son una característica a nivel de cartera
17:13:35 Bueno, al menos no he visto que se acumule una presión de “¿cuándo vais a soportar por fin las cuentas?” para los monederos que no las soportan (todavía)
17:14:02 Sí, pero la implementación de referencia será probablemente el 99% de los usuarios
17:14:39 aun así, probablemente sea más limpio si las especificaciones de las direcciones son agnósticas a esa característica
17:14:41 <jberman[m]> Creo que desaprobar las “cuentas” necesita la opinión de más usuarios. Yo las uso y es bueno porque tengo una contabilidad racionalizada y una buena abstracción de cómo se gastan los fondos, sin necesidad de ir a un nivel más profundo y seleccionar realmente qué salidas quiero gastar
17:14:47 No estoy seguro, creo que Feather Wallet ha hecho avances en comparación con la interfaz gráfica de usuario, y creo que hicieron una decisión consciente de no apoyar las cuentas, ya que es demasiado complicado UX sabiduría
17:15:58 Sí, por eso me ha gustado el planteamiento del último comentario de un espacio de direcciones uniforme que sólo gestiona lógicamente el monedero en unos “compartimentos”, como quiera llamarlos
17:16:11 Si eso realmente vuela
17:16:38 Creo que la pregunta principal hoy es si vale la pena optimizar la detección de salidas con 8 bytes más de direcciones y 8 bytes más de salidas
17:16:46 Tal vez podamos mantener las cuentas con el esquema simplificado pero renombrarlas como ‘categorías de saldo’ o algo así para reflejar que no son delineaciones ‘duras’ en la cartera.
17:17:43 <Rucknium[m]> BTC y otras monedas también tienen cuentas. Desde mis observaciones, las cuentas se utilizan raramente. En parte es un problema de huevo y gallina. Las billeteras no las soportan ya que los usuarios no las usan, y viceversa.
17:17:58 Mi opinión personal es que 8 bytes es un precio digno de una recuperación de salida robusta.

17:17:58 <Rucknium[m]> Aunque puede que los comerciantes y los intercambios las utilicen.
17:18:17 <UkoeHB> precio*
17:18:18 <rbrunner> ¿A qué te refieres con “recuperación de la salida” exactamente?
17:18:26 <UkoeHB> ver scanning
17:18:39 <monerobull[m]> Rucknium[m]: Tengo como 10 carteras ya que no entendí las cuentas al principio
17:19:09 <UkoeHB> Con una tabla de subdirecciones puedes tener salidas fuera de la tabla (esto evita el mapeo de direcciones PID, y esquemas similares).
17:19:14 <Rucknium[m]> Uno de los números de las rutas de derivación de BTC para los monederos compatibles con BIP44/49 es para los números de cuenta.
17:20:12 <rbrunner> ¿Y con 8 bytes esos problemas “fuera de la mesa” están (perdón por el juego de palabras) fuera de la mesa es decir, resueltos?
17:20:49 <UkoeHB> Correcto; otro ejemplo: ‘generar subdirecciones aleatorias’ sin necesidad de conocer todas las subdirecciones que ya has generado
17:21:04 <jberman[m]> buen juego de palabras rbrunner
17:21:35 <rbrunner> Todo lo que simplifica tiene mi inmediata simpatía 🙂
17:22:15 <UkoeHB> (con ‘generar aleatorio’ y direcciones de 40 bits, se producirá una colisión el 50% de las veces a lo largo de 1 millón de generaciones)
17:24:45 <tevador> Creo que la capa de escaneo de la salida simplemente devolvería “esta salida va a este índice de 56 bits” y las capas superiores lo interpretarían de alguna manera (incluso podría ser un espacio de direcciones plano de 56 bits)
17:25:33 <UkoeHB> correcto
17:25:43 <rbrunner> ¿Es de 40 bits si mantenemos un número razonable de cuentas fijas?
17:25:52 <UkoeHB> 40 bit con 16bits de cuentas
17:25:58 <rbrunner> Ah ok
17:26:21 <UkoeHB> o ‘categorías’ tal vez ^.^
17:27:46 <rbrunner> Uno de los aspectos agradables de la cuenta actual es que se restauran desde la blockchain. Si perdemos eso me parece que las devaluamos bastante. Pero no se puede tener todo, supongo
17:28:19 <tevador> ^ ese aspecto no se perdería
17:28:34 <rbrunner> ¿Incluso con un espacio plano de 56 bits?
17:28:42 <rbrunner> En el nivel más bajo
17:29:00 <tevador> no se pierde nada, sólo es una interpretación diferente de los mismos datos
17:29:31 <tevador> podrías tratar los 56 bits como 16+40 bits y obtener cuentas
17:29:51 <rbrunner> Hmm, sí, pero esto puede entonces -al menos potencialmente- diferir de monedero a monedero.
17:30:18 <rbrunner> Me refiero a la App de billetera a la App de billetera
17:30:19 <UkoeHB> la implementación de referencia establece el estándar, y depende de otros monederos seguir/ir por un camino diferente
17:30:24 <tevador> una cosa es lo que está escrito en las especificaciones y otra la implementación real
17:30:59 <jberman[m]> Entonces, si mantenemos las “cuentas”/categorías de 16 bits, el cliente precalcularía 2^16 claves y las guardaría en memoria, ¿no? Y si las cuentas están obsoletas, ¿esto no es necesario?
17:31:06 <UkoeHB> las billeteras ya tienen la libertad de hacer algo diferente con los índices (no es que ninguna lo haga, por lo visto)
17:31:37 <tevador> jberman[m]: exactamente
17:31:53 <UkoeHB> jberman[m]: esa es una opción, aunque imo sólo las categorías que el usuario agrega manualmente deben ser precalculadas
17:32:16 <rbrunner> O si las cuentas son empujadas uno o dos niveles hacia arriba en la jerarquía de procesamiento, si entiendo correctamente
17:32:19 <tevador> la cuestión es que si el índice de cuentas se utiliza para la derivación de claves entonces las cuentas se vuelven obligatorias para todos las billeteras
17:32:23 <UkoeHB> Tardaría 2,6s en configurar contextos Blowfish para 65k claves.
17:33:28 <jberman[m]> ¿también son posibles las colisiones hoy en día? o eso sería nuevo
17:33:43 <UkoeHB> colisiones donde/
17:33:44 <jberman[m]> posibles dentro de lo razonable
17:34:15 <rbrunner> ¿Que se puedan encontrar dos pares (cuenta, dirección dentro de la cuenta) que den como resultado la misma subdirección?
17:34:19 <jberman[m]> <UkoeHB> “(con ‘generar aleatorio’ y 40-…” <- aquí
17:34:34 <tevador> con PIDs de 64 bits, es posible que se produzcan colisiones si tienes más de 100 millones de ellos.
17:34:40 <UkoeHB> sí generando un índice de subdirecciones aleatorio de 32 bits también habrá colisiones
17:35:12 <tevador> con 32 bits, tendrás colisiones con ~miles
17:35:35 <rbrunner> ¿Porque los alcanzan el mismo punto ECC o lo que sea dentro de la precisión utilizada? O algo así 🙂
17:36:05 <tevador> es extremadamente improbable que dos direcciones diferentes tengan la misma clave
17:36:05 <UkoeHB> Es sólo un índice que es aleatorio, no el punto ECC
17:36:27 <rbrunner> De todas formas, si también podemos tener colisiones *con* cuentas, eso no es un pro definitivo de ellas.
17:36:33 <UkoeHB> Si generas aleatoriamente el mismo índice dos veces (colisión), entonces obtendrás la misma dirección
17:37:09 <rbrunner> No, me refiero a si puedes numerar todas las cuentas posibles y todas las direcciones posibles dentro de ellas y nunca obtener la misma subdirección dos veces
17:37:49 <rbrunner> con una garantía
17:37:50 <UkoeHB> sí, el conjunto de todas las direcciones posibles no contendrá colisiones salvo con una probabilidad despreciable. Necesitas 2^128 puntos ECC aleatorios para tener un 50% de probabilidad de colisión.
17:38:26 <rbrunner> Ok, así que probablemente no en este universo todavía.
17:38:55 <jberman[m]> ¿quién está generando subdirecciones aleatorias y por qué importa una colisión en el índice? los usuarios las incrementan

17:39:34 <tevador> Creo que ese era un argumento que los comerciantes usaban contra las subdirecciones, “puedes generar PIDs al azar”
17:39:52 <UkoeHB> Me refiero a si te olvidas de cuántas direcciones tienes. O tal vez tienes algún servicio que te genera direcciones y no quieres que colisionen con las direcciones que generas en tu propia máquina.
17:39:59 <rbrunner> Creo que eso sería una implementación particularmente fácil para el sistema de los comerciantes, porque no tienen que “slog” alrededor de la información donde se encuentran con el contador
17:41:51 <rbrunner> Así que ahora tenemos posibles tasas de colisión para sub-direcciones al azar en la mesa que son un poco incómodamente altas, me parece
17:42:08 <jberman[m]> que me parece que no es tan robusto hoy en día
17:42:10 <Rucknium[m]> rbrunner: slog = schlepp? (tedioso)
17:42:10 <tevador> con las etiquetas de dirección encriptadas, los comerciantes podrían generar índices de forma aleatoria, pero todavía tendrían que comprobar si hay colisiones. Creo que incluso con PID esto es necesario a no ser que tengas pocos pedidos en general
17:42:14 <UkoeHB> Por cierto, en el futuro podríamos escuchar quejas de que 40-56 bits es demasiado pequeño para los PIDs… ¿no se necesitan como 10-16 bytes para PIDS robustos?
17:42:23 <rbrunner> Sí, “schlepp” (tedioso)
17:42:35 <jberman[m]> lo ideal sería que el sistema mercantil utilizara un contador compartido para generar direcciones
17:43:20 <tevador> con la búsqueda basada en la tabla de búsqueda, un contador compartido es un requisito
17:45:12 <rbrunner> Me duele la cabeza, con tantos pros y contras conflictivos…
17:45:20 <rbrunner> Decisiones difíciles
17:46:03 <UkoeHB> ¿cuáles son las cosas conflictivas? el único contra de “hacer un cambio” es la adición de 8 bytes a las salidas/direcciones
17:46:50 <rbrunner> Bueno, si eso no abre el camino para generar con éxito sub-direcciones aleatorias sin miedo / comprobación de las direcciones, eso es quizás una contra?
17:46:51 <jberman[m]> una cosa que está bien: Creo que el método 2 es inferior a cualquiera de los métodos 1 o 3, por lo que uno puede ser eliminado para reducir la superficie de decisión
17:47:09 <UkoeHB> hay dos cosas que estamos discutiendo: 8 bytes para un descubrimiento de salida más robusto, si/cómo depreciar las cuentas (una cuestión básicamente no relacionada)
17:48:13 <tevador> jberman[m]: ¿quieres decir que el método 1 es inferior al 2 y al 3? El 2 puede hacer lo mismo que el 1, pero añade más opciones
17:48:58 <UkoeHB> rbrunner: ¿quizás quieras proponer ir a 16 bytes (necesitamos un múltiplo de 64 bits con blowfish, a menos que encontremos un buen cifrado de 32 bits y podamos hacer 12 bytes)?
17:49:17 <tevador> 16 bytes es excesivo
17:49:36 <UkoeHB> Sólo me refiero a reducir las tasas de colisión*.
17:50:46 <tevador> eso es mucho blockchain inflado sólo para que los comerciantes gasten un poco menos en el desarrollo
17:50:51 <jberman[m]> las colisiones son posibles en cualquier esquema que estemos viendo, ¿no? No veo cómo en cualquier esquema, alguien puede sin miedo generar con éxito subdirecciones aleatorias sin comprobar si hay colisiones
17:51:07 <rbrunner> Creo que he revisado la información en el gist más a fondo que hasta ahora, sospecho que tengo algunas lagunas en mi comprensión
17:51:52 <tevador> No creo que evitar las colisiones al generar aleatoriamente las direcciones de las carteras deba ser el objetivo.
17:52:04 <rbrunner> tevador: buenos argumentos IMHO
17:52:38 <jberman[m]> tevador: Estoy de acuerdo
17:52:52 <rbrunner> Tal vez ese posible objetivo resulte ser una mera detracción
17:54:30 <rbrunner> Pero además, si la gente genera subdirecciones, digamos, “con sentido”, ¿cómo de robusto debe ser nuestro descubrimiento de salidas?
17:55:26 <rbrunner> ¿Alguna vez no cogeremos una?
17:55:31 <rbrunner> Siendo realistas
17:55:35 <tevador> AFAIK el repo de github recibe un montón de problemas como “saldo de cartera incorrecto”, etc.
17:55:50 <tevador> todo eso desaparecería con este esquema
17:56:12 <rbrunner> Cierto, como en Reddit, pero al menos allí tengo la impresión de que es casi simplemente restaurar la altura.
17:56:32 <tevador> https://github.com/monero-project/monero/issues/8138
17:56:36 <rbrunner> Y no gente haciendo el tonto con subdirecciones “exóticas”, lejanas o no.
17:56:39 <jberman[m]> aquí hay una reciente: https://github.com/monero-project/monero/issues/8138
17:57:17 <jberman[m]> Creo que el coste añadido de 8 bytes por salida para el descubrimiento sólido de subdirecciones es un coste sólido
17:57:26 <rbrunner> Que podría resolver con sólo usar parámetros de inicio adecuados?
17:57:28 <jberman[m]> Y la eliminación de las cuentas es algo que imagino que necesitaría la opinión de la comunidad
17:58:14 <tevador> no queremos eliminar las cuentas, eso nunca fue propuesto por nadie AFAIK
17:58:18 <jberman[m]> bueno todo necesita de la retroalimentación de la comunidad obviamente, pero un mayor conocimiento de cómo se usan las cuentas por parte de los miembros de la comunidad ayudaría
17:58:25 <UkoeHB> “Parámetros de inicio adecuados” siempre será una solución poco práctica y propensa a casos extremos
17:58:43 <rbrunner> Claro, pero si entiendo bien hay formas de mantener las cuentas y seguir simplificando cosas como la generación de claves / handlich ¿verdad?
17:58:54 <tevador> la propuesta era desaprobar las carteras a nivel de cuenta en jamtis
17:59:33 <tevador> por ejemplo, puedo crear un monedero que sólo puede acceder a la cuenta número 1

18:00:08 <rbrunner> Ah, ahora lo entiendo. Sí que parece un poco exagerado, a primera vista.
18:00:16 <rbrunner> IMHO
18:00:24 <UkoeHB> ¿Qué es exagerado?
18:00:32 <tevador> ¿No ha quedado claro mi comentario? https://gist.github.com/tevador/50..
18:00:37 <rbrunner> ¿Tener tipos de carteras de vista tan finos?
18:01:16 <rbrunner> No, creo que el comentario es claro, debería haber vuelto a buscar los tiers… mi error probablemente…
18:02:06 <rbrunner> Me refiero a que son pocas las personas que usan cuentas, ¿cuántas personas entonces van a usar un monedero de sólo vista que está restringido a una sola cuenta?
18:02:51 <tevador> Originalmente estaba pensado como una característica para los comerciantes y pensaba que no tenía inconvenientes, pero resultó tenerlos.
18:05:15 <rbrunner> Personalmente no tengo ningún problema si esos monederos de vista sólo para cuentas resultan ser nada más que un sueño fugaz 🙂
18:05:15 <jberman[m]> “y dependería del monedero cómo se divide ese espacio de direcciones”. -> es decir, un monedero puede decir “las primeras 1000 direcciones son -> cuenta 1, las siguientes 1000 direcciones son cuenta 2” etc. algo así pero con cifras más sensatas… ¿es así como se mantendrían las cuentas?
18:06:32 <tevador> exactamente
18:07:00 <rbrunner> Bien. Yo también lo estaba entendiendo así, y hoy me he convencido de que eso funcionaría.
18:07:04 <tevador> el punto principal es que el esquema de direccionamiento se independizaría de cómo se definen las cuentas (y si se definen)
18:07:04 <UkoeHB> ahora mismo la dirección de 64 bits se mapea en 2 índices de dirección/subdirección de 32 bits; ese mapeo está definido por la cartera
18:07:28 <UkoeHB> índice de direcciones de 64 bits*
18:07:33 <rbrunner> Si la implementación de referencia se adelanta y propone algo sensato que luego la gente sigue, salvo que tenga buenas razones para no hacerlo
18:08:05 <rbrunner> No es necesario codificar esto tan profundamente, incluso en la blockchain como hoy en día
18:08:49 <jberman[m]> Lo sigo, me gusta
18:09:03 <tevador> OK. Entonces voy a actualizar la propuesta para no asumir ninguna estructura particular para el índice de direcciones. Los índices de 56 bits también me parecen razonables
18:09:16 <UkoeHB> no hay objeciones por mi parte
18:10:15 <UkoeHB> ¿hay consenso sobre la etiqueta de dirección encriptada de 8 bytes? ¿necesitamos más opiniones (no hay muchos participantes hoy)?
18:11:11 <rbrunner> Es difícil de decir, con las lagunas de comprensión que he detectado hoy…
18:11:30 <rbrunner> Un poco fuera de mi alcance 🙂
18:12:28 <jberman[m]> Me gustan
18:14:07 <UkoeHB> Bueno, tal vez no hay fuertes sentimientos negativos. tevador si usted está a bordo y dispuestos, podría estar bien para agregar las etiquetas de 8 bytes a jamtis. La iteración final de jamtis requerirá y obtendrá mucho más escrutinio.
18:14:42 <UkoeHB> Ya se ha pasado la hora, así que doy por terminada la reunión. Gracias por asistir a todos.
18:14:55 <Rucknium[m]> ¿Nos estamos acercando a un “menú” que sea comprensible para comerciantes, bolsas, desarrolladores de carteras y usuarios?
18:14:58 <rbrunner> Muy interesante el día de hoy, gracias.
18:15:58 <tevador> Creo que estamos convergiendo en una propuesta que podría estar cerca de ser definitiva
18:16:44 <tevador> Sólo dame un poco de tiempo para actualizar el gist
18:16:59 <UkoeHB> Sí, la única cuestión abierta en mi mente es la semántica exacta para la implementación de referencia de cuentas/direcciones.
18:20:49 <UkoeHB> Después de consultar un diccionario de sinónimos… ‘categoría de direcciones’ es probablemente la mejor alternativa (sólo ‘categoría’ en el lado del usuario) 🙂
18:23:35 <UkoeHB> Quiero plasmar que una ‘cuenta’ no tiene un significado estricto. Son más bien colecciones/grupos de direcciones para organizar su saldo…