Lightning & SkalierungLightning & ScalingLightning & EscalabilidadLightning & EscalabilidadeLightning & スケーリングLightning & 扩容Lightning & التوسع
Lightning-Invoices und BOLT-Standard: Was hinter einem Bitcoin-Zahlungslink stecktLightning Invoices and the BOLT Standard: What's Behind a Bitcoin Payment LinkFacturas Lightning y el estándar BOLT: qué hay detrás de un enlace de pago de BitcoinLightning Invoices e o padrão BOLT: o que está por trás de um link de pagamento BitcoinLightning InvoicesとBOLT標準：Bitcoinの支払いリンクの仕組みLightning Invoices 与 BOLT 标准：Bitcoin 支付链接背后的原理Lightning Invoices ومعيار BOLT: ما الذي يقف وراء رابط دفع Bitcoin
Bewertung durch automatisierten Mehrquellen-Abgleich des KI-Redaktionsteams; anschließend menschlich freigegeben.Assessed via the AI newsroom's automated multi-source cross-check, then approved by a human.Evaluado mediante la verificación automatizada multifuente de la redacción de IA y aprobado por una persona.Avaliado pela verificação automatizada multifonte da redação de IA e aprovado por uma pessoa.AI編集部による自動マルチソース照合で評価し、人による承認を経ています。由AI编辑部的自动多源交叉核查评估，并经人工审核。جرى التقييم عبر التدقيق الآلي متعدد المصادر من غرفة أخبار الذكاء الاصطناعي، ثم اعتُمد بشريًا.
Der Artikel erklärt BOLT #11 technisch korrekt und gut strukturiert, lässt aber alle Primärquellen weg – ein erhebliches Glaubwürdigkeitsdefizit für einen Referenzartikel. Die Behauptung vollständiger HTLC-Atomizität ohne Einschränkung vereinfacht ein System, das in der Praxis Kantenfälle wie stuck HTLCs kennt. BOLT #12 wird als fertige Lösung gerahmt, obwohl breiter Wallet-Support fehlt und die Spezifikation noch im Entwicklungsprozess ist. Sicherheitsrelevante Privatsphären-Risiken von Routing Hints und Klartextbeschreibungen fehlen, obwohl der Teaser explizit 'strikte Sicherheitsregeln' verspricht.The article explains BOLT #11 in a technically accurate and well-structured manner, yet omits every primary source – a significant credibility gap for a reference piece. The claim of full HTLC atomicity without qualification oversimplifies a system that, in practice, involves edge cases such as stuck HTLCs. BOLT #12 is framed as a near-complete solution despite lacking broad wallet support and remaining an evolving specification. Privacy risks associated with routing hints and plaintext description fields go unmentioned, even though the teaser explicitly promises "strict security rules."El artículo explica BOLT #11 de forma técnicamente precisa y bien estructurada, pero omite todas las fuentes primarias, un déficit de credibilidad considerable para un artículo de referencia. La afirmación de atomicidad HTLC completa sin matices simplifica en exceso un sistema que, en la práctica, presenta casos límite como los HTLCs bloqueados. BOLT #12 se presenta como una solución casi terminada, pese a que carece de soporte amplio en wallets y la especificación sigue en desarrollo. Los riesgos de privacidad asociados a los routing hints y a los campos de descripción en texto claro no se mencionan, aunque el avance promete explícitamente «estrictas reglas de seguridad».O artigo explica o BOLT #11 de forma tecnicamente precisa e bem estruturada, mas omite todas as fontes primárias — uma lacuna de credibilidade significativa para um artigo de referência. A afirmação de atomicidade HTLC total sem ressalvas simplifica demais um sistema que, na prática, apresenta casos extremos como HTLCs travados. O BOLT #12 é apresentado como uma solução quase completa, apesar de não contar com suporte amplo em carteiras e ainda ser uma especificação em evolução. Os riscos de privacidade associados aos routing hints e aos campos de descrição em texto simples não são mencionados, mesmo que o teaser prometa explicitamente «regras de segurança rigorosas».この記事はBOLT #11を技術的に正確かつ構造的にわかりやすく説明しているが、一次資料をすべて省略しており、参照記事としては信頼性に大きな欠陥がある。完全なHTLCアトミック性を無条件に主張することは、実際にはスタックHTLCのようなエッジケースが存在するシステムを過度に単純化している。BOLT #12は、ウォレットの幅広いサポートが欠如しており、仕様もまだ策定中であるにもかかわらず、ほぼ完成した解決策として位置づけられている。ルーティングヒントや平文の説明フィールドに関連するプライバシーリスクについては、ティーザーが「厳格なセキュリティルール」を明示的に謳っているにもかかわらず、一切言及されていない。本文对 BOLT #11 的阐述技术准确、结构清晰，但完全略去了所有一手资料——对于一篇参考性文章而言，这是一处显著的可信度缺陷。在毫无保留地声称 HTLC 具有完全原子性时，文章过度简化了一个在实践中存在边缘情况（如卡滞的 HTLC）的系统。尽管 BOLT #12 尚缺乏广泛的钱包支持且规范仍在演进中，文章却将其定位为一项近乎完善的解决方案。与路由提示和明文描述字段相关的隐私风险只字未提，而文章的引言却明确承诺「严格的安全规则」。يشرح المقال BOLT #11 بدقة تقنية وبنية جيدة، غير أنه يُغفل جميع المصادر الأولية، وهو ما يُشكّل ثغرة كبيرة في المصداقية لمقال مرجعي. يُبسّط الادعاء بالذرية الكاملة لـ HTLC دون تحفظ نظامًا يواجه في الواقع حالات حافة كـ HTLCs العالقة. يُقدَّم BOLT #12 باعتباره حلًا شبه مكتمل، على الرغم من غياب الدعم الواسع من المحافظ واستمرار مسيرة تطوير المواصفة. لا تُذكر مخاطر الخصوصية المرتبطة بتلميحات التوجيه وحقول الوصف النصي الصريح، رغم أن المقدمة تعد صراحةً بـ«قواعد أمان صارمة».
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Wer im Lightning Network eine Zahlung empfangen möchte, stellt eine Invoice aus – einen kompakten, kryptografisch gesicherten String, der alle Informationen enthält, die ein Sender für die Zahlung benötigt. Das zugrundeliegende Format ist in BOLT #11 der Lightning Network Specifications (LIGHTNING-RFC) definiert. Hinter jedem lnbc…-String verbirgt sich eine präzise Datenstruktur mit klaren Sicherheitsgarantien.
Aufbau einer BOLT #11 Invoice: HRP und Data Part
Eine BOLT #11 Invoice ist ein Bech32-kodierter String – derselbe fehlerkorrigierende Zeichensatz (32 alphanumerische Zeichen, Kleinbuchstaben, ohne 'b', 'i', 'o', '1') wie bei nativen SegWit-Adressen. Er besteht aus zwei Teilen:
- Human-Readable Part (HRP): Kodiert das Netzwerk und optional den Betrag. Präfix
lnbcsteht für Mainnet,lntbfür Testnet. Der Betrag wird in Millisatoshi angegeben – der kleinsten Einheit im Lightning Network (1 Satoshi = 1.000 msat). - Data Part: Enthält einen Zeitstempel, eine Reihe von Tagged Fields sowie eine ECDSA-Signatur über den gesamten Invoice-Inhalt.
Tagged Fields: die Pflicht- und Optionalfelder im Detail
Die Tagged Fields sind das Herzstück der Invoice. Jedes Feld hat einen einbuchstabigen Typbezeichner:
p– Payment Hash (32 Byte, Pflichtfeld): Der SHA-256-Hash des sogenannten Payment Preimage. Dies ist das kryptografische Kernstück der Invoice.d– Description: Eine kurze Klartextbeschreibung des Zahlungszwecks.x– Ablaufzeit: Standardmäßig 3.600 Sekunden (1 Stunde). Nach Ablauf ist die Invoice ungültig.n– Node Public Key: Der öffentliche Schlüssel des Empfänger-Nodes (33 Byte).r– Routing Hints: Private Channel-Informationen, die dem Sender helfen, den Empfänger im Netzwerkgraphen zu finden. Für Nodes hinter privaten Channels sind diese Hints unverzichtbar – ohne sie kann der Sender keinen Zahlungspfad berechnen.h– Description Hash: SHA-256-Hash einer langen Beschreibung, wenn diese die Zeichenlimits desd-Felds überschreitet.
Das kryptografische Herzstück: Payment Hash und HTLC-Atomizität
Der Pay-for-Preimage-Mechanismus ist die Grundlage der Trustlessness im Lightning Network. Der Ablauf ist präzise: Der Empfänger erzeugt einen geheimen Zufallswert – das Payment Preimage – und berechnet dessen SHA-256-Hash. Dieser Hash landet als Pflichtfeld p in der Invoice. Der Sender baut entlang des Zahlungspfads eine Kette von Hashed Timelock Contracts (HTLCs) auf: Jeder Hop verpflichtet sich, einen Betrag weiterzuleiten, sobald das Preimage offenbart wird. Erst wenn der Empfänger das Preimage freigibt, lösen sich alle HTLCs atomar auf – die Zahlung ist entweder vollständig erfolgreich oder schlägt komplett fehl. Es gibt kein Teilrisiko.
Sicherheitsregel: Eine BOLT #11 Invoice darf exakt einmal bezahlt werden und verfällt nach der Ablaufzeit. Beides ist keine Einschränkung, sondern gewolltes Sicherheitsdesign: Einmaligkeit verhindert Replay-Angriffe, der Ablauf schützt vor hängenden HTLCs im Netzwerk.
LNURL und Lightning-Adressen: UX-Schichten über BOLT #11
Das größte UX-Problem von BOLT #11 Invoices ist ihre Einmaligkeit und Dynamik: Für jede Zahlung muss eine frische Invoice erzeugt werden – statische QR-Codes sind nicht möglich. Hier setzen zwei Protokollschichten an:
LNURL (definiert in den LNURL Documents, kurz LUDs) ist ein HTTP(S)-basiertes Protokoll. Eine LNURL kodiert eine Server-URL als Bech32-String. Der Wallet-Client dekodiert die URL, fragt den Server an und erhält als Antwort eine frische, gültige BOLT #11 Invoice – das eigentliche Zahlungsformat bleibt BOLT #11, aber der Austausch ist automatisiert.
Lightning-Adressen (LUD-16) gehen noch einen Schritt weiter: Das Format user@domain.com sieht aus wie eine E-Mail-Adresse und ist syntaktischer Zucker über LNURL-Pay. Der Client konstruiert daraus automatisch eine HTTPS-Anfrage an https://domain.com/.well-known/lnurlp/user und erhält vom Server eine frische Invoice – ohne dass der Nutzer eine URL kennen muss.
Vertrauensmodell-Unterschied: BOLT #11 ist trustless – Invoice-Gültigkeit und Zahlungsabwicklung erfordern keinen vertrauenswürdigen Dritten. LNURL und Lightning-Adressen hingegen erfordern einen funktionierenden Server, DNS-Auflösung und setzen damit Vertrauen in den Betreiber voraus. Fällt der Server aus oder ist er kompromittiert, können keine Zahlungen empfangen werden.
BOLT #12 Offers: statische Zahlungsanfragen ohne Serverabhängigkeit
Die langfristige Antwort auf das Statik-Problem ist BOLT #12 Offers: ein neuerer Standard für wiederverwendbare, statische Zahlungsanfragen direkt auf Protokollebene. Offers nutzen Onion-Messaging, um die Kommunikation zwischen Sender und Empfänger direkt durch das Lightning-Netzwerk zu routen – ohne externe Server, ohne DNS, ohne Custodial-Risiko. Stand 2026 ist BOLT #12 in Core Lightning (CLN) implementiert; die LND-Unterstützung befindet sich in Entwicklung, und der flächendeckende Wallet-Support ist noch nicht erreicht. BOLT #12 gilt jedoch als strategische Weiterentwicklung, die das Vertrauensmodell von LNURL auf Protokollebene löst.
Systemgrenzen im Überblick
- Einmaligkeit: Jede BOLT #11 Invoice kann nur einmal eingelöst werden.
- Ablauf: Standard 1 Stunde; danach ist die Invoice wertlos.
- Betragsbindung: Der kodierte Betrag ist fest; eine Zahlung über oder unter dem angegebenen Betrag wird abgelehnt.
- Routing-Abhängigkeit: Ohne ausreichende Liquidität und korrekte Routing Hints kann eine valide Invoice nicht bezahlbar sein.
- LNURL/LN-Adresse: Serverabhängigkeit, DNS-Risiko, potenzielle Zensurbarkeit einzelner Empfänger.
Weiterführend
Anyone wishing to receive a payment on the Lightning Network issues an invoice – a compact, cryptographically secured string containing all the information a sender needs to complete a payment. The underlying format is defined in BOLT #11 of the Lightning Network Specifications (LIGHTNING-RFC). Behind every lnbc… string lies a precisely structured data format with clear security guarantees.
Structure of a BOLT #11 Invoice: HRP and Data Part
A BOLT #11 invoice is a Bech32-encoded string – the same error-correcting character set (32 alphanumeric characters, lowercase, excluding 'b', 'i', 'o', '1') used for native SegWit addresses. It consists of two parts:
- Human-Readable Part (HRP): Encodes the network and optionally the amount. The prefix
lnbcdenotes Mainnet,lntbTestnet. Amounts are expressed in millisatoshi – the smallest unit in the Lightning Network (1 satoshi = 1,000 msat). - Data Part: Contains a timestamp, a set of tagged fields, and an ECDSA signature over the entire invoice content.
Tagged Fields: Mandatory and Optional Fields in Detail
The tagged fields are the core of the invoice. Each field has a single-letter type identifier:
p– Payment Hash (32 bytes, mandatory): The SHA-256 hash of the so-called payment preimage. This is the cryptographic centrepiece of the invoice.d– Description: A short plaintext description of the payment purpose.x– Expiry: Defaults to 3,600 seconds (1 hour). After expiry, the invoice is invalid.n– Node Public Key: The recipient node's public key (33 bytes).r– Routing Hints: Private channel information helping the sender locate the recipient in the network graph. For nodes behind private channels, these hints are indispensable – without them, the sender cannot compute a payment path.h– Description Hash: SHA-256 hash of a longer description when it exceeds the character limits of thedfield.
The Cryptographic Core: Payment Hash and HTLC Atomicity
The pay-for-preimage mechanism is the foundation of trustlessness in the Lightning Network. The process is precise: the recipient generates a secret random value – the payment preimage – and computes its SHA-256 hash. This hash is placed as the mandatory field p in the invoice. The sender then constructs a chain of Hashed Timelock Contracts (HTLCs) along the payment path: each hop commits to forwarding a certain amount as soon as the preimage is revealed. Only when the recipient releases the preimage do all HTLCs resolve atomically – the payment either succeeds in full or fails completely. There is no partial risk.
Security rule: A BOLT #11 invoice may be paid exactly once and expires after its set time limit. Both properties are deliberate security design decisions: single-use prevents replay attacks, and expiry protects against stuck HTLCs in the network.
LNURL and Lightning Addresses: UX Layers on Top of BOLT #11
The biggest UX problem with BOLT #11 invoices is their single-use, dynamic nature: a fresh invoice must be generated for each payment – static QR codes are not possible. Two protocol layers address this:
LNURL (defined in the LNURL Documents, or LUDs) is an HTTP(S)-based protocol. An LNURL encodes a server URL as a Bech32 string. The wallet client decodes the URL, queries the server, and receives a fresh, valid BOLT #11 invoice in response – the underlying payment format remains BOLT #11, but the exchange is automated.
Lightning Addresses (LUD-16) go one step further: the format user@domain.com looks like an email address and is syntactic sugar over LNURL-Pay. The client automatically constructs an HTTPS request to https://domain.com/.well-known/lnurlp/user and receives a fresh invoice from the server – without the user ever needing to know a URL.
Trust model difference: BOLT #11 is trustless – invoice validity and payment settlement require no trusted third party. LNURL and Lightning Addresses, however, depend on a functioning server and DNS resolution, introducing trust in the operator. If the server goes down or is compromised, payments cannot be received.
BOLT #12 Offers: Static Payment Requests Without Server Dependency
The long-term answer to the static-invoice problem is BOLT #12 Offers: a newer standard for reusable, static payment requests at the protocol level. Offers use onion messaging to route communication between sender and recipient directly through the Lightning network – no external servers, no DNS, no custodial risk. As of 2026, BOLT #12 is implemented in Core Lightning (CLN); LND support is under development, and universal wallet support has not yet been achieved. Nevertheless, BOLT #12 is widely regarded as the strategic evolution that resolves the trust model of LNURL at the protocol level.
System Limits at a Glance
- Single-use: Each BOLT #11 invoice can only be redeemed once.
- Expiry: Default 1 hour; after that, the invoice is worthless.
- Amount binding: The encoded amount is fixed; payments above or below the stated amount are rejected.
- Routing dependency: Without sufficient liquidity and correct routing hints, a valid invoice may not be payable.
- LNURL / Lightning Address: Server dependency, DNS risk, potential censurability of individual recipients.
Related
Quien desee recibir un pago en Lightning Network emite una invoice (factura de pago) — una cadena compacta y criptográficamente segura que contiene toda la información que el emisor necesita para completar el pago. El formato subyacente está definido en BOLT #11 de las Lightning Network Specifications (LIGHTNING-RFC). Detrás de cada cadena lnbc… se esconde una estructura de datos precisa con sólidas garantías de seguridad.
Estructura de una invoice BOLT #11: HRP y Data Part
Una invoice BOLT #11 es una cadena codificada en Bech32 — el mismo conjunto de caracteres con corrección de errores (32 caracteres alfanuméricos, en minúsculas, sin 'b', 'i', 'o', '1') que se utiliza en las direcciones SegWit nativas. Consta de dos partes:
- Human-Readable Part (HRP): Codifica la red y, opcionalmente, el importe. El prefijo
lnbccorresponde a Mainnet ylntba Testnet. El importe se expresa en millisatoshi — la unidad más pequeña de Lightning Network (1 satoshi = 1.000 msat). - Data Part: Contiene una marca de tiempo, un conjunto de campos etiquetados (tagged fields) y una firma ECDSA sobre el contenido completo de la invoice.
Tagged Fields: los campos obligatorios y opcionales en detalle
Los tagged fields son el núcleo de la invoice. Cada campo tiene un identificador de tipo de una sola letra:
p– Payment Hash (32 bytes, obligatorio): El hash SHA-256 del denominado payment preimage. Es la pieza criptográfica central de la invoice.d– Description: Una breve descripción en texto plano del propósito del pago.x– Tiempo de expiración: Por defecto, 3.600 segundos (1 hora). Tras su vencimiento, la invoice queda inválida.n– Node Public Key: La clave pública del nodo receptor (33 bytes).r– Routing Hints: Información de canales privados que ayuda al emisor a localizar al receptor en el grafo de la red. Para los nodos situados detrás de canales privados, estos hints son indispensables — sin ellos, el emisor no puede calcular una ruta de pago.h– Description Hash: Hash SHA-256 de una descripción larga cuando esta supera los límites de caracteres del campod.
El núcleo criptográfico: Payment Hash y atomicidad HTLC
El mecanismo pay-for-preimage es la base de la ausencia de confianza (trustlessness) en Lightning Network. El proceso es preciso: el receptor genera un valor aleatorio secreto — el payment preimage — y calcula su hash SHA-256. Ese hash se incluye como campo obligatorio p en la invoice. El emisor construye entonces una cadena de Hashed Timelock Contracts (HTLCs) a lo largo de la ruta de pago: cada salto se compromete a reenviar un importe en cuanto se revele el preimage. Solo cuando el receptor libera el preimage se resuelven todos los HTLCs de forma atómica — el pago tiene éxito por completo o falla en su totalidad. No existe riesgo parcial.
Regla de seguridad: Una invoice BOLT #11 solo puede pagarse exactamente una vez y expira tras su tiempo límite. Ambas propiedades son decisiones de diseño de seguridad deliberadas: el uso único previene los ataques de repetición (replay attacks), y la expiración protege contra HTLCs bloqueados en la red.
LNURL y Lightning Addresses: capas de UX sobre BOLT #11
El mayor problema de UX de las invoices BOLT #11 es su naturaleza dinámica y de un solo uso: debe generarse una invoice nueva para cada pago, por lo que los códigos QR estáticos no son posibles. Dos capas de protocolo abordan este problema:
LNURL (definido en los LNURL Documents, o LUDs) es un protocolo basado en HTTP(S). Una LNURL codifica una URL de servidor como cadena Bech32. El cliente de la billetera decodifica la URL, consulta al servidor y recibe como respuesta una invoice BOLT #11 nueva y válida — el formato de pago subyacente sigue siendo BOLT #11, pero el intercambio está automatizado.
Las Lightning Addresses (LUD-16) van un paso más allá: el formato user@domain.com tiene el aspecto de una dirección de correo electrónico y es azúcar sintáctico sobre LNURL-Pay. El cliente construye automáticamente una solicitud HTTPS a https://domain.com/.well-known/lnurlp/user y recibe del servidor una invoice nueva — sin que el usuario necesite conocer ninguna URL.
Diferencia en el modelo de confianza: BOLT #11 es trustless — la validez de la invoice y la liquidación del pago no requieren ningún tercero de confianza. LNURL y las Lightning Addresses, en cambio, dependen de un servidor operativo y de la resolución DNS, lo que introduce confianza en el operador. Si el servidor cae o se ve comprometido, no se pueden recibir pagos.
BOLT #12 Offers: solicitudes de pago estáticas sin dependencia de servidor
La respuesta a largo plazo al problema de las invoices estáticas son las BOLT #12 Offers: un estándar más reciente para solicitudes de pago reutilizables y estáticas directamente a nivel de protocolo. Las Offers emplean onion messaging para enrutar la comunicación entre emisor y receptor directamente a través de la red Lightning — sin servidores externos, sin DNS y sin riesgo de custodia. A fecha de 2026, BOLT #12 está implementado en Core Lightning (CLN); el soporte en LND se encuentra en desarrollo y el soporte generalizado en billeteras aún no se ha alcanzado. No obstante, BOLT #12 se considera la evolución estratégica que resuelve el modelo de confianza de LNURL a nivel de protocolo.
Limitaciones del sistema de un vistazo
- Uso único: Cada invoice BOLT #11 solo puede canjearse una vez.
- Expiración: Por defecto, 1 hora; transcurrido ese tiempo, la invoice no tiene valor.
- Vinculación al importe: El importe codificado es fijo; los pagos por encima o por debajo del importe indicado son rechazados.
- Dependencia de enrutamiento: Sin liquidez suficiente y routing hints correctos, una invoice válida puede no ser pagable.
- LNURL / Lightning Address: Dependencia del servidor, riesgo de DNS, posible censurabilidad de receptores individuales.
Más información
Quem deseja receber um pagamento na Lightning Network emite uma Invoice – uma string compacta e criptograficamente segura que contém todas as informações de que um remetente precisa para efetuar o pagamento. O formato subjacente é definido no BOLT #11 das Lightning Network Specifications (LIGHTNING-RFC). Por trás de cada string lnbc… existe uma estrutura de dados precisa com garantias de segurança bem definidas.
Estrutura de uma Invoice BOLT #11: HRP e Data Part
Uma Invoice BOLT #11 é uma string codificada em Bech32 – o mesmo conjunto de caracteres com correção de erros (32 caracteres alfanuméricos, minúsculos, excluindo 'b', 'i', 'o', '1') utilizado nos endereços SegWit nativos. É composta por duas partes:
- Human-Readable Part (HRP): Codifica a rede e, opcionalmente, o valor. O prefixo
lnbcindica a Mainnet,lntba Testnet. O valor é expresso em millisatoshi – a menor unidade da Lightning Network (1 satoshi = 1.000 msat). - Data Part: Contém um timestamp, um conjunto de Tagged Fields e uma assinatura ECDSA sobre todo o conteúdo da Invoice.
Tagged Fields: os campos obrigatórios e opcionais em detalhe
Os Tagged Fields são o núcleo da Invoice. Cada campo possui um identificador de tipo com uma única letra:
p– Payment Hash (32 bytes, obrigatório): O hash SHA-256 do chamado Payment Preimage. Este é o elemento criptográfico central da Invoice.d– Description: Uma breve descrição em texto simples da finalidade do pagamento.x– Prazo de validade: Por padrão, 3.600 segundos (1 hora). Após o vencimento, a Invoice é inválida.n– Node Public Key: A chave pública do nó destinatário (33 bytes).r– Routing Hints: Informações sobre canais privados que auxiliam o remetente a localizar o destinatário no grafo da rede. Para nós atrás de canais privados, esses hints são indispensáveis – sem eles, o remetente não consegue calcular um caminho de pagamento.h– Description Hash: Hash SHA-256 de uma descrição longa, quando esta ultrapassa o limite de caracteres do campod.
O núcleo criptográfico: Payment Hash e atomicidade dos HTLCs
O mecanismo pay-for-preimage é a base da ausência de confiança (trustlessness) na Lightning Network. O processo é preciso: o destinatário gera um valor aleatório secreto – o Payment Preimage – e calcula o seu hash SHA-256. Esse hash é inserido como campo obrigatório p na Invoice. O remetente constrói, ao longo do caminho de pagamento, uma cadeia de Hashed Timelock Contracts (HTLCs): cada salto (hop) compromete-se a encaminhar um valor assim que o preimage for revelado. Somente quando o destinatário libera o preimage todos os HTLCs se resolvem atomicamente – o pagamento é bem-sucedido na totalidade ou falha completamente. Não existe risco parcial.
Regra de segurança: Uma Invoice BOLT #11 pode ser paga exatamente uma vez e expira após o prazo definido. Ambas as propriedades são decisões deliberadas de design de segurança: o uso único previne ataques de replay, e o prazo de validade protege contra HTLCs suspensos na rede.
LNURL e Lightning Addresses: camadas de UX sobre o BOLT #11
O maior problema de UX das Invoices BOLT #11 é a sua natureza de uso único e dinâmica: é necessário gerar uma nova Invoice para cada pagamento – QR codes estáticos não são possíveis. Duas camadas de protocolo abordam essa questão:
LNURL (definido nos LNURL Documents, abreviados como LUDs) é um protocolo baseado em HTTP(S). Um LNURL codifica uma URL de servidor como uma string Bech32. O cliente da carteira decodifica a URL, consulta o servidor e recebe como resposta uma Invoice BOLT #11 nova e válida – o formato de pagamento subjacente continua sendo BOLT #11, mas o processo é automatizado.
Lightning Addresses (LUD-16) vão um passo além: o formato user@domain.com tem a aparência de um endereço de e-mail e é um açúcar sintático sobre o LNURL-Pay. O cliente constrói automaticamente uma requisição HTTPS para https://domain.com/.well-known/lnurlp/user e recebe do servidor uma Invoice nova – sem que o utilizador precise conhecer qualquer URL.
Diferença no modelo de confiança: O BOLT #11 é trustless – a validade da Invoice e a liquidação do pagamento não requerem terceiros de confiança. Já o LNURL e as Lightning Addresses dependem de um servidor em funcionamento e de resolução DNS, introduzindo confiança no operador. Se o servidor ficar indisponível ou for comprometido, os pagamentos não poderão ser recebidos.
BOLT #12 Offers: pedidos de pagamento estáticos sem dependência de servidor
A resposta de longo prazo ao problema da estaticidade é o BOLT #12 Offers: um padrão mais recente para pedidos de pagamento reutilizáveis e estáticos diretamente ao nível do protocolo. As Offers utilizam Onion Messaging para encaminhar a comunicação entre remetente e destinatário diretamente pela rede Lightning – sem servidores externos, sem DNS, sem risco de custódia. Em 2026, o BOLT #12 está implementado no Core Lightning (CLN); o suporte no LND encontra-se em desenvolvimento e o suporte generalizado por carteiras ainda não foi alcançado. Ainda assim, o BOLT #12 é amplamente considerado a evolução estratégica que resolve o modelo de confiança do LNURL ao nível do protocolo.
Limites do sistema em resumo
- Uso único: Cada Invoice BOLT #11 só pode ser resgatada uma vez.
- Validade: Padrão de 1 hora; após esse período, a Invoice perde o valor.
- Valor fixo: O valor codificado é imutável; pagamentos acima ou abaixo do valor indicado são rejeitados.
- Dependência de routing: Sem liquidez suficiente e Routing Hints corretos, uma Invoice válida pode não ser pagável.
- LNURL / Lightning Address: Dependência de servidor, risco de DNS, potencial censurabilidade de destinatários individuais.
Mais informação
Lightning Networkで支払いを受け取りたい人は、インボイスを発行します。これは、送信者が支払いを完了するために必要なすべての情報を含む、コンパクトかつ暗号学的に保護された文字列です。基盤となるフォーマットは、Lightning Network仕様書（LIGHTNING-RFC）のBOLT #11で定義されています。すべてのlnbc…文字列の背後には、明確なセキュリティ保証を持つ精密なデータ構造があります。
BOLT #11インボイスの構造：HRPとデータパート
BOLT #11インボイスはBech32エンコードされた文字列です。これはネイティブSegWitアドレスと同じ誤り訂正文字セット（32文字の英数字、小文字、'b'・'i'・'o'・'1'を除く）です。2つの部分で構成されます：
- Human-Readable Part（HRP）：ネットワークと任意で金額をエンコードします。プレフィックス
lnbcはMainnetを、lntbはTestnetを表します。金額はミリサトシで表記されます。これはLightning Networkにおける最小単位です（1 satoshi = 1,000 msat）。 - データパート：タイムスタンプ、一連のタグ付きフィールド、およびインボイス全体の内容に対するECDSA署名が含まれます。
タグ付きフィールド：必須フィールドとオプションフィールドの詳細
タグ付きフィールドはインボイスの核心です。各フィールドには1文字のタイプ識別子があります：
p– Payment Hash（32バイト、必須）：いわゆるPayment PreimageのSHA-256ハッシュ。これはインボイスの暗号学的な中核です。d– Description：支払い目的の短いプレーンテキストによる説明。x– 有効期限：デフォルトは3,600秒（1時間）。期限切れ後はインボイスが無効になります。n– Node Public Key：受信ノードの公開鍵（33バイト）。r– Routing Hints：送信者がネットワークグラフ上で受信者を特定するのを助けるプライベートチャネル情報。プライベートチャネルの背後にあるノードにとって、このヒントは不可欠です。なければ送信者は支払い経路を計算できません。h– Description Hash：dフィールドの文字数制限を超える長い説明のSHA-256ハッシュ。
暗号学的な核心：Payment HashとHTLCのアトミック性
pay-for-preimageメカニズムは、Lightning Networkにおけるトラストレス性の基盤です。その仕組みは次のとおりです：受信者が秘密のランダム値（Payment Preimage）を生成し、そのSHA-256ハッシュを計算します。このハッシュがインボイスの必須フィールドpとして格納されます。送信者は支払い経路に沿ってHashed Timelock Contracts（HTLC）のチェーンを構築します。各ホップはPreimageが公開された時点で一定額を転送することを約束します。受信者がPreimageを公開して初めて、すべてのHTLCがアトミックに解決されます。支払いは完全に成功するか、完全に失敗するかのどちらかです。部分的なリスクは存在しません。
セキュリティルール：BOLT #11インボイスは正確に1回だけ支払い可能であり、有効期限後は失効します。どちらも制約ではなく、意図されたセキュリティ設計です。単回使用はリプレイ攻撃を防ぎ、有効期限はネットワーク内でHTLCが宙吊りになるのを防ぎます。
LNURLとLightningアドレス：BOLT #11上のUXレイヤー
BOLT #11インボイスの最大のUX上の問題は、その単回使用かつ動的な性質にあります。支払いごとに新しいインボイスを生成しなければならず、静的なQRコードは使用できません。これに対応するために2つのプロトコルレイヤーが存在します：
LNURL（LNURL Documents、略称LUDsで定義）はHTTP(S)ベースのプロトコルです。LNURLはサーバーURLをBech32文字列としてエンコードします。ウォレットクライアントはURLをデコードし、サーバーに問い合わせ、応答として新鮮で有効なBOLT #11インボイスを受け取ります。基盤となる支払いフォーマットはBOLT #11のままですが、やり取りは自動化されます。
Lightningアドレス（LUD-16）はさらに一歩進んでいます：user@domain.comというフォーマットはメールアドレスのように見え、LNURL-Payの上に構築されたシンタックスシュガーです。クライアントは自動的にhttps://domain.com/.well-known/lnurlp/userへHTTPSリクエストを構築し、サーバーから新鮮なインボイスを受け取ります。ユーザーはURLを意識する必要がありません。
信頼モデルの違い：BOLT #11はトラストレスです。インボイスの有効性と支払い決済に信頼できる第三者は必要ありません。一方、LNURLとLightningアドレスは機能するサーバーとDNS解決に依存するため、運営者への信頼が前提となります。サーバーがダウンしたり侵害されたりした場合、支払いを受け取れなくなります。
BOLT #12 Offers：サーバー依存なしの静的な支払いリクエスト
静的インボイス問題への長期的な解答がBOLT #12 Offersです。これはプロトコルレベルで再利用可能な静的支払いリクエストを実現する新しい標準です。Offersはオニオンメッセージングを活用し、送信者と受信者の通信を外部サーバーもDNSもカストディアルリスクもなしに、Lightning Network内で直接ルーティングします。2026年時点で、BOLT #12はCore Lightning（CLN）に実装されており、LNDのサポートは開発中で、全面的なウォレットサポートはまだ達成されていません。しかしBOLT #12は、LNURLの信頼モデルをプロトコルレベルで解決する戦略的な発展として広く認識されています。
システム上の制限：概要
- 単回使用：各BOLT #11インボイスは1回しか使用できません。
- 有効期限：デフォルトは1時間。それ以降はインボイスは無効となります。
- 金額の固定：エンコードされた金額は固定であり、指定金額を上回るまたは下回る支払いは拒否されます。
- ルーティング依存：十分な流動性と正確なルーティングヒントがなければ、有効なインボイスでも支払い不能になる場合があります。
- LNURL / Lightningアドレス：サーバー依存、DNSリスク、個々の受信者に対する検閲の可能性。
関連情報
在 Lightning Network 上希望收款的人需要出具一张 Invoice——一个紧凑的、经过密码学保护的字符串，包含发送方完成付款所需的全部信息。其底层格式由 Lightning Network 规范（LIGHTNING-RFC）中的 BOLT #11 定义。每一个 lnbc… 字符串背后都是一套结构精确、具有明确安全保证的数据格式。
BOLT #11 Invoice 的结构：HRP 与 Data Part
BOLT #11 Invoice 是一个 Bech32 编码的字符串——与原生 SegWit 地址所用的相同纠错字符集（32 个字母数字字符，小写，不含 'b'、'i'、'o'、'1'）。它由两部分组成：
- Human-Readable Part（HRP）：编码网络信息以及可选的金额。前缀
lnbc代表主网，lntb代表测试网。金额以毫聪（millisatoshi）表示——Lightning Network 中的最小单位（1 聪 = 1,000 msat）。 - Data Part：包含时间戳、一组 Tagged Fields 以及对整个 Invoice 内容的 ECDSA 签名。
Tagged Fields：必填字段与可选字段详解
Tagged Fields 是 Invoice 的核心。每个字段都有一个单字母类型标识符：
p– Payment Hash（32 字节，必填）：即所谓 Payment Preimage 的 SHA-256 哈希值，是 Invoice 的密码学核心。d– Description：对付款用途的简短明文描述。x– 过期时间：默认为 3,600 秒（1 小时），过期后 Invoice 即告无效。n– Node Public Key：收款节点的公钥（33 字节）。r– Routing Hints：私有通道信息，帮助发送方在网络图中定位收款方。对于位于私有通道后的节点，这些 Hints 不可或缺——没有它们，发送方将无法计算付款路径。h– Description Hash：当描述内容超过d字段的字符限制时，存储较长描述的 SHA-256 哈希值。
密码学核心：Payment Hash 与 HTLC 原子性
预映像兑付机制（Pay-for-Preimage）是 Lightning Network 无需信任特性的基础。流程如下：收款方生成一个秘密随机值——即 Payment Preimage——并计算其 SHA-256 哈希值。该哈希值作为必填字段 p 写入 Invoice。发送方随后沿付款路径构建一条 哈希时间锁合约（HTLCs）链：每个跳点承诺在 Preimage 披露后转发相应金额。只有当收款方释放 Preimage 时，所有 HTLC 才会原子性地结算——付款要么完全成功，要么彻底失败，不存在部分风险。
安全规则：一张 BOLT #11 Invoice 只能被支付 一次，并在过期时间后失效。这两点并非限制，而是有意为之的安全设计：单次使用防止重放攻击，过期机制保护网络免受悬挂 HTLC 的影响。
LNURL 与 Lightning 地址：BOLT #11 之上的用户体验层
BOLT #11 Invoice 最大的用户体验问题在于其单次性与动态性：每笔付款都必须生成一张全新的 Invoice，静态二维码因此无从实现。针对这一问题，两个协议层应运而生：
LNURL（定义于 LNURL Documents，简称 LUDs）是一种基于 HTTP(S) 的协议。LNURL 将服务器 URL 编码为 Bech32 字符串。钱包客户端解码该 URL 后向服务器发起请求，并获得一张新鲜有效的 BOLT #11 Invoice 作为响应——底层支付格式仍为 BOLT #11，但整个交换过程是自动化的。
Lightning 地址（LUD-16）更进一步：user@domain.com 格式看似电子邮件地址，实为 LNURL-Pay 之上的语法糖。客户端自动将其转换为向 https://domain.com/.well-known/lnurlp/user 发出的 HTTPS 请求，并从服务器获取一张新鲜的 Invoice——用户无需了解任何 URL。
信任模型差异：BOLT #11 是无需信任的——Invoice 有效性与支付结算无需可信第三方。而 LNURL 和 Lightning 地址则依赖正常运行的服务器与 DNS 解析，因此需要信任服务器运营方。若服务器宕机或遭到攻击，将无法收款。
BOLT #12 Offers：无需服务器依赖的静态付款请求
解决静态 Invoice 问题的长期方案是 BOLT #12 Offers：一种在协议层面实现可复用静态付款请求的新标准。Offers 利用 洋葱消息（Onion Messaging），直接通过 Lightning 网络路由发送方与收款方之间的通信——无需外部服务器，无需 DNS，无托管风险。截至 2026 年，BOLT #12 已在 Core Lightning（CLN）中实现；LND 的支持仍在开发中，全面的钱包支持尚未达到。尽管如此，BOLT #12 被普遍视为从协议层面解决 LNURL 信任模型问题的战略性演进。
系统限制概览
- 单次性：每张 BOLT #11 Invoice 只能兑付一次。
- 过期：默认 1 小时；过期后 Invoice 即告作废。
- 金额绑定：编码金额固定；高于或低于指定金额的付款均会被拒绝。
- 路由依赖：若流动性不足或 Routing Hints 不正确，有效的 Invoice 也可能无法完成支付。
- LNURL / Lightning 地址：依赖服务器、存在 DNS 风险，单个收款方可能面临潜在的审查风险。
延伸阅读
من يرغب في استقبال دفعة عبر شبكة Lightning يُصدر فاتورة (Invoice) – وهي سلسلة نصية مضغوطة ومؤمَّنة تشفيريًا، تحتوي على جميع المعلومات التي يحتاجها المُرسل لإتمام الدفعة. يُعرَّف الشكل الأساسي لهذه الفاتورة في BOLT #11 ضمن مواصفات شبكة Lightning (LIGHTNING-RFC). خلف كل سلسلة lnbc… تكمن بنية بيانات دقيقة تتمتع بضمانات أمنية واضحة.
بنية فاتورة BOLT #11: الجزء المقروء (HRP) وجزء البيانات
فاتورة BOLT #11 هي سلسلة مُرمَّزة بـ Bech32 – وهو نفس مجموعة الأحرف ذاتها المُصحِّحة للأخطاء (32 حرفًا أبجديًا رقميًا، بأحرف صغيرة، باستثناء 'b' و'i' و'o' و'1') المستخدمة في عناوين SegWit الأصلية. وتتكوّن من جزأين:
- الجزء المقروء للإنسان (HRP): يُرمِّز الشبكة والمبلغ اختياريًا. البادئة
lnbcتدل على الشبكة الرئيسية (Mainnet)، وlntbعلى شبكة الاختبار (Testnet). يُعبَّر عن المبلغ بوحدة millisatoshi – وهي أصغر وحدة في شبكة Lightning (1 Satoshi = 1,000 msat). - جزء البيانات (Data Part): يحتوي على طابع زمني، ومجموعة من الحقول المُصنَّفة (Tagged Fields)، وتوقيع ECDSA على كامل محتوى الفاتورة.
الحقول المُصنَّفة: الحقول الإلزامية والاختيارية بالتفصيل
الحقول المُصنَّفة هي جوهر الفاتورة. لكل حقل معرِّف نوع مكوَّن من حرف واحد:
p– Payment Hash (32 بايت، إلزامي): تجزئة SHA-256 لما يُعرف بـ Payment Preimage. هذا هو الجوهر التشفيري للفاتورة.d– الوصف (Description): وصف نصي مختصر بصيغة نص عادي لغرض الدفعة.x– وقت الانتهاء (Expiry): الافتراضي 3,600 ثانية (ساعة واحدة). بعد انتهاء هذه المدة، تصبح الفاتورة غير صالحة.n– المفتاح العام للعقدة (Node Public Key): المفتاح العام لعقدة المستقبِل (33 بايت).r– تلميحات التوجيه (Routing Hints): معلومات القنوات الخاصة التي تُساعد المُرسل على تحديد موقع المستقبِل في رسم الشبكة. بالنسبة للعقد الواقعة خلف قنوات خاصة، هذه التلميحات لا غنى عنها – فبدونها لا يستطيع المُرسل حساب مسار الدفعة.h– تجزئة الوصف (Description Hash): تجزئة SHA-256 لوصف طويل عندما يتجاوز حدود الأحرف المسموح بها في الحقلd.
الجوهر التشفيري: Payment Hash وذرية HTLC
آلية الدفع مقابل الـ Preimage (Pay-for-Preimage) هي الأساس الذي تقوم عليه خاصية انعدام الحاجة إلى الثقة في شبكة Lightning. تسير العملية على النحو الدقيق التالي: يُنشئ المستقبِل قيمة عشوائية سرية – هي Payment Preimage – ثم يحسب تجزئة SHA-256 لها. تُوضع هذه التجزئة كحقل إلزامي p في الفاتورة. يقوم المُرسل بعدها ببناء سلسلة من عقود القفل الزمني المُجزَّأة (HTLCs) على امتداد مسار الدفعة: يلتزم كل hop بإعادة توجيه مبلغ معين فور الكشف عن الـ Preimage. وفور إفصاح المستقبِل عن الـ Preimage، تنحل جميع الـ HTLCs بشكل ذري – فإما أن تنجح الدفعة كاملةً أو تفشل كليًا. لا وجود لأي مخاطرة جزئية.
قاعدة أمنية: يجوز دفع فاتورة BOLT #11 مرة واحدة فحسب، وتنتهي صلاحيتها بعد المدة المحددة. كلا الأمرين ليس قيدًا، بل تصميم أمني مقصود: الاستخدام الفردي يمنع هجمات إعادة التشغيل (Replay Attacks)، وانتهاء الصلاحية يحمي من تعليق الـ HTLCs في الشبكة.
LNURL وعناوين Lightning: طبقات تجربة المستخدم فوق BOLT #11
أكبر مشكلة في تجربة المستخدم مع فواتير BOLT #11 هي طابعها الفردي والديناميكي: إذ يجب إنشاء فاتورة جديدة لكل دفعة، مما يجعل رموز QR الثابتة مستحيلة. وهنا يتدخل مستويان من البروتوكولات:
LNURL (المُعرَّف في وثائق LNURL، اختصارًا LUDs) هو بروتوكول قائم على HTTP(S). يُرمِّز LNURL رابط URL لخادم ما بصيغة سلسلة Bech32. يقوم عميل المحفظة بفك تشفير الرابط، واستعلام الخادم، ليتلقى في الاستجابة فاتورة BOLT #11 جديدة وصالحة – يبقى تنسيق الدفع الأساسي BOLT #11، لكن عملية التبادل تتم آليًا.
عناوين Lightning (LUD-16) تذهب خطوة أبعد: تنسيق user@domain.com يبدو كعنوان بريد إلكتروني وهو سكر نحوي (Syntactic Sugar) فوق LNURL-Pay. يبني العميل تلقائيًا طلب HTTPS إلى https://domain.com/.well-known/lnurlp/user ويتلقى من الخادم فاتورة جديدة – دون أن يحتاج المستخدم إلى معرفة أي رابط URL.
الفرق في نموذج الثقة: BOLT #11 لا يستلزم ثقة (Trustless) – فصلاحية الفاتورة وتسوية الدفعة لا تتطلبان طرفًا ثالثًا موثوقًا به. أما LNURL وعناوين Lightning فتعتمد على خادم يعمل بشكل صحيح وعلى نظام DNS، مما يستوجب الثقة في المشغِّل. إن توقف الخادم أو تعرَّض للاختراق، لن يتمكن المستخدم من استقبال أي دفعات.
BOLT #12 Offers: طلبات دفع ثابتة بدون اعتماد على خادم
الحل طويل الأمد لمشكلة الفواتير الثابتة هو BOLT #12 Offers: معيار أحدث لطلبات الدفع القابلة لإعادة الاستخدام والثابتة مباشرةً على مستوى البروتوكول. تستخدم Offers رسائل البصل (Onion Messaging) لتوجيه الاتصال بين المُرسل والمستقبِل مباشرةً عبر شبكة Lightning – بدون خوادم خارجية، وبدون DNS، وبدون مخاطر الحضانة (Custodial Risk). حتى عام 2026، يُطبَّق BOLT #12 في Core Lightning (CLN)؛ فيما لا يزال دعم LND قيد التطوير، ولم يتحقق بعد دعم المحافظ على نطاق واسع. غير أن BOLT #12 يُعدّ التطور الاستراتيجي الذي يحل إشكالية نموذج الثقة في LNURL على مستوى البروتوكول.
حدود النظام في لمحة
- الاستخدام الفردي: يمكن استرداد كل فاتورة BOLT #11 مرة واحدة فقط.
- انتهاء الصلاحية: ساعة واحدة افتراضيًا؛ بعدها تصبح الفاتورة عديمة القيمة.
- ارتباط المبلغ: المبلغ المُرمَّز ثابت؛ تُرفض أي دفعة تزيد أو تنقص عن المبلغ المحدد.
- الاعتماد على التوجيه: بدون سيولة كافية وتلميحات توجيه صحيحة، قد لا تكون الفاتورة الصالحة قابلة للدفع.
- LNURL / عنوان Lightning: اعتماد على الخادم، مخاطر DNS، إمكانية الرقابة على مستقبِلين بعينهم.
مزيد من المعلومات
⚖️ Die stärksten GegenargumenteThe Strongest CounterargumentsLos contraargumentos más fuertesOs contra-argumentos mais fortes最も強力な反論最有力的反方观点أقوى الحجج المضادة
Jedes Gegenargument in seiner stärksten Form – geprüft und nach Datenlage entschieden, kein Wunschdenken.Each counterargument in its strongest form – scrutinized and adjudicated per the data, no wishful thinking.Cada contraargumento en su forma más fuerte: examinado y juzgado según los datos, sin ilusiones.Cada contra-argumento na sua forma mais forte – examinado e julgado segundo os dados, sem ilusões.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定，绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
Die Aussage „kein Teilrisiko" ist idealisiert: Zahlungen können als Stuck HTLCs stunden- bis tagelang in der Schwebe hängen und Kapital des Senders bis zum Timeout binden – die Atomizität gilt erst am Ende, nicht während des Flugs.The claim of no partial risk is idealized: payments can hang in limbo as stuck HTLCs for hours to days, locking the sender's funds until timeout — atomicity holds only at the end, not while the payment is in flight.La afirmación de que no hay riesgo parcial es idealizada: los pagos pueden quedar en el limbo como HTLC atascados durante horas o días, bloqueando los fondos del emisor hasta el timeout; la atomicidad se cumple solo al final, no mientras el pago está en vuelo.A afirmação de que não há risco parcial é idealizada: pagamentos podem ficar no limbo como HTLCs travados por horas ou dias, bloqueando os fundos do remetente até o timeout — a atomicidade vale apenas no final, não enquanto o pagamento está em trânsito.「部分的リスクはない」という記述は理想化されている。支払いはStuck HTLCとして数時間から数日間宙づりになり、タイムアウトまで送信者の資金を拘束しうる。原子性が成立するのは最終的にであって、送金の途中ではない。「不存在部分风险」的说法过于理想化:支付可能作为卡住的HTLC悬置数小时甚至数天,在超时之前锁住发送方的资金——原子性只在最终结算时成立,而非支付在途期间。القول بانعدام المخاطر الجزئية مثالي أكثر من اللازم: فقد تبقى المدفوعات معلقة كعقود HTLC عالقة لساعات أو أيام، حاجزة أموال المرسل حتى انتهاء المهلة — فالذرية تتحقق في النهاية فقط، لا أثناء مرور الدفعة.
Belegt: Stuck Payments sind ein in der Lightning-Entwicklung ausführlich dokumentiertes Praxisphänomen und Gegenstand laufender Protokolldiskussionen. Die uneingeschränkte Atomizitätsdarstellung des Artikels blendet dieses Zeitwert- und Liquiditätsrisiko aus, auch wenn am Ende tatsächlich niemand Geld verliert.Substantiated: stuck payments are a practice phenomenon extensively documented in Lightning development and the subject of ongoing protocol discussions. The article's unqualified atomicity claim glosses over this time-value and liquidity risk, even though ultimately no one loses funds.Confirmado: los pagos atascados son un fenómeno práctico ampliamente documentado en el desarrollo de Lightning y objeto de discusiones de protocolo en curso. La afirmación de atomicidad sin matices del artículo omite este riesgo de valor temporal y liquidez, aunque al final nadie pierda fondos.Confirmado: pagamentos travados são um fenômeno prático amplamente documentado no desenvolvimento do Lightning e objeto de discussões de protocolo em andamento. A afirmação de atomicidade sem ressalvas do artigo ignora esse risco de valor temporal e liquidez, ainda que no final ninguém perca fundos.立証済み:Stuck PaymentはLightning開発において広く文書化された実務上の現象であり、現在も続くプロトコル議論の対象である。最終的に誰も資金を失わないとはいえ、記事の無条件な原子性の記述は、この時間価値と流動性のリスクを覆い隠している。成立:卡住的支付是Lightning开发中被大量记录的实践现象,也是持续的协议讨论议题。即便最终无人损失资金,文章不加限定的原子性表述仍掩盖了这种时间价值与流动性风险。مثبت: المدفوعات العالقة ظاهرة عملية موثقة باستفاضة في تطوير Lightning وموضوع نقاشات بروتوكولية مستمرة. وصف المقال غير المشروط للذرية يطمس مخاطر القيمة الزمنية والسيولة هذه، وإن لم يخسر أحد أمواله في النهاية.
Die Invoice selbst ist ein Privatsphäre-Leck: Eine BOLT #11 Invoice legt den Node Public Key des Empfängers, den Betrag und die Beschreibung im Klartext offen, und Routing Hints verraten private Kanäle – wer den String sieht, kennt den Empfänger.The invoice itself is a privacy leak: a BOLT #11 invoice exposes the recipient's node public key, the amount, and the description in plaintext, and routing hints reveal private channels — whoever sees the string knows the recipient.La propia invoice es una fuga de privacidad: una invoice BOLT #11 expone en claro la clave pública del nodo receptor, el importe y la descripción, y los routing hints revelan canales privados; quien vea la cadena conoce al receptor.A própria invoice é um vazamento de privacidade: uma invoice BOLT #11 expõe em texto claro a chave pública do node do recebedor, o valor e a descrição, e os routing hints revelam canais privados — quem vê a string conhece o recebedor.インボイス自体がプライバシーの漏洩点である。BOLT #11インボイスは受取人のノード公開鍵、金額、説明文を平文で開示し、Routing Hintsはプライベートチャネルを暴露する。文字列を見た者は受取人を特定できる。发票本身就是隐私泄露点:BOLT #11发票以明文暴露收款方的节点公钥、金额和描述,Routing Hints还会泄露私有通道——任何看到该字符串的人都能识别收款方。الفاتورة نفسها ثغرة خصوصية: تكشف فاتورة BOLT #11 المفتاح العام لعقدة المستلم والمبلغ والوصف بنص صريح، وتفضح تلميحات التوجيه القنوات الخاصة — فمن يرى السلسلة يعرف المستلم.
Belegt: Diese Felder sind per BOLT #11-Spezifikation Bestandteil der Invoice und für jeden dekodierbar. Der Artikel verspricht im Teaser „strikte Sicherheitsregeln", benennt diese strukturelle Empfänger-Privatsphäre-Grenze aber an keiner Stelle.Substantiated: per the BOLT #11 specification these fields are part of the invoice and decodable by anyone. The teaser promises strict security rules, yet the article never names this structural limit on recipient privacy.Confirmado: según la especificación BOLT #11, esos campos forman parte de la invoice y cualquiera puede decodificarlos. El avance promete reglas de seguridad estrictas, pero el artículo nunca menciona este límite estructural de la privacidad del receptor.Confirmado: pela especificação BOLT #11, esses campos fazem parte da invoice e podem ser decodificados por qualquer um. O teaser promete regras de segurança estritas, mas o artigo nunca menciona esse limite estrutural da privacidade do recebedor.立証済み:BOLT #11の仕様上、これらのフィールドはインボイスの一部であり、誰でもデコードできる。ティーザーは「厳格なセキュリティルール」を約束しているが、記事は受取人プライバシーのこの構造的限界に一度も触れていない。成立:按BOLT #11规范,这些字段是发票的组成部分,任何人都能解码。导语承诺「严格的安全规则」,但文章从未提及收款方隐私的这一结构性局限。مثبت: بحسب مواصفة BOLT #11 هذه الحقول جزء من الفاتورة ويمكن لأي شخص فك ترميزها. تعد المقدمة بقواعد أمان صارمة، لكن المقال لا يذكر أبدا هذا الحد البنيوي لخصوصية المستلم.
BOLT #12 als „strategische Antwort" könnte Nische bleiben: LNURL dominiert gerade deshalb, weil das Server-Modell für Web-Integration, Metadaten und Händler-Workflows praktisch überlegen ist – Protokollreinheit allein erzwingt keine Adoption.BOLT #12 as the strategic answer may remain a niche: LNURL dominates precisely because the server model is practically superior for web integration, metadata, and merchant workflows — protocol purity alone does not force adoption.BOLT #12 como respuesta estratégica podría quedarse en un nicho: LNURL domina precisamente porque el modelo de servidor es superior en la práctica para integración web, metadatos y flujos de comercio; la pureza de protocolo por sí sola no fuerza la adopción.O BOLT #12 como resposta estratégica pode permanecer um nicho: o LNURL domina justamente porque o modelo de servidor é superior na prática para integração web, metadados e fluxos de comerciantes — pureza de protocolo, por si só, não força adoção.「戦略的な答え」としてのBOLT #12はニッチにとどまる可能性がある。LNURLが支配的なのは、Web統合・メタデータ・加盟店ワークフローにおいてサーバーモデルが実務的に優れているからであり、プロトコルの純粋さだけでは普及は強制できない。作为「战略性答案」的BOLT #12可能始终停留在小众:LNURL之所以占主导,正是因为服务器模式在网页集成、元数据和商户流程上更具实用优势——仅靠协议上的纯粹性无法强制普及。قد يبقى BOLT #12 بوصفه الجواب الاستراتيجي خيارا هامشيا: يهيمن LNURL تحديدا لأن نموذج الخادم متفوق عمليا في التكامل مع الويب والبيانات الوصفية ومسارات عمل التجار — ونقاء البروتوكول وحده لا يفرض التبني.
Offen: Die dünne Verbreitung bestätigt der Artikel selbst (nur Core Lightning produktiv, LND in Entwicklung, Wallet-Support lückenhaft). Ob BOLT #12 sich langfristig gegen das etablierte LNURL-Ökosystem durchsetzt, ist heute nicht entscheidbar.Open: the article itself confirms the thin deployment (only Core Lightning in production, LND in development, patchy wallet support). Whether BOLT #12 prevails long-term against the established LNURL ecosystem cannot be decided today.Abierto: el propio artículo confirma la escasa implantación (solo Core Lightning en producción, LND en desarrollo, soporte de carteras irregular). Si BOLT #12 se impondrá a largo plazo frente al ecosistema LNURL establecido no puede decidirse hoy.Em aberto: o próprio artigo confirma a implantação escassa (apenas Core Lightning em produção, LND em desenvolvimento, suporte de carteiras irregular). Se o BOLT #12 vencerá no longo prazo o ecossistema LNURL estabelecido, não é possível decidir hoje.未確定:普及の薄さは記事自身が認めている(本番運用はCore Lightningのみ、LNDは開発中、ウォレット対応はまばら)。BOLT #12が確立されたLNURLエコシステムに長期的に勝てるかは、今日の時点では判断できない。悬而未决:文章自己也确认其普及度有限(仅Core Lightning投入生产,LND仍在开发,钱包支持零散)。BOLT #12能否长期胜过已成型的LNURL生态,今天无法定论。مفتوح: يؤكد المقال نفسه ضعف الانتشار (Core Lightning وحده في الإنتاج، وLND قيد التطوير، ودعم المحافظ متقطع). أما هل سيتفوق BOLT #12 على منظومة LNURL الراسخة على المدى الطويل فلا يمكن حسمه اليوم.