Implement Lightning Loop support

[ZmnSCPxj]

Getting incoming capacity is dangerously centralized around Boltz exchange. In principle somebody else could come around and implement an alternative (hopefully using the same protocol so it is easy on CLBOSS), but there are no alternative Boltz-protocol exchanges that I could find.

On the other hand, there already is a viable alternative to Boltz, that also (looks like it) has non-custodiality across the entire swap, Lightning Loop.

Loop does have the drawback that the client-server protocol is not documented, there is only the .proto files in the Loop source code.

[hosiawak]

@ZmnSCPxj I'm talking to the Coldbit team about setting up a Boltz compatible exchange and provide. Would you be willing to integrate that as well ? (It'll most likely be the same API Boltz use).

[ZmnSCPxj]

THAT WOULD BE AWESOME.

You "just" need to add it here: https://github.com/ZmnSCPxj/clboss/blob/bd4e45338a1ed7c376da1c5f82a591c11620f0c1/Boss/Mod/BoltzSwapper/Main.cpp#L8-L17

You can also check if the BOSS code can handle your Boltz-compatible by modifying this line in the dev-boltz tool: https://github.com/ZmnSCPxj/clboss/blob/66274457b14f478924d86df662ffaaad21bc0d12/dev-boltz.cpp#L162

If you can get that working, then 99.9% chance it will "just work" by adding to the above boltz_instances data structure.

BUT note that BOSS currently only supports the no-mining-fee-invoice variation of the Boltz protocol. If your service demands an invoice to be paid first to defray the mining cost of the onchain HTLC, I will need to update a bunch of code (but likely far less than having to study the Lightning Loop code and reimplementing it and so on). Currently swapping assumes only one invoice is involved in a swap, so need to redesign code over in Boss::SwapManager in addition to modifications in the Boltz namespace.

[ZmnSCPxj]

To use dev-boltz (after modifying that line to point to your new Boltz-compatible) to evaluate if the Boltz-compatible is sufficiently compatible for CLBOSS to use:

• Make sure you have never run dev-boltz before, or if there are swaps before, you do not care about them (i.e. they expired already or you have claimed them).
  • rm -f data.dev-boltz to clear any previous swaps you do not care about anymore.
• ./dev-boltz get-quotation ${AMOUNT} to get a quotation on how much it would cost to swap.
• Get a SegWitv0 (starts with bc1q or tb1q) onchain address you control, assign to ADDR. (I think I did not add support for all address types, just SegWit, in any case C-Lightning can support SegWitv0 addresses anyway and BOSS just explicitly requests for those).
  • Note that BOSS does not do checksum-checking on addresses, on the assumption that BOSS only gets addresses from C-Lightning and puts them into its own database, and that bitflips do not occur in the hardware, only when human brains are involved.
• ./dev-boltz swap ${AMOUNT} ${ADDR} $(bitcoin-cli getblockcount) to get an invoice to pay.
• Pay the invoice.
• At every block, run ./dev-boltz on-block $(bitcoin-cli getblockcount).
  • Does not need to be done every block, it is okay if you skip a few, but take note about the timeout on the swap, which dev-boltz should print on stdout as part of the log at some point.
• Check if the address gets to receive funds if the invoice payment succeeded, when dev-boltz on-block gets to run correctly.

The dev-boltz-api tool is also useful to check the API of the Boltz-compatible directly. Though note that the conversion from Jsmn::Object to Json::Out can cause roundoff/numeric inaccuracy errors (the JSON input to dev-boltz-api is parsed by Jsmn, but we output JSON using Json::Out, the conversion between them for numbers passes through double and a lossy double-to-text conversion), which I did not fix since we use Ln::Amount inside CLBOSS for amounts.

[ZmnSCPxj]

AND Boltz Exchange has an SSL certificate error now :(

This is why depending on a single server suxxxxxx

[ZmnSCPxj]

Boltz is up again!

[ghost]

The reverse submarine swap - using an untrusted server to exchange lightning btc for chain btc - allows new nodes to bootstrap themselves into being useful for routing and useful for receiving. The mechanism of the swap is simple, an on chain buyer makes a request then an on chain address is funded with a script like

HASH160 <hash of preimage> EQUAL
IF <chain buyer pubkey>
ELSE <timeout> CHECKLOCKTIMEVERIFY
DROP <chain seller pubkey> ENDIF
CHECKSIG 

If the timeout has not been reached then the only way the chain coins can be claimed is using the preimage and the buyer pubkey. The preimage is the secret lock of a lightning invoice and must be revealed in order to receive the lightning payment, thus an exchange can happen with no trust between the participants.

The problem with this is the CHECKLOCKTIMEVERIFY creates a confirmation urgency. In boltz-backend implementation even in a low fee moment the lockup fee rate was 95sat/byte+. Paying this level of fees to balance digs a very large hole that routing fees will take years to make up. Seems like lightning loop uses the same transaction dynamic, subject to the same confirmation urgency.

Naively, a script like

HASH160 <hash of preimage> EQUAL

would allow a server to put outputs up for sale indefinitely? But the server and any nodes on the payment route have the preimage so this is no good. Think it is important to be able to do reverse submarine swaps with low fees. Wondering if an asynchronous, counterparty flexible version of reverse sub-swaps is possible? The fees paid by boltz backend are too damn high!

[ZmnSCPxj]

Naively, a script like

 HASH160 <hash of preimage> EQUAL

would allow a server to put outputs up for sale indefinitely?

As you note, the server knows the preimage, so, after getting paid quickly offchain, the server can try to race the onchain side and claim the funds.

In order to prevent such sudden reversals, it has to lock it to a specific client, by adding an OP_CHECKSIG.

But now the server cannot safely leave its funds in such scripts. If the client disappears, then the server funds are stuck forever and it cannot reuse the funds for other purposes. That is why the OP_CHECKLOCKTIMEVERIFY exists at all.

Lengthening the timeout allows for lower fees (because the longer timeout translates to less pressure for immediate confirmation), but has the drawback that a client can DoS the server by requesting service without paying, which requires the locktime to pass in its entirety. The longer the timeout, the worse the effect the DoS has. The shorter the timeout, the higher the fee necessaary for quick confirmation of transactions involved. Traeoffs tradeoffs...

We really need decent widespread support for RBF, as that would allow our automated tools to always start at tiny 1sat/byte fees, then later bump fees up if confirmation is not occurring quickly enough. I need to double-check the Boltz client-server protocol, because I am unsure if it even allows the transaction containing the HTLC to be RBFable --- if the server commits to a specific txid before the transaction can be confirmed then the protocol simply does not support RBF, full stop.

[hosiawak]

Dear Santa: A RBF-able swap implementation as a C-Lightning plugin that is Boltz API compliant :)

[ZmnSCPxj]

Dear Santa: A RBF-able swap implementation as a C-Lightning plugin that is Boltz API compliant :)

I am sort-of planning one, though I do have to think about how to make RBF work on C-Lightning (it has theoretical support for it, but I am not sure we do not have bugs in edge cases when race conditions occur between a replacement and a new block that contains the transactions being replaced --- it is not a well-tested part yet). Or maybe just have the plugin manage its own onchain wallet? Hmm.