BOLT 12

[elsirion]

Investigate ways of implementing recurring payments e.g. through BOLT12.

• Without PTLCs: client gives federation many encrypted preimages when creating the BOLT12 offer, replenishes whenever they are online
• With PTLCs: the federation can create its own secrets/points

[justinmoon]

Just renamed the issue to BOLT12.

@elsirion: remind me what the problem was with having the gateway sign BOLT12 invoices instead of the federation?

[justinmoon]

Note: BOLT12 also fixes our current inability to pay amountless invoices because all bolt12 invoices have an amount.

[elsirion]

@elsirion: remind me what the problem was with having the gateway sign BOLT12 invoices instead of the federation?

You'd trust the GW to set the same required amount in the incoming LN offer as in the invoice generated for the sender while the incentives are to set the amount of the offer way lower and take the difference as profit, cheating the user out of money.

EDIT: there is no spec for how BOLT12+Fedimint would work yet, this might only make sense if you already have the rough potential protocol flow in your head.

[TheBlueMatt]

Wouldn't the user see that? Ultimately to deposit money into a fedimint, the user is going to (a) interact with fedimint software to connect to the gateway and get an offer, then (b) that software will display the qr code for the user to use to pay via a lightning wallet. In (a) that software can trivially validate the amount in the offer.

[elsirion]

tj;dr: It's a very similar problem to why amountless invoices were broken in the early days.

@TheBlueMatt Let's simplify a bit, for this case we can think of the recipient being the federation, the gateway an arbitrary, untrusted routing node and the sender any (not Fedimint-aware) LN node.

In this model the preimage and payment hash are generated by the federation[^1] and the preimage is only revealed if a certain amount is paid. But which amount should be paid for a given preimage? That is defined at invoice creation time. If we now let the gateway generate the invoice it can tell the federation the preimage is worth 1sat while putting 1BTC into the invoice it gives the sender. The sender isn't aware that the recipient will only get 1sat of the 1 BTC sent and will happily return the preimage for that.

In Fedimint the gateway isn't trusted, only the federation as a whole is. That's why it cannot be used to generate/sign invoices.

[^1]: Reality is a bit more complex and users actually have to deposit threshold-encrypted preimages in advance for BOLT12 to work with Fedimint. Once PTLCs are widely adopted the federation will be able to generate points by itself through a DKG algorithm.

[TheBlueMatt]

Right, the simple solution here is to always use offers with amounts in them, rather than variable-amount offers. Sadly this does mean single-use offers, in effect, but that seems fine?

[elsirion]

But why do offers at all then? I always thought having the option of recurring payments was the point of adding an additional round to the payment protocol. It's one of the bigger selling points.

[TheBlueMatt]

Indeed, the recipient being different from the offer responder is incompatible with variable amounts and such. Sadly, BOLT12 is really not designed for that, and thus we have to resort to hacks if we can't get onion messages through to the client who is actually receiving the money.