valentinewallace

Keybase proof

I hereby claim:

• I am valentinewallace on github.
• I am valwal (https://keybase.io/valwal) on keybase.
• I have a public key ASCH4xTSpFFzi3kfH3l5YoB_6gEmKtBaaaCfCP8lYYXg6wo

To claim this, I am signing this object:

valentinewallace

// baseline estimates
var TX_EMPTY_SIZE = 4 + 1 + 1 + 4
var TX_INPUT_BASE = 32 + 4 + 1 + 4
var TX_INPUT_PUBKEYHASH = 107
var TX_OUTPUT_BASE = 8 + 1
var TX_OUTPUT_PUBKEYHASH = 25


function coinSelect (utxos, outputs, feeRate) {
    // sort by value from high to low

valentinewallace

Introduction

This document outlines a new payment probing scheme based on onion messages.

For context, in today’s lightning, payment reliability tends to heavily depend on having sufficient payment volume to determine current liquidity balances of channels, which is how most big nodes can tell whether a given channel has enough liquidity to forward a given amount. If a node is using HTLC probing to achieve this payment volume, they use a regular update_add_htlc message with a bogus payment hash, where the error returned informs the sender of whether the payment reached the final recipient. Note that there is a tradeoff between always routing through nodes that are known to rebalance their channels vs leaning on probing smaller nodes and “risking” payments through them based on what’s learned.

Today’s HTLC payment probing can work well, but risks channel liquidity being locked up if a peer along the route goes offline. On the upside, for just-in-time probes, it works to loosely “reserve” the channel

valentinewallace

Intro

An issue with BOLT 12 for async payments is that recipients may be offline when the payer sends them their invoice request. However, their channel counterparty is likely to be an always-online node. Here we outline a scheme for always-online channel counterparties (e.g. LSPs) to supply BOLT 12 invoices on behalf of often-offline receivers when requested by payers.

Proposed Protocol

TL;DR when creating an offer, the receiver will give their counterparty a payment_hash-less (or "keysend") invoice. Later, when the payer sends an invoice request to the receiver, the payer will include an encrypted reply path in the onion payload destined for the counterparty. The counterparty will then send the aforementioned keysend invoice over the reply path to the payer.

1. Counterparty sends receiver a 16-byte unique_salt and 16-byte encrypted_counterparty_secret

• encrypted_counterparty_secret is a static counterparty_secret encrypted with ChaCha20-Poly1305 using counterparty_secret itsel