Published on: 2018-11-17T23:20:56+00:00
In an email exchange, Rusty Russell clarified the concept of a "lightning probe message" to René Pickhardt. He explained that it would be a new message proposed for liveness testing of routes pre-payment. The payer would create an onion package triggering the offering of HTLCs with additional metadata, allowing the recipient of the final onion to respond with a BOLT11 invoice. Rusty emphasized that payment hash is not necessary to offer HTLCs. René suggested incorporating a connection-oriented communication layer in the current protocol to enhance payment and routing communication efficiency. In response, Rusty recommended reading the paper on HORNET but expressed concerns about incentives and privacy.ZmnSCPxj discussed the mechanism of generating a payment_hash from random data and sending it to the payee, who cannot claim the funds without the preimage. This mechanism could be used to stream invoices instead of anime. ZmnSCPxj proposed using this method to create reusable BOLT11 "offers" that enable almost-spontaneous payments without generating a BOLT11 invoice for each sale. Additionally, separate BOLT15 offers were suggested to allow users to obtain any number of BOLT11 invoices. ZmnSCPxj also advocated for a connection-oriented communication layer on top of the current protocol for more efficient payment communication, although he believed that payments or forwarding fees should be attached to each message due to concerns over network capacity abuse.Addressing ZmnSCPxj's proposal, the sender of an email to Rusty requested clarification on the term "lightning probe message" and its absence from the current BOLTs. The proposal outlined a method of having reusable BOLT11 "offers" that provide almost-spontaneous payments without the need for generating a BOLT11 invoice for each potential sale. These offers would be retrieved through a lightning probe message using the existing onion format for HTLCs. The return lightning message would contain a new BOLT11 invoice along with additional data. The proposal aimed to facilitate recurring payments and static invoicing, allowing a single static invoice without an amount field to approximate spontaneous donations while still providing proof of payment.In a recent email exchange, ZmnSCPxj admitted to overestimating the power of Scriptless Scripts before the summit but now recognized their significance, albeit with implementation difficulties without Schnorr. Static invoices were deemed not possible without an extra interaction as the payee needed to dynamically provide a new payment hash or payment point under Scriptless Scripts for proof-of-payment. To share a static invoice among multiple payers, the payee must generate new secrets each time to ensure separate proof-of-payment.A conversation on the Bitcoin-Dev mailing list involved ZmnSCPxj apologizing for not fully explaining the power of Scriptless Scripts before the summit. Another user acknowledged that the understanding of Scriptless Scripts' capabilities matched previous expectations. However, implementing them proved challenging without Schnorr due to script magic involving OP_CODESEPARATOR. Progress on Scriptless Scripts had been halted in anticipation of Schnorr. Rusty clarified that static invoices were not feasible without an extra interaction.ZmnSCPxj proposed a new method of having reusable BOLT11 "offers" to enable almost-spontaneous payments without generating a BOLT11 invoice for each sale. This involved creating a separate BOLT document for generating a BOLT11 invoice and using the term "BOLT15 advertisement." The proposal also addressed concerns regarding canonical ordering for tagged fields in the generated BOLT11 invoice, suggesting a proposal for types to have an absolute order, particularly useful for unique components. The order of tagged fields in BOLT11 invoices mattered due to their signatures.Further discussions by ZmnSCPxj suggested a separate BOLT for the format of type, len, and data in the final-hop lightning onion. It was also proposed to document various consistent designs of messages in the BOLT, such as using prefixed 16-bit length for var-length fields. ZmnSCPxj acknowledged overestimating the power of Scriptless Scripts before the summit, attributing the difficulty of implementation without Schnorr to script magic involving OP_CODESEPARATOR.The proposal put forth by ZmnSCPxj focused on reusable BOLT11 "offers" that would facilitate almost-spontaneous payments without generating a BOLT11 invoice for each sale. These offers would include a 26-byte `p` field, ignored by existing nodes. To retrieve the complete invoice, the payer would use a new lightning probe message employing the current onion format used for HTLCs. The final-hop lightning onion would consist of a marker, a 128-bit `p` field, and optional types such as quantity, delivery-address, and signature. The return lightning message would contain a new BOLT11 invoice, potentially optimized by copying fields from the BOLT11 offer if they are not included.
Updated on: 2023-07-31T20:47:29.571316+00:00