The spec should include optional preimage for RequestInvoiceArgs

[monokh]

The lightnings clients by default generate the preimage for the invoice. In some use cases (e.g. swaps) the app requires to specify the preimage for the invoice. The lightning API includes options for specifying this so it shouldn't be an issue from the provider side.

There may be security considerations here for providers.
Thoughts?

[wbobeirne]

Yeah, this is a little tricky. If the application knows the preimage, the payment could potentially not be secure. I see what you mean about there being use cases for it though, but I'd have to dive more into them to see if it can't be managed in some other way. If this were to be implemented, it would probably require a big scary warning for users about their payment having this risk associated with it.

If you can follow up with any more information about this use case, would appreciate it!

[monokh]

If we want to be Bitcoin specific, the use case is submarine swaps. This means conducting a swap of onchain BTC for BTC on Lightning. To be able to conduct this swap the steps are:

Alice generates a preimage and funds a HTLC on the bitcoin mainchain with the hash of the preimage.
Alice also generates an invoice with the same preimage.
Alice sends the lightning invoice to BOB

As Bob can verify that knowledge of the preimage can mean access to the funds located on the bitcoin mainchain, he pays the invoice.
Paying the invoice reveals the preimage that he then uses to unlock the mainchain BTC.

I believe this is the process @alexbosworth uses in https://github.com/submarineswaps/swaps-service.

For Alice to be able to generate this invoice correctly through an extension like Joules, it needs to be possible to pass through the preimage to the LND rest api.

What could the app do with the preimage? I suppose you would have to trust the app in this case. I understand that there would have to be a warning to the user. Maybe there can be a general handling of "unsafe" parameters like this? I can see how this is tricky 😄, webln would really be valuable the usecase though.

[alexbosworth]

Sounds cool, in the case of the submarine swaps library there I don't use a client-generated preimage but it could be added

I also have another open source node.js library for working with swaps on the client side: https://www.npmjs.com/package/goldengate - this one does generate preimages on the client side

Letting users in Joule do submarine swaps to manage liquidity issues sounds pretty awesome to me although the tooling I have made so far does need some work to be drop-in ready

[monokh]

I have actually figured out that this is not 100% required for the submarine swap use case. The order of creating the HTLC and invoice can be reversed so that payment hash (preimage hash) from the invoice can be used for locking the HTLC. Since the payment response in the spec returns the preimage, it fulfils the usecase just fine.

The only reason I'm looking to do it in the reverse order is so that all details of the swap can be embedded and exchanged using a lightning invoice (see https://github.com/monokh/submarine-swap/blob/master/src/utils/order.js#L23) making the swap much more usable.

@alexbosworth do you mean within the joule extension or as an app? If through the extension, wouldn't it also need connection to a bitcoin node/wallet? I suppose LND does have decent access to the full node but i wonder if it's accessible through the rest API.

If a solution for submarine swap in joule is interesting, what i'm trying at https://github.com/monokh/submarine-swap is trying to put together an example of a 100% browser based, serverless submarine swap. It might show that it's possible directly through the extension although the general appetite for getting complex functionality like this into Joule is a question in itself.

[alexbosworth]

Either Joule could embed it or it could have a conduit to LND to do it

[monokh]

There is actually another requirement for the swap and that is to specify the expiry. That would seem more straightforward to add @wbobeirne? Joule seems to support specifying it too.

[wbobeirne]

Specifying expiry seems totally fine to me, I'm down with that!

[pseudozach]

I actually have a new use case on betya.tk where the user will be paid after 24 hours when the bet is resolved so I need to make sure webln generated invoice is valid at 24 or 25 hours to be safe. Do you have any plans to add this option (expiry) to makeInvoice? thanks.