lightning-dev
Proposal: Bundled payments
Posted on: June 13, 2023 08:10 UTC
In a proposal to extend BOLT-11, ThomasV suggests the inclusion of two bundled payments with distinct preimages and amounts in an invoice.
This proposal aims to address the use case of services that require prepayment of a mining fee for non-custodian exchanges, such as submarine swaps and JIT (Just-In-Time) channels. Currently, service providers face challenges in requesting prepayment due to limitations in existing systems.For services like Loop by Lightning Labs, which utilize dedicated client software, prepayment can be requested as their software can handle it through a "no show penalty" feature. However, competitors like the Boltz exchange, which do not require a dedicated wallet, are vulnerable to denial-of-service (DoS) attacks where attackers force them to pay on-chain fees. Similarly, providers of JIT channels need to ask for the preimage of the main payment before opening the channel to protect themselves against mining fee attacks.However, requesting the preimage first makes the service provider a custodian, which raises legal concerns under European MICA regulation. Competitors like Electrum, who refuse to offer custodian services, are excluded from this game. To overcome these challenges, ThomasV proposes bundling the prepayment and the main payment in the same BOLT-11 invoice.The proposed semantics of bundled payments are as follows: 1. The BOLT-11 invoice would contain two preimages and two amounts: prepayment and main payment.2. The receiver should wait until all HTLCs (Hash Time-Locked Contracts) of both payments have arrived before fulfilling the HTLCs of the pre-payment. If the main payment does not arrive, they should fail the pre-payment with a MPP (Multi-Path Payments) timeout.3. Once the HTLCs of both payments have arrived, the receiver fulfills the HTLCs of the prepayment and broadcasts their on-chain transaction. However, the main payment can still fail if the sender never reveals the preimage of the main payment.ThomasV acknowledges that his proposal does not prevent service providers from stealing the pre-payment, but clarifies that this is already a risk in the current system. He believes that implementing this change in BOLT-11 would level the playing field for lightning service providers. Currently, Loop requires the use of a dedicated client, while competitors without an established user base running a dedicated client are exposed to mining fee attacks. Additionally, ThomasV suggests that ACINQ, another lightning service provider, would benefit from this proposal by allowing them to make their pay-to-open service fully non-custodian. As per his understanding, the current 'pay-to-open' service used by Phoenix may fall under the scope of the European MICA regulation, which should be considered a serious issue.In conclusion, ThomasV advocates for the implementation of bundled payments in BOLT-11 to address the challenges faced by lightning service providers in requesting prepayment and protect against mining fee attacks. He emphasizes the need for a non-interactive solution without introducing new messages, making BOLT-11 the appropriate framework for this enhancement.