¿Qué es el BOLT 12? Bueno, son muchas características diferentes y partes móviles juntas para ganar varias cosas diferentes: códigos QR estáticos, facturas modulares, privacidad para la persona que recibe el plazo.
Pero, ¿cuál es el paquete total? Es una forma de tener un solo código QR, una «proposición», que le permite extraer facturas de un nodo de una forma que preserva la privacidad, mientras sigue haciendo cosas como pedirle a un nodo remoto que pague su suma, puede solicitar.
Ahora, cualquiera que esté familiarizado con LNURL ya debería estar pensando: «Eso se parece mucho a LNURL.» Pero para aquellos de ustedes que no saben qué es LNURL o cómo funciona, aquí hay un desglose rápido.
¿Qué es LNURL?
LNURL es una pila de protocolos simples para coordinar la información necesaria para los pagos a través de Lightning Community utilizando HTTP. La serie completa de partes del protocolo LNURL se puede encontrar aquí, pero solo cubriré algunos usos principales que se superponen con BOLT 12.
Tres piezas centrales del protocolo LNURL son un esquema de autenticación donde se puede usar una secreto pública para iniciar sesión en un servicio, un esquema de solicitud de suma donde una billetera puede hacer ping a un servidor a través de un código QR inmutable y recuperar una suma, y un esquema de solicitud de Plazo donde una billetera puede hacer ping a un servidor y solicitar que el servidor pague una suma proporcionada por la billetera. Las facturas relámpago son mucho más largas que las direcciones de bitcoin en cautiverio, el plazo en sí ya es un proceso interactivo que requiere que ambas partes estén en lista, por lo que tiene sentido coordinar los detalles de plazo de forma interactiva a través de una conexión de crimson.
El protocolo de autenticación es efectivamente solo el servidor que proporciona un número generado aleatoriamente que firma la billetera del beneficiario con una secreto recién generada. Una vez que el servidor recibe el valencia azaroso firmado, almacena la secreto asociada para usarla en futuros inicios de sesión.
La función de solicitud de suma es una forma de proporcionar a un beneficiario información sobre un plazo que desea realizar en un formato que no es una suma. Esto incluye una descripción del plazo, el monto intrascendente y mayor que el servicio dilación sufragar y una URL para la billetera desde la cual solicitar una suma true. A partir de aquí, la billetera muestra esta información al beneficiario para que pueda establecer un monto ultimate y solicitar una suma. A posteriori de que se envía la solicitud de suma y se recibe una del servidor, la billetera verifica que los montos coincidan con los establecidos por el beneficiario y paga la suma.
La solicitud de retiro funciona haciendo ping al servicio y brindando como respuesta una descripción, una URL para remitir una suma, una cautiverio de caracteres aleatoria (o determinista para vincularla a una cuenta o beneficiario) y un monto intrascendente y mayor que se retirará Puede ser obtenido. A posteriori de ingresar el valencia apropiado, la billetera envía una suma al servidor y, si es válida y está adentro de los parámetros de cantidad, el servicio paga la suma. El protocolo de autenticación LNURL además se puede usar para asegurar que solo el beneficiario previsto pueda retirarse con éxito utilizando el enlace LNURL.
LNURL ha suavizado y mejorado gran parte de la experiencia de UX en torno al uso de Lightning Community, pero requiere el uso de un servidor internet para ser utilizado. Todas las solicitudes y respuestas se manejan a través de HTTP, y se requiere una infraestructura adicional más allá del nodo Lightning para manejar estos métodos simplificados de coordinación y procesamiento de pagos. Este es un requisito perfectamente moderado para cualquier proveedor de servicios en lista o minorista que de todos modos necesite un servidor net para proporcionar sus servicios o productos en lista. Sin retención, para un beneficiario last doméstico no práctico en tecnología que solo quiere una experiencia tan sencilla como esta, un mercader ambulante, una tienda física u otro beneficiario que aún no necesita usar un servidor world-wide-web, puede ser una tarea tediosa y requisito potencialmente riesgoso.
¿Qué es el BOLT 12?
BOLT 12 ofrece un intento de ganar algunas de las funciones principales de LNURL sin requerir el uso de un servidor website. Una proposición codifica los datos necesarios para arribar a un nodo, solicitar una suma, realizar un plazo, ya sea a un node_id o a una ruta ciega (los últimos saltos en una ruta de cebolla, precalculados y encriptados). mensajes Todavía puede codificar un monto intrascendente para un plazo, la moneda en la que se pagará, un tiempo de vencimiento y números de cantidad mínima/máxima (para comprar varios artículos).
Esta es toda la información necesaria para recuperar una suma authentic del nodo que emitió la cotización. Determinado que quiere sufragar una suma lo hace a través de Onion Messages, una de las funciones principales de BOLT 12. Permite que los nodos establezcan una conexión cifrada directa de extremo a extremo entre sí que no involucra un canal Lightning. Al igual que los pagos Lightning, estos pueden estar de moda para reenviar mensajes. A posteriori de percibir una proposición, un pagador united states la información codificada en ella para remitir un mensaje de Solicitud de suma. El creador de la cotización luego argumenta con una suma genuine.
Todavía hay soporte para crear ofertas únicas por beneficiario, lo que permite al destinatario solicitar el plazo del creador de la proposición, identical a la función de solicitud de retiro de LNURL. Las facturas de BOLT 12 se comprometen con una secreto de pagador única esto se puede usar al emitir reembolsos para demostrar que usted es la persona que efectivamente pagó la suma. Esto además se puede usar en combinación con la proposición de retiro para asegurar que solo la persona adecuada pueda percibir una suma pagada por el creador y no todos los que puedan percibir una copia de la proposición.
Estos dos usos de ofertas realizan efectivamente la misma funcionalidad que las solicitudes de plazo y facturación de LNURL sin la penuria de ejecutar un servidor web.
LNURL o PERNO 12? Se negociación de compromiso
LNURL y BOLT 12 cumplen la misma funcionalidad normal, entonces, ¿cuál es efectivamente la diferencia entre ellos? ¿Por qué se necesita BOLT 12 cuando ya existe LNURL? La principal diferencia es el servidor world-wide-web. Un servidor internet requiere más infraestructura, un nombre de dominio, un certificado TLS y la experiencia para tener la llave de la despensa esas cosas.
Si perfectamente este no es un problema importante para la mayoría de las empresas y servicios, regalado que estas cosas son necesarias para ejecutar un negocio en lista en primer extensión, es un gran problema para el beneficiario last peculiar no técnico. No se dilación que un beneficiario instale infraestructura adicional en su nodo Lightning para lograr a una experiencia de beneficiario straightforward y optimizada. Todavía está el tema de la centralización de DNS Un dominio nunca puede ser efectivamente controlado por el propietario.
Apartado de estos problemas, entreambos pueden coexistir. LNURL funciona a la perfección y ya está muy extendido en el ecosistema Lightning, simplemente no es una alternativa realista para usuarios que no sean empresas o servicios. BOLT 12, como se cree, puede cerrar esta brecha y ofrecer la misma experiencia de beneficiario optimizada a los usuarios finales domésticos no empresariales.
Ambas soluciones logran más o menos lo mismo para dos clases diferentes de usuarios, y eso está perfectamente.
Esta es una publicación invitada de Shinobi. Las opiniones expresadas son exclusivamente suyas y no reflejan necesariamente las de BTC Inc o Revista Bitcoin.
