Monero

Monero Research Lab Meeting – Wed 22 December 2021 @ 17:00 UTC #642

MRL 642

Cuando: 22 de Diciembre de 2021

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

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

MRL Historial de conversación:

[12-22-2021 17:00:12] <UkoeHB> hora de la reunión: https://github.com/monero-project/meta/issues/642
[12-22-2021 17:00:12] <UkoeHB> 1. saludos
[12-22-2021 17:00:12] <UkoeHB> hola
[12-22-2021 17:00:23] <tevador> hola
[12-22-2021 17:00:26] <sgp_> ¡hola!
[12-22-2021 17:00:30] <rbrunner> Hola
[12-22-2021 17:00:55] <Rucknium[m]> Hola
[12-22-2021 17:00:58] <jberman[m]> hola :)
[12-22-2021 17:04:49] <mj-xmr[m]> ¡Hola!
[12-22-2021 17:06:10] <dEBRUYNE> hola
[12-22-2021 17:06:27] <sethsimmons> Hola a todos 🙂 .
[12-22-2021 17:06:31] <UkoeHB> 2. discutir los esquemas de dirección de Seraphis: https://github.com/monero-project/research-lab/issues/92 https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024
[12-22-2021 17:06:31] <UkoeHB> ¿Alguien tiene algún comentario/pregunta sobre esto?
[12-22-2021 17:06:56] <UkoeHB> Mi objetivo hoy es reducir la elección a 1-3 opciones.
[12-22-2021 17:07:35] <dEBRUYNE> Creo que muchos usuarios agradecerían una clave de vista que tenga una funcionalidad completa, es decir, que muestre el saldo, además de las transacciones entrantes y salientes
[12-22-2021 17:07:48] <dEBRUYNE> Así, podría decirse que ya deberíamos reducir las opciones a los esquemas que incluyen esto
[12-22-2021 17:08:01] <UkoeHB> Eso es todo excepto el esquema A
[12-22-2021 17:08:33] <dEBRUYNE> OK ty
[12-22-2021 17:08:37] <sgp_> No lo reduce demasiado :p
[12-22-2021 17:08:47] <dEBRUYNE> Mitigar el ataque janus parece una victoria fácil si tenemos que cambiar el esquema de direcciones de todos modos
[12-22-2021 17:09:03] <Lyza> Me parece que 5 niveles de billeteras podrían ser un poco confusos para los usuarios, aunque veo que 2 son sólo para comerciantes así que tal vez no sea tan malo
[12-22-2021 17:09:37] <Lyza> hablando de la propuesta de tevador
[12-22-2021 17:09:45] <tevador> Los niveles de comerciantes están ahí principalmente para facilitar la eliminación de las direcciones integradas.
[12-22-2021 17:10:10] <Lyza> interesante -- ¿prevés que se dejen de usar eventualmente?
[12-22-2021 17:10:23] <Rucknium[m]> ¿Por qué dice "detectar" un ataque Janus en lugar de " evitar" un ataque Janus?
[12-22-2021 17:10:32] <dEBRUYNE> Lyza: Sería menos confuso entonces tener direcciones integradas, secundarias y públicas, además de la clave de vista / clave de gasto
[12-22-2021 17:10:38] <dEBRUYNE> Lo que tenemos actualmente 
[12-22-2021 17:11:12] <sethsimmons> Yo, personalmente, estoy bastante a favor de JAMTIS, ya que encapsula tanto un esquema de direcciones sólido como un nuevo enfoque de direcciones.
[12-22-2021 17:11:15] <tevador> Rucknium[m]: Creo que decir "detectar los outputs de Janus" sería más acertado
[12-22-2021 17:11:37] <tevador> ya que no se puede evitar que la gente las envíe
[12-22-2021 17:11:40] <sethsimmons> El formato de dirección necesario para facilitar eso parece ser un ajuste sólido y coincide básicamente con lo que yo querría de los esquemas de dirección de todos modos.
[12-22-2021 17:11:49] <Lyza> <dEBRUYNE> cierto pero no es tan simple como las propuestas con tres niveles así que me pregunto sobre los beneficios de los otros 2
[12-22-2021 17:12:03] <dEBRUYNE> Cierto si
[12-22-2021 17:12:43] <UkoeHB> tevador: podrías añadir un comentario a la propuesta señalando que tu esquema no soporta direcciones integradas (no más PIDs encriptados)
[12-22-2021 17:13:17] <tevador> Por cierto, los niveles comerciales pueden ser fácilmente eliminados e introducidos más tarde si es necesario, no afecta al núcleo del protocolo
[12-22-2021 17:13:41] <sethsimmons> tevador: Ah, ese es un detalle importante 🙂 .
[12-22-2021 17:14:02] <Lyza> sí es bueno saberlo
[12-22-2021 17:14:10] <sethsimmons> Mejor aún, entonces.
[12-22-2021 17:14:25] <sgp_> ¿Qué importancia tiene que el primer nivel de cualquier sistema permita cuál de los dos: a) ver sólo las etiquetas, o b) las salidas entrantes (sin cantidades)
[12-22-2021 17:14:57] <UkoeHB> ¿puedes replantear la pregunta?
[12-22-2021 17:15:15] <dEBRUYNE> sgp_: Por lo que veo, con a) podemos mejorar la privacidad de los monederos ligeros
[12-22-2021 17:16:02] <sethsimmons> Que el nivel 1 satisfaría en JAMTIS, a mi parecer.
[12-22-2021 17:16:17] <jberman[m]> Hacen más que mejorar la privacidad de los monederos ligeros. Personalmente me gusta el enfoque de la etiqueta de vista de tevador 'o Janus B porque ofrecen este nivel
[12-22-2021 17:16:29] <sgp_> No creo que tenga una opinión súper fuerte de Janus B vs Janus E, pero Janus B está más en línea con las expectativas actuales
[12-22-2021 17:16:41] <dEBRUYNE> jberman[m]: ¿Puedes detallar lo de 'más'?
[12-22-2021 17:16:55] <jberman[m]> También aumenta el atractivo de utilizar el nivel 1 para el [escaneo en segundo plano del lado del cliente](https://github.com/monero-project/monero/issues/8082), o en la ejecución de su propio servidor de monederos ligeros, como [monero-lws](https://github.com/vtnerd/monero-lws) u [openmonero](https://github.com/moneroexamples/openmonero), y la concesión de permiso de nivel 1 a ese servidor. Un proceso de escaneo perpetuo ejecutado en un dispositivo plantea un problema de seguridad:
[12-22-2021 17:16:55] <jberman[m]> la clave en caliente y disponible para un atacante. Si esta clave sólo revela las salidas recibidas y no las cantidades, entonces las propiedades de seguridad de escanear perpetuamente la cadena en un dispositivo son más fuertes
[12-22-2021 17:17:45] <UkoeHB> sgp_: JAMTIS está en medio de eso, te permite computar todas las etiquetas de la vista, y adicionalmente encontrar salidas entrantes (sin cantidades) sólo para las direcciones que conoces (lo que puede no ser súper útil en la práctica).
[12-22-2021 17:17:53] <sethsimmons> jberman[m]: Este ^ Gran paso al frente para la viabilidad y privacidad de billeteras ligeras.
[12-22-2021 17:18:14] <tevador> En realidad, creo que incluso revelar las salidas recibidas sin cantidades podría ser demasiado fuerte. JAMTIS Nivel 1 sólo revela las etiquetas de vista, por lo que hay salidas señuelo que no van a parar al monedero.
[12-22-2021 17:18:25] <sethsimmons> Es muy, muy importante que tengamos un fuerte soporte para el LWS a medida que la cadena crece en uso.
[12-22-2021 17:18:32] <sgp_> UkoeHB: lo entiendo, no tengo ni idea de si esto es útil en la práctica pero podría ser utilizado por los usuarios expertos en teoría
[12-22-2021 17:18:52] <sethsimmons> Y sin embargo hacerlo sin revelar información crítica en el caso de un LWS malicioso de terceros
[12-22-2021 17:19:08] <jberman[m]> tevador: por eso me gusta también el esquema de etiquetas de vista
[12-22-2021 17:19:48] <tevador> Revelar las salidas significa que el nivel 1 podría detectar heurísticamente los gastos reales a través de las salidas de cambio, reduciendo la eficacia de los anillos que los utilizan como señuelos.
[12-22-2021 17:19:51] <Rucknium[m]> ¿Podemos preguntar a las empresas que actualmente utilizan Monero qué tipo de características querrían en un esquema de direcciones? ¿Qué podemos hacer para facilitarles la vida (y por lo tanto hacer que los posibles negocios que acepten XMR sean más propensos a aceptar XMR)? LocalMonero ya ha intervenido, pero deberíamos incluir a más empresas en la conversación.
[12-22-2021 17:19:57] <sgp_> sethsimmons: para ser claros, revelar la etiqueta de vista sigue siendo malo, sólo que es menos malo :) Así que no sé cuánto importará en la práctica, pero al menos hay algo de negación, así que eso es algo.
[12-22-2021 17:20:25] <sethsimmons> sgp_: Sigue siendo mucho mejor que el sistema actual.
[12-22-2021 17:20:42] <tevador> revelar las etiquetas de vista es lo menos malo que todavía se puede utilizar para acelerar la sincronización de la cartera
[12-22-2021 17:20:44] <sethsimmons> Obviamente el usuario final debe correr el LWS, pero me gusta que esto proteja lo más posible incluso a los que no quieren/pueden.
[12-22-2021 17:21:03] <UkoeHB> tevador: como el nivel 1 de JAMTIS puede ver las claves de gasto nominales de todas las salidas, cada vez que haya un duplicado sabrán que es una clave de gasto real
[12-22-2021 17:21:13] <sgp_> ¿Hay alguien aquí que piense que reducir el primer nivel desde ver salidas recibidas (sin importes) a ver etiquetas es una mala idea?
[12-22-2021 17:21:29] <ErCiccione> Rucknium[m]: Informaré por Haveno
[12-22-2021 17:21:35] <UkoeHB> sgp_: para hacer eso, las direcciones tienen que ser 1 clave más largas
[12-22-2021 17:21:39] <sethsimmons> sgp_: ¿Primer nivel de qué esquema?
[12-22-2021 17:22:17] <sethsimmons> Oh Janus B
[12-22-2021 17:22:20] <sgp_> UkoeHB: Esta me gusta, esta frase me ha convencido (dejando de lado otras compensaciones)
[12-22-2021 17:22:21] <tevador> UkoeHB: cierto. Tiene algunas limitaciones, pero introducir una clave independiente para las etiquetas de vista tendría sus propios problemas.
[12-22-2021 17:22:49] <tevador> Como por ejemplo necesitar 2 claves públicas por salida.
[12-22-2021 17:22:53] <jberman[m]> En cuanto a las etiquetas de vista, creo que sería útil medir el rendimiento de este enfoque (con varias Tx) para calcular exactamente cuán útil sería este nivel (cuánto tiempo llevaría escanear las salidas del año anterior, cuántas salidas). Creo que sería útil ver la importancia de este aumento de velocidad para valorar mejor la propuesta. ¿Sería este aumento de velocidad lo suficientemente importante como para que podamos estar seguros de que la gente estará muy contenta con ello
[12-22-2021 17:22:53] <jberman[m]> nivel 1 a largo plazo, incluso cuando el volumen aumente mucho?
[12-22-2021 17:23:19] <sgp_> en la práctica con JAMTIS, yo ejecutaría mi propio LWS y proporcionaría mis direcciones públicamente conocidas a él para una mejor eficiencia, y luego soportaría la eficiencia ligeramente inferior por la privacidad ligeramente mejor (que parece ser una ganancia neta)
[12-22-2021 17:23:36] <sgp_> * mejor privacidad para las otras direcciones (que parece
[12-22-2021 17:23:44] <UkoeHB> jberman[m]: ¿te refieres a un nivel que sólo puede calcular las etiquetas de vista, sin claves de gasto nominal?
[12-22-2021 17:23:58] <jberman[m]> UkoeHB: sip
[12-22-2021 17:24:55] <tevador> Eso también sería una opción, pero tiene inconvenientes: 1 pubkey más en cada dirección y 1 pubkey más en cada salida.
[12-22-2021 17:25:02] <UkoeHB> sgp_: Creo que el único beneficio de filtrar por direcciones en el LWS sería un menor coste de ancho de banda/almacenamiento, no de tiempo de cálculo.
[12-22-2021 17:27:50] <tevador> Por cierto, una dirección JAMTIS básica tiene 139 caracteres (otros esquemas con 3 claves serían similares).
[12-22-2021 17:28:09] <tevador> Eso es un 50% más largo que las direcciones actuales.
[12-22-2021 17:28:24] <sgp_> supongamos 1 caso de uso más: alguien quiere proporcionar una prueba de recepción de fondos, pero no quiere revelar todo el gasto futuro. Según estoy leyendo, podrían hacer esto con JAMTIS con las direcciones receptoras conocidas, ¿correcto?
[12-22-2021 17:29:08] <UkoeHB> ¿Están Fluffypony o LocalMonero para dar su opinión sobre JAMTIS? Tenían mucho que decir sobre el tema el la MRL
[12-22-2021 17:29:23] <fluffypony> ¿qué es un jamtis?
[12-22-2021 17:29:27] <monerobull[m]> tevador: De todas formas no es que actualmente se puedan teclear
[12-22-2021 17:29:35] <UkoeHB> fluffypony: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024
[12-22-2021 17:29:51] <rbrunner> Si miro todas las nuevas posibilidades de JAMTIS realmente me preocupa A) todas las funciones que necesitarán las carteras para manejar todo, y B) el esfuerzo de los usuarios para aprender sobre todo
[12-22-2021 17:30:02] <rbrunner> *todas las nuevas funciones
[12-22-2021 17:31:03] <sgp_> aunque también me preocupa la explicación de la complejidad, proporciona una mejor privacidad de base desde el principio, por lo que lo veo como un riesgo general menor
[12-22-2021 17:31:11] <fluffypony> rbrunner: pero eso se abstraería de los usuarios
[12-22-2021 17:31:25] <fluffypony> y la mayoría de los monederos se limitan a crear una dirección básica y se acaba con ella
[12-22-2021 17:31:30] <tevador> sgp_: puedes demostrar que una dirección te pertenece. Eso es diferente a demostrar que has recibido fondos.
[12-22-2021 17:31:42] <rbrunner> ¿se puede salir con la suya manejando sólo direcciones básicas?
[12-22-2021 17:31:54] <fluffypony> rbrunner: por el lado de los receptores, seguro
[12-22-2021 17:32:03] <dEBRUYNE> jberman[m]: Gracias, tiene sentido
[12-22-2021 17:32:11] <fluffypony> y en el lado de envío MyMonero por ejemplo utiliza el código CLI transcodificado en JS
[12-22-2021 17:32:18] <fluffypony> o WASM quiero decir
[12-22-2021 17:32:26] <fluffypony> entonces es un mundo diferente, no necesitamos escribir cosas desde cero
[12-22-2021 17:32:46] <sgp_> tevador: hmm, ¿entonces con JAMTIS estamos perdiendo la capacidad de mostrar direcciones de recibir salidas específicas sin revelar también el balance+gasto? Si es así, debo haber entendido mal entonces
[12-22-2021 17:33:04] <fluffypony> tevador: una cosa que deberíamos hacer en las direcciones es empezarlas con algo, por ejemplo, xmr, para que sean inmediatamente identificables visualmente - que sólo puede ser despojado antes de procesar
[12-22-2021 17:33:14] <fluffypony> ie. eVuKRDtxGWvdDMVX7wHS5dQFk8DgF8rvXZ7kKWMiNps25NLwiwSfriqaksdkxVgMXVyiw54EbULLQ9FzcC4XcxhbRfCsV2Uzx8Qjsgs7LPrJ1GHx5NX5ao6fwh2yy3oxLt7pvUcxB debe ser xmreVuKRDtxGWvdDMVX7wHS5dQFk8DgF8rvXZ7kKWMiNps25NLwiwSfriqaksdkxWgMXVyiw54EbULLQ9FzcC4XcxhbRfCsV2Uzx8Qjsgs7LPrJ1GHx5NX5ao6fwh2yy3oxLt7pvUcxB
[12-22-2021 17:33:37] <rbrunner> Hmm ... todavía no tenemos todos los monederos propiamente dichos que soportan subdirecciones, y/o direcciones integradas, y ahora inventamos cosas nuevas a montones, y esperamos que haya soporte. Puede ser bastante optimista
[12-22-2021 17:34:03] <UkoeHB> sgp_: una prueba de recepción de seraphis sería más o menos lo mismo que actualmente
[12-22-2021 17:34:13] <sgp_> rbrunner: esto agiliza muchas de esas cosas aunque a mi parecer
[12-22-2021 17:34:15] <tevador> sgp_: tal vez entendí mal la pregunta, JAMTIS no es diferente al esquema actual en ese sentido. 
[12-22-2021 17:34:18] <fluffypony> rbrunner: por cierto MyMonero ha soportado pagos a subdirecciones durante años, simplemente hay demasiada carga de UX para implementarlo en la cartera
[12-22-2021 17:34:43] <tevador> fluffypony: claro, la versión base58 podría tener un prefijo "xmr
[12-22-2021 17:34:53] <sgp_> UkoeHB: sí pero ¿qué es eso, algo más que hay que compartir fuera de banda además de una clave de visualización de nivel 1?
[12-22-2021 17:35:01] <rbrunner> Sí, ese es uno de mis puntos: Cuántas pantallas nuevas, casillas de entrada, botones de radio, etc. necesitará para soportar todo eso
[12-22-2021 17:35:01] <fluffypony> tevador: ¿también no querríamos que la suma de comprobación (checksum) fuera algo un poco más útil / robusto, por ejemplo, Reed-Solomon?
[12-22-2021 17:35:30] <UkoeHB> sgp_: si sólo quieres demostrar la propiedad de 1 salida, sólo necesitas 1 prueba de recepción (sin clave de nivel 1)
[12-22-2021 17:35:32] <tevador> Si se considera que las nuevas funciones son demasiado para implementar, se pueden añadir más adelante. Solo hay que mantener los bits de la cabecera y todo se puede añadir más adelante.
[12-22-2021 17:35:36] <dEBRUYNE> rbrunner: Por lo que he entendido, en Seraphis sólo habrá un tipo de dirección básicamente
[12-22-2021 17:36:01] <fluffypony> rbrunner: correcto - y mi punto es que no lo harías, sólo tendrías una dirección básica en el 90% de los casos. todos los otros bits de fantasía son en su mayoría útiles para los flujos de pago en las aplicaciones de los comerciantes, por lo que serían generados por una aplicación de punto de venta
[12-22-2021 17:36:06] <rbrunner> Bueno, si miro la propuesta de JAMTIS, veo un número desconcertante de posibles direcciones
[12-22-2021 17:36:36] <rbrunner> Sí, tal vez sobreestimo lo que el usuario "normal" tendría que afrontar
[12-22-2021 17:36:38] <tevador> fluffypony: estaba pensando en diferentes checksums, pero base58 no es muy compatible con estos. Puedo elaborar más tarde si es necesario.
[12-22-2021 17:36:40] <sgp_> UkoeHB: actualmente, puedo proporcionar una clave de vista y la gente puede ver todas las salidas que entran en esa cartera. Con JAMTIS, eso no es posible a no ser que también se comparta la salida ¿no?
[12-22-2021 17:37:06] <fluffypony> tevador: no es necesario - solo era curiosidad 
[12-22-2021 17:37:12] <UkoeHB> sgp_: un conjunto de direcciones de nivel 1 + mostrará todas las salidas entrantes a esas direcciones (sin cantidades)
[12-22-2021 17:38:08] <sgp_> UkoeHB: ok eso es lo mejor de los dos mundos, lo siento me confundí en el medio allí así que gracias por aclarar
[12-22-2021 17:38:11] <UkoeHB> * si la persona con nivel 1 se entera de tus direcciones por un tercero, es lo mismo
[12-22-2021 17:38:53] <fluffypony> además del prefijo base58 realmente no tengo más comentarios, esto tiene todo mi apoyo
[12-22-2021 17:38:55] <tevador> Sí, y el Tier 2 puede ver todo, incluidos los importes y los gastos
[12-22-2021 17:40:09] <jberman[m]> <UkoeHB> "tevador: desde JAMTIS el tier 1 puede..." <- puedes ampliar esto más, ¿cuándo habría un duplicado aquí?
[12-22-2021 17:41:13] <UkoeHB> jberman[m]: dos salidas cualesquiera que sean propiedad de la misma dirección tendrán la misma clave de gasto nominal, si se escanea con una clave de búsqueda-recepción
[12-22-2021 17:42:59] <jberman[m]> ¿cuál sería el beneficio de las etiquetas de vista todavía en ese caso? ¿no podrías determinar fácilmente las salidas propiedad de la misma dirección a través de las claves de gasto nominal entonces?
[12-22-2021 17:43:22] <tevador> Sí, si se proporcionan al nivel 1, se puede.
[12-22-2021 17:43:32] <TheCharlatan> tevador , ¿hay un subconjunto mínimo de características que un monedero podría implementar para JAMTIS tal y como está la propuesta ahora? Me resulta un poco confuso cuáles serían las características mínimas.
[12-22-2021 17:43:36] <tevador> El nivel 1 no puede derivar claves de gasto.
[12-22-2021 17:44:14] <UkoeHB> En general, creo que el nivel 1 tiene un montón de escollos a tener en cuenta, pero no hay ninguna forma realista de evitar esos problemas sin A) eliminar el escaneo de terceros, B) añadir costes a las direcciones, la cadena y el escaneo LWS, C) aumentar enormemente el poder del escaneo de terceros
[12-22-2021 17:44:29] <tevador> TheCharlatan: sí, la dirección básica sin metadatos (mainnet header byte 0xe0)
[12-22-2021 17:44:30] <sgp_> ¿Es correcto que una dirección de comerciante para el nivel de monedero 1.5 puede ver todas las salidas entrantes para el monedero porque pueden generar direcciones independientemente? Eso es lo que tengo entendido
[12-22-2021 17:45:02] <tevador> sgp_: no, sólo pueden generar direcciones para una cuenta.
[12-22-2021 17:45:06] <UkoeHB> > ¿en qué se beneficiarían las etiquetas de vista en ese caso? ¿no se podrían determinar fácilmente las salidas que pertenecen a la misma dirección a través de las claves de gasto nominal entonces?
[12-22-2021 17:45:06] <UkoeHB> Sólo si > 1 salida son propiedad de la misma dirección.
[12-22-2021 17:45:40] <sgp_> tevador: ok, gracias por la aclaración
[12-22-2021 17:46:06] <sgp_> A estas alturas me convencen bastante los tiers para JAMTIS, realmente un gran trabajo aquí
[12-22-2021 17:46:35] <tevador> Como dijo UkoeHB, el nivel 1 es un compromiso.
[12-22-2021 17:46:47] <TheCharlatan> tevador , ¿entonces se puede omitir el contenido alineado en 7.3?
[12-22-2021 17:47:23] <UkoeHB> oh wow, TheCharlatan mucho tiempo sin ver
[12-22-2021 17:48:19] <tevador> TheCharlatan: sí, pero entonces las firmas no tienen mucho sentido porque no abarcarían toda la uri de pago (si el importe y la descripción se dan por separado).
[12-22-2021 17:48:37] <tevador> entonces se puede quitar 7.3 y 7.4 juntos
[12-22-2021 17:49:00] <tevador> la dirección pasa a ser: byte de cabecera, K1, K2, K3, suma de comprobación (checksum)
[12-22-2021 17:49:20] <TheCharlatan> ok, lo entiendo
[12-22-2021 17:51:26] <tevador> También estaba mirando otras opciones de checksum, pero el problema de base58 es que una errata de un solo carácter puede cambiar hasta 8 bytes, lo que no juega bien con ningún checksum basado en polinomios.
[12-22-2021 17:53:05] <sech1> ¿se pueden adoptar a base58?
[12-22-2021 17:53:09] <sech1> Las matemáticas deberían ser similares
[12-22-2021 17:53:34] <tevador> no, se necesita que la base sea una potencia prima
[12-22-2021 17:53:56] <tevador> base 59 podría funcionar
[12-22-2021 17:54:46] <TheCharlatan> por lo que recuerdo esta es una de las razones por las que bitcoin pasó a base 32 (pero podría estar equivocado)
[12-22-2021 17:55:03] <moneromooo> ¿Requiere más datos en la salida (es decir, actualmente cantidad y pubkey)?
[12-22-2021 17:55:21] <UkoeHB> Antes de terminar la reunión, ¿hay alguien que tenga alguna objeción a JAMTIS, o que piense que se debería incluir otro esquema en la lista de opciones?
[12-22-2021 17:55:41] <UkoeHB> rbrunner: ?
[12-22-2021 17:55:54] <tevador> moneromooo: no, salvo que podría necesitar una pubkey distinta para cada salida
[12-22-2021 17:55:57] <jberman[m]> ¿Podría omitirse también el 8 (autenticación del destinatario/todo lo relacionado con esto) y ser soportado por cualquier esquema de direcciones en un futuro? Tal y como yo lo veo, el componente más crítico es un par de claves asimétricas adicionales para la verificación de la identidad; ¿no podríamos teóricamente implementar un protocolo que logre el mismo objetivo de verificación de la identidad junto con cualquiera de los esquemas de direcciones propuestos, en cualquier momento en el futuro?
[12-22-2021 17:56:09] <rbrunner> Sólo una bastante general, más "visceral" como, que esto es demasiado, básicamente de todo :)
[12-22-2021 17:56:37] <rbrunner> Enamorarse de la complejidad por todas las posibilidades que ofrece, el sueño del nerd.
[12-22-2021 17:56:37] <moneromooo> Lo leo como "no, excepto que quizás sí". Puedes ampliar un poco por favor ?
[12-22-2021 17:57:06] <tevador> jberman[m]: como dije, las funciones de autenticación podrían añadirse más adelante, siempre que se mantenga el formato de bytes de la cabecera.
[12-22-2021 17:57:35] <rbrunner> "Recuerda la época en la que una dirección de criptodivisa era sólo... una dirección, y no todo menos el fregadero de la cocina".
[12-22-2021 17:58:06] <UkoeHB> rbrunner: también existe "aprender de la experiencia
[12-22-2021 17:58:11] <jberman[m]> tevador: entendido
[12-22-2021 17:58:17] <tevador> moneromooo: esto está relacionado con la detección de Janus, creo que UkoeHB tenía alguna opción con una sola pubkey si es un tx de 2 salidas con una salida de cambio.
[12-22-2021 17:58:19] <rbrunner> Pero parece que estoy bastante solo aquí con estas intuiciones :)
[12-22-2021 17:58:41] <rbrunner> También es mayormente una reunión técnica, no me extraña
[12-22-2021 17:58:49] <Rucknium[m]> ¿Hay alguna manera de que podamos hacer esta información digerible para las empresas que aceptan Monero, para que podamos llegar a ellos para obtener su punto de vista?
[12-22-2021 17:59:49] <tevador> ^ Segundo a eso, me gustaría escuchar algunos comentarios sobre las funciones del monedero comercial
[12-22-2021 18:00:11] <Rucknium[m]> O tal vez deberíamos tener una encuesta de retroalimentación general, como, "¿Cuáles son los mayores puntos de dolor al lidiar con Monero?"
[12-22-2021 18:01:03] <UkoeHB> tevador: moneromooo Mi objetivo para el nuevo protocolo es que los tx de 2 salidas tengan 1 txo pubkey (aprovechando el cambio/salida ficticio, que es obligatorio para las 2 salidas), y que los tx de >2 salidas tengan 1 txo pubkey por salida.
[12-22-2021 18:01:38] <rbrunner> ¿Cómo se traduce a JAMTIS la queja común "No se pueden generar subdirecciones sin conocer una clave secreta"?
[12-22-2021 18:01:53] <tevador> Pues debería ser igual que ahora si todas las salidas van a una subdirección.
[12-22-2021 18:01:58] <UkoeHB> correcto
[12-22-2021 18:02:10] <tevador> rbrunner: por eso JAMTIS tiene Tier 0
[12-22-2021 18:02:20] <rbrunner> Ah, ok
[12-22-2021 18:03:00] <tevador> He oído que era una queja común contra el uso de subdirecciones 
[12-22-2021 18:03:38] <moneromooo> "1 txo pubkey" significa una más de la que tenemos ahora, ¿no?
[12-22-2021 18:03:47] <UkoeHB> no, significa 1
[12-22-2021 18:03:53] <rbrunner> ¿Y esto tiene activo todo el habitual "no se puede correlacionar", es decir, no puedo ver qué direcciones de nivel 0 son de la misma billetera? O puede ser que ahora confunda las cosas
[12-22-2021 18:04:02] <moneromooo> Y 2 txes de salida tendrían... ¿que por salida?
[12-22-2021 18:04:09] <UkoeHB> 0.5 por salida
[12-22-2021 18:04:19] <moneromooo> Ya veo.
[12-22-2021 18:04:33] <moneromooo> ¿Entonces mejor que ahora?
[12-22-2021 18:04:46] <moneromooo> Sólo para asegurarme de que lo he entendido bien :)
[12-22-2021 18:04:52] <tevador> rbrunner: El Tier 0 es sólo para los comerciantes, las direcciones generadas por el Tier 0 se pueden enlazar fuera de la cadena. 
[12-22-2021 18:05:08] <UkoeHB> la txo pubkey es la 'transaction public key' y 'additional tx keys', que tienen un nombre horrible
[12-22-2021 18:05:50] <tevador> ^sí, a mí también me pareció confusa la nomenclatura
[12-22-2021 18:06:57] <TheCharlatan> es una propuesta muy bonita tevador
[12-22-2021 18:08:57] <UkoeHB> rbrunner: todas las direcciones de nivel 0 tendrían dos claves comunes, por lo que todas las direcciones de una cuenta comercial serían vinculables
[12-22-2021 18:09:21] <SerHack> He leído la propuesta, gracias tevador por tu trabajo
[12-22-2021 18:09:34] <sgp_> Estoy absolutamente asombrado por la cantidad de información de la propuesta
[12-22-2021 18:09:37] <UkoeHB> las direcciones de las cuentas no comerciales no serían vinculables
[12-22-2021 18:10:46] <tevador> intentaré incorporar los comentarios de esta reunión
[12-22-2021 18:10:56] <rbrunner> sgp_: ¿Escalonamiento positivo o negativo?
[12-22-2021 18:11:13] <UkoeHB> Se ha pasado la hora, así que doy por finalizada la reunión aquí. Parece que hay un consenso general para seguir con JAMTIS. Los futuros puntos de acción incluyen A) obtener la retroalimentación de los comerciantes, B) decidir cuánto de la API para apoyar out-of-the-box.
[12-22-2021 18:11:26] <UkoeHB> Gracias por asistir a todos