Re: [Lightning-dev] Proposal: Bundled payments

2023-06-20 Thread Steve Lee
On Tue, Jun 20, 2023 at 6:17 AM Thomas Voegtlin wrote: > > > We have not implemented BOLT-12 yet in Electrum. Would you care to > describe whether bundled payments already would work with the current > specification, or whether they would require changes to BOLT-12? We > are going to implement BO

Re: [Lightning-dev] Proposal: Bundled payments

2023-06-20 Thread Matt Corallo
On 6/20/23 1:45 AM, Thomas Voegtlin wrote: - snip - We have not implemented BOLT-12 yet in Electrum. Would you care to describe whether bundled payments already would work with the current specification, or whether they would require changes to BOLT-12? They will not as-specified, but becau

Re: [Lightning-dev] Proposal: Bundled payments

2023-06-20 Thread SomberNight via Lightning-dev
Hi Thomas, Bastien, and list, One point I would like to stress for this idea, is that there are potentially three different entities at play in these payments. This might not be obvious at first glance especially for the submarine swap example, where people expect just two entities: the user ("c

Re: [Lightning-dev] Proposal: Bundled payments

2023-06-20 Thread Bastien TEINTURIER
Hi Thomas, > I believe pre-payment of the mining fee can be combined with 0-conf; > I am not sure why you picture them as opposed? Even with BOLT-12, I > don't see 0-conf going away. Sorry if that was unclear, that's not at all what I meant. What I meant is that if we *stopped* using 0-conf for s

Re: [Lightning-dev] Proposal: Bundled payments

2023-06-20 Thread Thomas Voegtlin
Hello Bastien, Thank you for the clarification; indeed I might not have been clear about the fact that senders need to understand the new fields. What you are suggesting (solution 2, blacklisting non-cooperative clients and playing with the mempool) is prone to griefing attacks and it requires m

Re: [Lightning-dev] Proposal: Bundled payments

2023-06-20 Thread Thomas Voegtlin
Hello Dave, That is an interesting idea; it would indeed save space for the prepayment hash. I think the invoice would still need a feature bit, so that the receiver can decide to make prepayment optional or required. Note that for the feature to be optional, we need to subtract the prepayment a

Re: [Lightning-dev] Potential vulnerability in Lightning backends: BOLT-11 "payment hash" does not commit to payment!

2023-06-20 Thread Antoine Riard
Hi calle, Thanks for the report. >From my understanding of what you're describing, the attack is possible because LNBits backend does not check that an external received HTLC `amount_msat` satisfies the invoice amount for both matching preimage and payment secret. This sounds plausible to me. If

Re: [Lightning-dev] Proposal: Bundled payments

2023-06-20 Thread David A. Harding
On 2023-06-12 22:10, Thomas Voegtlin wrote: The semantics of bundled payments is as follows: - 1. the BOLT-11 invoice contains two preimages and two amounts: prepayment and main payment. - 2. the receiver should wait until all the HTLCs of both payments have arrived, before they fulfill the HTL