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

remyers

The async-payment user story I'm interested in exploring is a mobile user (not always connected) who wants to receive donations (no PoP) via a static invoice from another mobile user.

My understanding of how this could work:

1. The static invoice should contain a blinded route to the payment receiver via their LSP and an ephemeral public key that the payment sender will use to encrypt the last hop of a payment onion containing a keysend TLV. The LSP of the payment receiver must support store-and-forward of onion messages.

2. A payment sender builds a payment onion where the first hop is their LSP that supports trampoline payments, onion messages and async-payments. The first hop of the onion includes a TLV to indicate the payment should be held until triggered (with a async-payment nonce) and gives the blinded route to the payment receiver. The last hop of the onion is encrypted to the payment receiver's ephemeral public key and includes:

• the keysend TLV payment secret
• the amount being sent

ariard

LDK Review Club 1st Session

Jun 21, 2022, 6 PM UTC, #review-club on LDK Slack.

lightningdevkit/rust-lightning#1507

Host: ariard PR author: ViktorTigerstrom

The PR branch HEAD was ae665ce at the time of this review club meeting.

AdamISZ

RIDDLE

Due to unexpected failures of github's LaTeX parsing (which were not evident until I published this, but have persisted afterwards), and since the mathematical parts are important in this, I have migrated this proposal to a blog post with identical content, but correctly formatted equations.

Please continue to put any comments here.

leonbreedt

#!/usr/bin/xcrun swift
//
// Copyright © 2016 Leon Breedt
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//

gavinandresen

O(1) Block Propagation

The problem

Bitcoin miners want their newly-found blocks to propagate across the network as quickly as possible, because every millisecond of delay increases the chances that another block, found at about the same time, wins the "block race."

xandkar

%%%----------------------------------------------------------------------------
%%% $ erl -noshell -s fibs main 40
%%% TRANSLATED ARRAY:    102334155   0.001755 seconds
%%% TRANSLATED LIST:     102334155   0.000048 seconds
%%% REVERSE ORDER LIST:  102334155   0.000004 seconds
%%% MINIMAL ARITHMETIC:  102334155   0.000001 seconds
%%% NAIVE RECURSIVE:     102334155   8.383385 seconds
%%%----------------------------------------------------------------------------