Oferta BOLT12

Una oferta es una solicitud para recibir un pago que sobrevive al propio pago, así que un único código impreso sirve para todos los clientes. Las ofertas no llevan firma ni suma de comprobación, y sus campos ocupan los tipos TLV 2 a 22: son, a propósito, lo bastante cortas para la cámara de un teléfono de gama baja. Si usted recibe bitcoin, esa es la diferencia entre un código que imprime una sola vez y la factura que este acuña, que expira 7200 segundos después.

Cómo funciona

Una oferta BOLT12 es una secuencia de registros tipo-longitud-valor escrita con el prefijo legible por humanos lno, un separador 1 y, después, caracteres de estilo bech32 que transportan esos registros en orden.

Al final no hay ninguna suma de comprobación de seis caracteres. La especificación la suprime con el argumento de que los códigos QR llevan sus propias sumas de comprobación y de que una oferta dañada produce una cadena de caracteres que no se puede interpretar, en lugar de un pago perdido. Las ofertas largas pueden dividirse con un signo más, seguido opcionalmente de espacios en blanco, para que sobrevivan al pegarse en un campo de texto con límite de caracteres, y quien las lee debe eliminar el signo más y los espacios antes de decodificar. Quien las escribe debe usar solo minúsculas o solo mayúsculas, y debería elegir mayúsculas para los códigos QR.

Los campos en sí están numerados. El campo offer_chains es el 2, offer_metadata el 4, offer_currency el 6, offer_amount el 8, offer_description el 10, offer_features el 12, offer_absolute_expiry el 14, offer_paths el 16, offer_issuer el 18, offer_quantity_max el 20 y offer_issuer_id el 22. Quien escribe debe mantenerse dentro de los tipos 1 a 79, con un segundo rango de 1000000000 a 1999999999 reservado para experimentos. Nada de esa lista es una firma, y eso es deliberado: firmar alargaría el código sin ningún beneficio, porque todo campo que no es de firma se copia en la solicitud que sigue, así que una oferta manipulada simplemente no produce ninguna factura.

Pagar requiere después dos mensajes más. Su billetera envía un mensaje invoice_request, con el prefijo lnr, dentro de un mensaje cebolla; copia todos los campos de la oferta, incluidos los que no entiende, y firma el resultado con una firma BIP340 que cubre una raíz de Merkle. El emisor responde con una factura firmada. La construcción de Merkle empareja la hoja de cada campo con una hoja de nonce, y eso es lo que permite a un pagador revelar más tarde un campo de una factura en disputa sin exponer los campos contiguos, algo que no puede hacer una firma BOLT11 que cubre todo el código.

Dos de esos tres mensajes funcionan en sentido inverso para reembolsos y cajeros. Un comerciante publica un invoice_request que indica un monto que quiere enviar, usted responde con una factura, y el comerciante confirma el campo invoice_node_id antes de pagar.

Por qué importa cuando compra bitcoin

Una oferta cambia la forma en que usted publica un medio para recibir pagos, y no cambia en absoluto lo que le cuesta recibirlos.

Tome como ejemplo la reseña de Phoenix de este sitio. ACINQ publica una tabla de comisiones en lugar de dejar que usted la descubra: enviar por Lightning cuesta 0,4 % más 4 satoshis, recibir es gratis cuando ya tiene liquidez entrante, y recibir cuando la billetera tiene que ir on-chain para hacer sitio cuesta 1 % más las comisiones de minería, con un canal nuevo a 1.000 satoshis. Entregar una oferta en lugar de una factura no altera ninguna de esas cifras. Elimina el paso en el que usted acuña un código nuevo por cada pagador, no el paso en el que alguien paga la liquidez.

La ventaja en privacidad es real pero limitada. Una dirección Lightning enruta cada solicitud de factura a través de un servidor web en el dominio de otra persona, y ese operador ve los montos y el momento de cada una. Una oferta enruta la solicitud por Lightning como un mensaje cebolla, y el campo offer_paths permite que un nodo cuyos canales son todos privados siga siendo alcanzable sin publicar ningún ID de nodo. Lo que eso no le da es privacidad frente a su propio proveedor: nuestra reseña de Phoenix cita las preguntas frecuentes de ACINQ, que dicen con todas las letras que conoce el destino final y el monto de los pagos.

