t-bast

Phoenix in a splicing future (a.k.a death to all swaps)

Phoenix implements trusted swaps for users' convenience (to allow easy onboarding and offboarding). But it's not a satisfying solution for the following reasons:

• It uses two on-chain transactions for swap-in where one should be sufficient (one transaction from the user to Acinq followed by a channel open)
• Swap-out feerates are unpredictable (because we may fund the swap-out with unconfirmed previous outputs) which is frustrating for users
• It forces Acinq to use its own utxos, which doesn't scale well and is an operational burden
• If Acinq doesn't have any utxos available and the mempool is completely full, swaps are stuck which is also frustrating for users

t-bast

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

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

On-the-fly channel liquidity

Table of Contents

• Abstract
• Specification
  • Feature bits
  • Extensions for Bolt 12 messages
  • Extensions for interactive-tx messages
• Examples

t-bast

On-the-fly channel liquidity

Table of Contents

• Abstract
• Specification
  • Feature bits
  • The propose_funding_htlc message
  • The fail_funding_htlc message
• The accept_funding_htlcs message

t-bast

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.

Terminology

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

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

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

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.

t-bast

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.