Skip to content

Instantly share code, notes, and snippets.

@harding

harding/mobile-client-pays-hold-invoice.md

Created November 16, 2023 22:29
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save harding/83e0934ec763c780241dbc7094f75665 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save harding/83e0934ec763c780241dbc7094f75665 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. harding created this gist Nov 16, 2023.
    62 changes: 62 additions & 0 deletions mobile-client-pays-hold-invoice.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,62 @@
    Re: https://twitter.com/super_testnet/status/1725239338533810410

    WARNING: this is a five-minute write up in response to a post I saw on
    X. I haven't thought about this carefully.

    Problem: a mobile wallet spender pays a hold invoice that doesn't settle
    immediately. The spender goes offline. The payment eventually times
    out far downstream, with each forwarding node settling it offchain until
    it reaches the initial downstream node. So far, so good, but then the
    mobile spender is offline when its downstream peer tries to settle with
    it, so the downstream peer needs to force close the channel to settle
    the HTLC onchain before HTLC expiry where mobile spender is able to
    claim a refund of the spend.

    Proposed solution: the mobile spender can make their refund condition
    timelocked relative to confirmation of the commitment transaction,
    allowing the HTLC to stay open between them and their downstream peer
    indefinitely. This doesn't cost the downstream peer anything (except
    storing a database entry). It also still allows the mobile spender to
    trustlessly receive a full refund if the payment doesn't settle. For a
    mobile client that's online all the time, they can receive a refund in
    the same amount of time as currently used. For a mobile client that's
    offline for t amount of time, their refund is only delayed by t.

    Downsides:

    1. A relative timelock (OP_CSV) on the refund condition is only safe for a
    spender to use. Regular forwarding nodes must use absolute timelocks
    (OP_CLTV) with a delta so that forwarding funds from one channel to
    another channel is atomic. That means the mobile wallet identifies
    itself to its downstream peer as the ultimate spender of the payment.
    For mobile clients using an LSP, it may already be clear that they're
    the ultimate spender, so no additional privacy is lost.

    2. It's a modification to the standard LN protocol. Change is hard.

    Here's an example comparison of prototypical HTLCs. The only difference
    are the lines using OP_CTLV vs OP_CSV.

    ```
    Standard HTLC
    ~~~~~~~~~~~~~
    OP_IF
    OP_RIPEMD160 <hash> OP_EQUALVERIFY
    <downstream pubkey> OP_CHECKSIG
    OP_ELSE
    <spender pubkey> OP_CHECKSIGVERIFY
    <expiry (absolute height)> OP_CLTV
    OP_ENDIF
    Mobile Spender HTLC
    ~~~~~~~~~~~~~~~~~~~
    OP_IF
    OP_RIPEMD160 <hash> OP_EQUALVERIFY
    <downstream pubkey> OP_CHECKSIG
    OP_ELSE
    <spender pubkey> OP_CHECKSIGVERIFY
    <expiry (relative number of blocks after commitment tx confirms)> OP_CSV
    OP_ENDIF
    ```