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 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 July 12, 2023 02:32
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
 | |
t-bast / PaymentPacket.scala
Last active December 21, 2022 10:54
Eclair architecture blog post code snippet
View PaymentPacket.scala
* @param cmd command to send the HTLC for this payment.
* @param outgoingChannel channel to send the HTLC to.
* @param sharedSecrets shared secrets (used to decrypt the error in case of payment failure).
case class OutgoingPaymentPacket(cmd: CMD_ADD_HTLC, outgoingChannel: ShortChannelId, sharedSecrets: Seq[(ByteVector32, PublicKey)])
/** Helpers to create outgoing payment packets. */
object OutgoingPaymentPacket {
t-bast /
Last active June 23, 2022 08:21
Package RBF lightning samples

Sample lightning transactions using package RBF

This document contains sample fee-bumping scenarios used by lightning nodes to replace a malicious commitment transaction. Commitments transactions in these test cases don't pay any fees. The fee-bumping child (the anchor transaction) spends from one or more commitment transactions and an unrelated wallet transaction (used to add funds).

The actual tests implementing this can be found here.

Basic commitment RBF

View Onion messages

Onion messages rate-limiting

During the recent Oakland Dev Summit, some lightning engineers got together to discuss DoS protection for onion messages. Rusty proposed a very simple rate-limiting scheme that statistically propagates back to the correct sender, which we describe in details below.

Nodes apply per-peer rate limits on incoming onion messages that should be relayed (e.g. N/seconds with some burst tolerance). It is recommended to allow more onion messages from peers with whom you have channels, for example 10/seconds when you have a channel and 1/second when you don't.


A different approach to solve RBF for off-chain contracts

Key observation: on-chain fees for off-chain application settlement should be endogenous, not exogenous. In more plain english, there is no good reason to bring funds from "outside" of an off-chain contract to pay the fees necessary to settle that contract on-chain. Any party in the contract is ready to burn at most their contract balance in on-chain fees, but it wouldn't make sense to burn more, even for a scorched earth strategy. This is something I brought up a while ago in lightning/bolts#845

We could achieve this with an extension to SIGHASH_ANYPREVOUT, which I'm calling SIGHASH_ANYAMOUNT. This could be a flag to complement a SIGHASH_ANYPREVOUT / SIGHASH_ANYPREVOUTANYSCRIPT and add the following behavior:

t-bast /
Last active April 26, 2022 07:01
When is it more economical to make an on-chain tx rather than an off-chain one?

Economics of making on-chain vs off-chain payments

The fees for on-chain payments are independent of the payment amount, while the fees for off-chain payments are proportional to the amount sent. It is trivial to compute the amount at which it makes more sense to make an on-chain payment.

Parameters used to compute the following numbers:

  • the weight of a 2 inputs, 2 outputs on-chain transaction using p2wpkh is 836 vbytes
  • a route in the lightning network has roughly a median 1000ppm proportional fee