t-bast

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

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

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

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

t-bast

   Mempool #1
+------------------------------------------------------------------------------+
|                                                                              |
|      1 sat/byte                  1 sat/byte                  1 sat/byte      |
|   +-------------+             +-------------+             +-------------+    |
|   |     tx1     |------------>|     tx2     |------------>|     tx3     |    |
|   +-------------+             +-------------+             +-------------+    |
|                                                                              |

t-bast

Combining BIP32 keys for fun and profit

We only consider non-hardened children here.

Private parent key → private child key

CKDpriv((kpar, cpar), i) → (ki, ci) computes a child extended private key from the parent extended private key:

• I = HMAC-SHA512(cpar, serP(point(kpar)) || ser32(i))
• IL = I[0:32]

t-bast

Pinning discussion

t-bast

Asymmetrical features

Let's explore the following scenario. There is an asymmetrical feature F, with a clear client side and provider side. The client side of the protocol is activated by feature X. The provider side of the protocol is activated by feature Y.

Some nodes want to be a client, but not a provider, and want to connect only to nodes that are providers of this feature. They obviously turn on feature X. Since they are only clients of the feature, they cannot turn on feature Y, so how do they require their peers to support feature Y?

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

Trampoline error encryption

Trampoline nodes apply the same error-wrapping mechanism that's used for normal onions at the trampoline onion level. That means there's simply two layers of error wrapping.

Notations

We note ss(Alice, Bob) the shared secret between Alice and Bob for the outer onion encryption, and tss(Alice, Bob) the shared secret between Alice and Bob