Los Silent Payments te permiten crear una dirección de Bitcoin única y estática para recibir pagos, manteniendo tu privacidad.
Salvo que tu privacidad no te importe y reutilices addresses (no recomendado), recibir pagos en Bitcoin tiene la complicación de que te obliga a generar un nuevo address cada vez que quieras recibir un nuevo pago.
Esto no es un problema cuando los pagos son pocos, pero igual requiere de nuestra interacción cada vez que lo hacemos: crear un nuevo address, entregárselo al pagador, y verificar el address enviado puede ser un poco estresante.
Cuando esperamos recibir muchos pagos, como en el caso de donaciones o cualquier otro pago recurrente, una posible solución es usar una extended public key (xpub).
Las xpub permiten generar child public keys (y de ahí, addresses) sin necesidad de la private key.
Lo bueno de darle una xpub a alguien es que puede pagarte en addresses tuyas sin necesidad de interacción futura.
Lo malo es que, quien tenga tu xpub, puede ver todas las transacciones pasadas y futuras que se hicieron o harán a addresses que sean derivadas de tu xpub.
Otro problema que tiene compartir tu xpub con varias personas/entidades es que nada garantiza que no haya reuso de addresses. No hay un estado global que indique cuál es el índice del último address “usado” de tu xpub, así que es probable que los pagadores reusen direcciones
Silent Payments al rescate
Silent Payments viene a simplificar los pagos en Bitcoin, permitiendo exponer una única dirección para recibir pagos (Silent Address), pero haciendo que los pagos se reciban en UTXOs con direcciones diferentes, y que nadie pueda vincularlos a tu Silent Address, excepto por vos
¿Cómo funciona? Supongamos que Bob publica su public key “B” codificada como un Silent Address.
Alice quiere usar un UTXO suyo bloqueado en su public key “A” y gastable con su private key “a”. El output (P) que construye Alice se ve así:
P = B + hash(a . B) . G
Ese output se codifica como un Taproot Output (P2TR) y Alice le envía los sats a Bob.
¿Cómo hace Bob para descubrir el pago?
Tiene que escanear todos los outputs Taproot recientes y ver, si haciendo el mismo cálculo que Alice, logra llegar al mismo valor “P” de resultado.
Veamos de nuevo el cálculo que hizo Alice:
P = B + hash(a . B) . G
Alice puede hacerlo porque “B” es la public key de Bob, “a” es su clave privada, y G es una constante en la curva elíptica (Generator Point)
¿Como puede hacerlo Bob si no tiene la clave privada de Alice “a”?
Por propiedad Diffie-Hellman, multiplicar la clave privada de Alice por la pública de Bob es igual a multiplicar la privada de Bob por la pública de Alice
a . B = b . A
Bob conoce su priv key (“b”) y la pub key del UTXO gastado por Alice “A”, entonces puede usar esta propiedad. Entonces Bob sólo tiene que escanear la blockchain de la siguiente manera.
Por cada output:
1- Si es un taproot output, tomar la clave pública A del input y ejecutar pasos 2 y 3
2- Calcular P = B + hash(b . A) . G
3- Si P es igual al taproot output analizado, entonces esos bitcoin pertenecen a Bob!
Evitando el reuso de addresses en Silent Payments
En realidad, el cálculo de P es un poco más complejo porque así tal cual puede reusar addresses. ¿Cómo?
Si Alice realizara otro pago a Bob desde otro UTXO bloqueado en la misma pub key “A”, entonces el cálculo de P daría el mismo resultado. Osea, el address taproot sería igual.
Para eso, se le agrega al cálculo un elemento “input_hash” que va a ser único para cada UTXO, porque tiene la información del outpoint (Tx ID + index)
input_hash = hash(outpoint || A)
Entonces ahora el taproot output sería:
P = B + hash(input_hash . a . B) . G
Esto hace que siempre se genere un nuevo address, incluso si Alice paga desde su misma public key “A” varias veces, porque siempre lo va a hacer desde diferentes UTXOs.
Hasta ahora venimos bien, pero este formato permite que Alice cree sólo un output para Bob.
Permitiendo más outputs
Para que Alice pueda generar más outputs hacia Bob en el mismo pago, se puede generalizar el cálculo de P a varios subíndices P0, P1, … Pn n = 0
Por cada output:
Pn = B + hash(input_hash.a.B || n).G
n = n+1
Ahora Bob escanea buscando el output 0 como describí anteriormente, y cuando lo encuentra busca de la siguiente manera:
1- P1=B + hash(input_hash.b.A || 1).G
2- Si P1 no se encuentra, frena
3- Si P1 existe, busca P2, y así hasta que no se encuentre
De esta manera podemos crear un silent payment con varios outputs. Ahora veamos como agregar múltiples inputs.
Permitiendo más inputs
Cada input de Alice podría tener su propia key (de hecho es lo más común ya que las wallets crean 1 par de claves para cada UTXO).
Entonces, cuál es el “A” y “a” que se debe usar en el cálculo de P?
Una opción es dejar que Alice elija el key pair de 1 de los inputs y exigir a Bob que pruebe con todos los inputs hasta encontrar el que genere el valor P esperado.
Lo que Silent payments propone es que Alice use una private key “a” que sea la suma de las private keys de sus inputs.
a = a1 + a2 + … + an
Entonces para calcular P ya tenemos: “a”, “B”, “G
Lo que nos falta es el input_hash, que antes se calculaba con el outpoint del input. El problema es que ahora hay múltiples inputs. Para este caso, Silent Payments propone usar el input menor lexicográficamente (alfabético)
Con esto tenemos todos los elementos para que tanto Alice como Bob puedan calcular el valor de P (taproot output).
Es decir, Alice tiene un método determinístico para enviar un silent payment a Bob, y Bob tiene un método determinístico para detectarlo y agregarlo a su saldo.
Otras funcionalidades, ventajas y desventajas
Silent Payments también tiene otras features interesantes como la posibilidad de tener una clave privada de escaneo y otra para el firmado, y así evitar exponer la private key de gasto en un dispositivo online. También permite usar labels para identificar los pagos entrantes.
Una gran ventaja de Silent Payments es que podríamos dejar de pagar a addresses y empezar a pagar a “contactos”, sin interacción.
Un silent address de testnet se ve así:
tsp1qq0u04ck46vgktprldj3seh9ndrk5wcahfl4qfvsxp8f5kd8n7kzquqhvtlswaek65zcvndmnxsrqsalrxlm7yksecd9cp62xhcu0r7gqvcphvz5p
La otra gran ventaja es que habría mucha más privacidad en los pagos, porque ningún observador externo podría vincular los UTXOs generados con la Silent Payment address que está recibiendo los pagos. Esto lo hace muy útil sobre todo para donaciones
La única contra es que tu wallet va a tener que escanear toda la blockchain desde el nacimiento de tu silent address en adelante, para detectar pagos entrantes y agregarlos a tu saldo. Pero esto será resuelto por la wallet y no tendrá impacto en el día a día del usuario final
Resumiendo
En resumen, una vez creada tu Silent Address, podrías:
- compartírsela a tus exchanges
- dársela a tus pagadores
- publicarla en tu sitio para donaciones
- publicarla en tu ecommerce
Y todos los pagos van a ser recibidos en UTXOs con addresses diferentes, y con mucha privacidad.
Silent Payments fue propuesto por josibake y Ruben Somsen el 9 de marzo de 2023: link al BIP de Silent Payments
Deja una respuesta