⚗️Investigate compatibility of RFC003 and LND with HODL invoices

[LLFourn]

This Spike is about figuring out how we could do an RFC003 SWAP with lnd as one of the Ledgers. Note that this would be independent of lightning channels as a Ledger (unless you find that lnd exposes an api that would allow this).

HODL invoices were introduced into lnd here: lightningnetwork/lnd#2022 which will make things easier.

What to include:

1. A sketch of the protocol (the actions involved at each ledger state, what the SWAP request response would look like). Justify your decisions.
2. A summary of architectural changes we'd need to make to realise the proposal.
3. An analysis of any inconsistencies the proposal would have with our present idea of RFC003.

[LLFourn]

Ok so the thing Thomas and I found our was that in order to compile lnd and ln-cli with this feature you need to add:

&&  make tags="invoicesrpc" \
&&  make install tags="invoicesrpc"

To the Dockerfile.

Events

in an X-LN Swap (beta_ledger is LN) the things we need to watch for are

Alice adds a HODL invoice

We agreed that it's best that the COMIT node does this itself.
Thomas and I agreed that this should be done automatically when Bob accepts.
If the COMIT node is doing it then it's easy to tell when it's done.

Bob sends the payment (conditioned the secret_hash)

This is done using sendpayment. It's actually tricky to tell if this has been done. Bob's node has to list his channels, waiting for for something like this:

lncli --network=simnet listchannels
{
    "channels": [
        {
            "active": true,
            "remote_pubkey": "03c47662613e835ecd13aea6d01415cac6e169c98e19185a2104d562ec637e7da9",
            "channel_point": "bc4cbb92aca37c465258f5a593cb0ba273b2bbf54960c1cf6a9370bbd1b2ebd9:0",
            "chan_id": "440904162803712",
            "capacity": "1000000",
            "local_balance": "978800",
            "remote_balance": "0",
            "commit_fee": "11200",
            "commit_weight": "772",
            "fee_per_kw": "12500",
            "unsettled_balance": "10000",
            "total_satoshis_sent": "0",
            "total_satoshis_received": "0",
            "num_updates": "1",
            "pending_htlcs": [
                {
                    "incoming": false,
                    "amount": "10000",
                    "hash_lock": "CBM42+D1lr0V1hh5cMQRgR9/oB6/ZvqvZ1KPqiExWVs=",
                    "expiration_height": 443
                }
            ],
            "csv_delay": 144,
            "private": false,
            "initiator": true,
            "chan_status_flags": "ChanStatusDefault"
        }
    ]
}

When he sees pending_htlcs has something with a hash_lock matching the secret_hash then Bob has sent the payment. (note we didn't verify yet that this base64 encoded value is actually the secret_hash so we need to test that -- it might be the actual hash lock which is in the contract with is the RIPEMD160 hash of the secret_hash 🤔. The secret for that one was 081338dbe0f596bd15d6187970c411811f7fa01ebf66faaf67528faa2131595b I think).

Alice settles the payment (and reveals the secret)

We haven't tested this but it can be done by using SubscribeSingleInvoice according to the PR.

RFC003 spec unanswered so far

What's the Ledger?

We didn't figure out the answers to what should be the ledger etc and what's possible. IMO the ideal situation is:

• The Ledger is lightning with parameter channel_id (probably network too).
• The associated identity is the node_id

But to do that we have to ensure that we can guarantee a payment is sent to a certain channel. If that's not possible, maybe we could make the channel_id optional?

How to negotiate times

LN uses absolute block height for the expiries. We have to decide whether we negotiate in terms of a specific time in the future in the SWAP messages and then try and convert it into block height or have block heights in the expiry messages.

[bonomat]

Note: the new feature holdinvoice enables us to trade LN-X, i.e. LN is the alpha ledger and X the beta ledger.
For the otherway around, we can make use of the normal createinvoice procedure.

A rewrite of this spike can be found in: comit-network/spikes#6