La advertencia práctica tiene que ver con pegar. El formulario de retiro de un exchange pide una factura Lightning, y un código lno1 no es una factura. Strike, uno de los 63 registros de exchanges de este sitio, es nativo de Lightning y no añade ninguna comisión propia en las transferencias en más de 100 países, y ese es justo el tipo de proceso en el que se confunden dos formatos. Ni las 41 reseñas de billeteras ni los 63 registros de exchanges de este sitio documentan actualmente la compatibilidad con ofertas como funcionalidad, así que tómela como algo que debe confirmar en las notas de la versión de su propia billetera, en lugar de darla por hecha.

La oferta de un puesto de sombreros y la factura en que se convierte

Un puesto que vende sombreros a 25 dólares escribe una oferta con offer_currency en USD y offer_amount en 2500.

Esa es la regla de la especificación para una moneda distinta de bitcoin: un código ISO 4217 de tres letras y un monto en la unidad de la moneda ajustado por el exponente ISO 4217, lo que en el caso del dólar significa centavos. El mero hecho de establecer offer_amount hace obligatorio offer_description, porque un pagador al que se le cobra algo concreto tiene que saber qué era. Si quedan tres sombreros, offer_quantity_max es 3, y si el puesto no tiene un límite fijo, es 0. Un valor de 1 está permitido de forma explícita, por extraño que parezca, para que un sistema de existencias nunca necesite un caso especial para el último artículo. El campo offer_issuer podría decir hats@example.com Hat Stall, ya que la especificación pide primero un dominio y, tras un espacio, cualquier texto descriptivo.

Su billetera lee eso, le cotiza 25 dólares y envía un invoice_request con el campo invreq_quantity igual a 2 para dos sombreros, un campo invreq_payer_id y, opcionalmente, un campo invreq_payer_note. De vuelta llega una factura con un hash de pago, una marca de tiempo de creación, al menos una ruta ciega y una cotización de comisiones por ruta que incluye la comisión base, la comisión proporcional, la delta CLTV y el HTLC más pequeño y el más grande que transportará. Aquí le protegen dos reglas. Su billetera debe rechazar la factura si algún campo de los rangos 0 a 159 no coincide con lo que envió, y debe advertirle si el monto en milisatoshis difiere de forma significativa de la estimación en dólares que dio la oferta. Salvo que el emisor establezca el campo invoice_relative_expiry, la factura debe rechazarse 7200 segundos después de su creación.

Oferta BOLT12 frente a factura BOLT11

Una oferta BOLT12 es una solicitud de una solicitud de pago; una factura BOLT11 es la solicitud de pago.

El texto del BOLT12 se abre con ocho quejas sobre su predecesor, y las que nota un pagador son estas. Una factura BOLT11 se firma como un todo, así que demostrar un campo implica revelarlos todos. Sus montos legibles por humanos, a juicio de la especificación, resultaron problemáticos: el multiplicador p se manejaba mal a menudo, y es más difícil contar en picobitcoin que en satoshis. Su campo payment_secret solo impedía el sondeo mientras la factura seguía siendo privada entre pagador y beneficiario, cosa que una factura publicada no es. Y, en palabras de la propia especificación, las facturas deben entregarse por usuario y son activamente peligrosas si se hacen dos intentos de pago para el mismo usuario. Una oferta resuelve las cuatro por el simple hecho de no ser una factura.

Oferta BOLT12 frente a dirección Lightning

Una oferta BOLT12 es un código autónomo; una dirección Lightning es un nombre que el servidor de otra persona resuelve por usted.

Las dos son reutilizables, y por eso se confunden. La dirección depende de un dominio, un certificado y un operador que mantenga el servicio en marcha, y deja de funcionar el día en que falla cualquiera de los tres. La oferta depende de que ambos nodos manejen mensajes cebolla y de nada más, lo que supone una superficie de fallo menor, aunque usted tiene que confirmar que su propia billetera la admite en lugar de suponerlo. La dirección gana en una cosa: se puede decir en voz alta. Un código lno1 largo es un código QR, no algo que se dicte a un micrófono.