From 8b8d40defc6a85d35617a4e49e12deccd062dbd1 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Tue, 5 Nov 2019 16:03:34 +1030 Subject: [PATCH] BOLT 4: add capacity_order to temporary_channel_failure. With AMP, we'll effectively be probing for channel capacity. Returning how far out a payment was provides a hint. You can determine the order required, then fuzz it a little, eg: switch(rand(8)): case 0: increase, retry; case 1: decrease, retry; case 2-8: stop; Signed-off-by: Rusty Russell --- 04-onion-routing.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/04-onion-routing.md b/04-onion-routing.md index 17851c7..9205a33 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -766,9 +766,12 @@ The ephemeral key was unparsable by the processing node. 2. data: * [`u16`:`len`] * [`len*byte`:`channel_update`] + * [`u8`:`capacity_order`] (`option_capacity_order`) The channel from the processing node was unable to handle this HTLC, -but may be able to handle it, or others, later. +but may be able to handle it, or others, later. The optional +`capacity_order` field gives a very rough indication of how far over +the channel capacity this htlc amount was. 1. type: PERM|8 (`permanent_channel_failure`) @@ -918,6 +921,8 @@ A _forwarding node_ MAY, but a _final node_ MUST NOT: transient error occurs in the outgoing channel (e.g. channel capacity reached, too many in-flight HTLCs, etc.): - return a `temporary_channel_failure` error. + - MAY set `capacity_order` to the approximate number of powers of 2 that the HTLC amount exceeded the available capacity. + - SHOULD randomize `capacity_order`. - if an otherwise unspecified, permanent error occurs during forwarding to its receiving peer (e.g. channel recently closed): - return a `permanent_channel_failure` error.