Los códigos de recogida en el punto de mensajería nunca son los mismos cada vez. Incluso si sigue siendo el mismo destinatario, el sistema no te dirá: "Estas dos veces las hizo la misma persona".
Hace poco ayudé a un vecino a recoger un paquete y descubrí que el sistema del punto de mensajería es interesante: la misma persona recogió dos veces, pero el código de recogida era totalmente distinto. El encargado solo ve, al escanear, "de quién es esta recogida", y no puede saber si esa persona ya había venido antes. Después, al revisar el modelo de transacciones de Dusk (Phoenix), me di cuenta de que esta lógica de "cambiar el código cada vez y que los de fuera no puedan relacionarlo" también se usa en la cadena, y además de forma todavía más extrema.
En Phoenix, en cada transferencia, el destinatario no recibe una dirección fija, sino una "note public key" (lo llamaremos npk) de un solo uso. El remitente usa la clave pública a largo plazo del receptor, junto con un número aleatorio, para calcular esa npk única. El receptor, por su propia view key, revisa transacción por transacción: si puede calcular la npk, significa que esa transacción es para él. La clave está en que—esta npk es diferente cada vez. Aunque la misma persona reciba diez pagos, si un tercero escanea los datos en la cadena, no puede ver si esos diez pagos son del mismo destinatario, porque no hay una dirección fija que se repita y permita identificarlo.
Este diseño busca resolver la "unlinkability" (inconexión/no asociabilidad): no evita que se vea "que recibiste el dinero", sino que evita que se arme la relación de que "esos diez pagos son todos del mismo tú". Además, también admite la delegación: el usuario puede entregar su view key por separado a un tercero para que le ayude a escanear qué transacciones son suyas, pero sin concederle el permiso de gastar. Esta separación está muy bien hecha.
Las direcciones de un solo uso suenan seguras, pero también implican que el coste de cómputo para detectar cada transacción es mayor que en el modelo de dirección fija. Cuando el volumen aumenta, si esa eficiencia de escaneo puede aguantar o no, depende de los datos reales.
$DUSK
#dusk @Dusk
Hace poco ayudé a un vecino a recoger un paquete y descubrí que el sistema del punto de mensajería es interesante: la misma persona recogió dos veces, pero el código de recogida era totalmente distinto. El encargado solo ve, al escanear, "de quién es esta recogida", y no puede saber si esa persona ya había venido antes. Después, al revisar el modelo de transacciones de Dusk (Phoenix), me di cuenta de que esta lógica de "cambiar el código cada vez y que los de fuera no puedan relacionarlo" también se usa en la cadena, y además de forma todavía más extrema.
En Phoenix, en cada transferencia, el destinatario no recibe una dirección fija, sino una "note public key" (lo llamaremos npk) de un solo uso. El remitente usa la clave pública a largo plazo del receptor, junto con un número aleatorio, para calcular esa npk única. El receptor, por su propia view key, revisa transacción por transacción: si puede calcular la npk, significa que esa transacción es para él. La clave está en que—esta npk es diferente cada vez. Aunque la misma persona reciba diez pagos, si un tercero escanea los datos en la cadena, no puede ver si esos diez pagos son del mismo destinatario, porque no hay una dirección fija que se repita y permita identificarlo.
Este diseño busca resolver la "unlinkability" (inconexión/no asociabilidad): no evita que se vea "que recibiste el dinero", sino que evita que se arme la relación de que "esos diez pagos son todos del mismo tú". Además, también admite la delegación: el usuario puede entregar su view key por separado a un tercero para que le ayude a escanear qué transacciones son suyas, pero sin concederle el permiso de gastar. Esta separación está muy bien hecha.
Las direcciones de un solo uso suenan seguras, pero también implican que el coste de cómputo para detectar cada transacción es mayor que en el modelo de dirección fija. Cuando el volumen aumenta, si esa eficiencia de escaneo puede aguantar o no, depende de los datos reales.
$DUSK
#dusk @Dusk
