Skip to content

Instantly share code, notes, and snippets.

View t-bast's full-sized avatar

Bastien Teinturier t-bast
View GitHub Profile
t-bast /
Last active May 15, 2024 14:01
On-the-fly channel funding based on liquidity ads

Continuous on-the-fly liquidity for mobile wallets

Liquidity is always provided by an on-chain transaction (channel open or splice), which can be triggered by:

  • On-chain funds added by the wallet user.
  • A lightning payment to the wallet user requiring additional liquidity.

Table of Contents

t-bast /
Last active January 3, 2024 14:07
Coin selection for liquidity providers

Coin selection for liquidity providers

Bitcoin Core's coin selection algorithms optimizes mostly for the following metrics:

  • keep a low utxo count by consolidating regularly
  • avoid creating a change output
  • when a change output is needed, use an amount equivalent to the payment (for privacy)

This doesn't match what liquidity providers need. Liquidity providers need to:

t-bast /
Last active November 8, 2023 16:46
On-the-fly channel liquidity (prepaid by sender)
t-bast /
Last active February 6, 2024 12:15
Future of lightning address

Lightning Address

Lightning Address is a very popular protocol that brings UX improvements that users love. We'd like to provide those UX benefits without its privacy and security drawbacks.

Issues with the current lightning address protocol

As described here, the lightning address protocol requires payment senders to make an HTTP request to the recipient's domain owner. This has some inconvenient side effects:

t-bast /
Last active November 7, 2023 14:22
On-the-fly channel liquidity (LSP-initiated)
t-bast /
Last active May 26, 2023 13:17
CLTV expiry usage in blinded paths

CLTV expiry for blinded paths

Let's consider the following setup:

  • E creates a blinded path C->D->E
  • E computes a cltv_expiry_delta for the blinded path:
    • E starts by adding the cltv_expiry_delta of every hop
    • E sets cltv_expiry_delta = 10 in the encrypted_recipient_data for C
    • E sets cltv_expiry_delta = 15 in the encrypted_recipient_data for D
    • E adds its min_final_expiry_delta (let's use 5)
t-bast /
Last active May 23, 2023 15:37
Explore usage of swap-in potentiam for Phoenix

Swap-in potentiam for Phoenix

The current swap-in flow for Phoenix uses the following steps:

  1. Derive a BIP 32 p2wpkh address from the user's seed
  2. Send funds to that address from an external on-chain wallet
  3. Wait for confirmations
  4. Fund a channel with ACINQ with utxos from that address
  5. Wait for confirmations
t-bast /
Last active April 13, 2023 06:39
Proposal to describe lightning protocol flows

Protocol flow representation

Representing message flows for lightning protocols is hard, because we're not using turn-based protocols: peers may be sending messages at the same time. It is very useful though to find a suitable way of representing protocol flows, to be able to discuss edge cases and implement the corresponding test cases.

The following diagram perfectly represents the fact that messages can be interleaved. There is no way to misinterpret it since Bolt 8 guarantees that messages are ordered. But it is hard for the reader to match a received message with the place where it was sent.

t-bast /
Last active October 2, 2023 13:57
Alternative splicing specification proposal with detailed examples

Splice specification proposal

This gist details various splicing protocol flows as they are currently implemented in eclair. We detail the exact flow of messages for each scenario, which should help the review process.


We call "active commitments" the set of valid commitment transactions to which updates (update_add_htlc, update_fulfill_htlc, update_fail_htlc, update_fail_malformed_htlc, update_fee) must be applied. While a funding transaction is unconfirmed, updates must be valid for all active commitments.

t-bast /
Created March 13, 2023 16:07
When should we store an `interactive-tx`?

When should we store an interactive-tx?

When using the interactive-tx protocol, we currently store the channel state only after we've sent tx_signatures. This makes sense from a funds safety point of view: the commitment transactions can only be broadcast once we've given our peer the signatures they needed to broadcast the funding transaction first.

But in some cases, this creates an issue where one side has stored the channel state but not the other side. See the following scenario for example (where -->X indicates a message that wasn't received):

  Alice                          Bob
 | |