Single-option large channel proposal #596

araspitzu · 2019-04-02T15:47:42Z

This PR allows peers to lift the channel size limit with a single option option_support_large_channel, it subsumes the previous PR #590. The option means that the offering peer supports opening large channels, a peer willing to send a large htlc should refer to channel_update.htlc_maximum_msat to check if a certain channel can route that.

Rename `globalfeatures` to `channelfeatures` and `localfeatures` to `nodefeatures`.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

You can still gossip. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

If we really want a new gossip message which old nodes will ignore, we'll use a new type, so having it discard unknown features is overzealous. Each feature can itself specify how it's advertized here: an key-exchange-instead-of-hash-preimage feature would need to advertize as even (you need to understand it to use it), for example, but a wumbo feature would advertize as odd. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This lets you find out what nodes support what node features, rather than connecting and probing. Like channel_announcement, we won't use feature bits for incompatible changes; we'll use a separate type. So don't discard messages with unknown ones. Similarly, you can try to connect to a node with unknown bits; you might fail, but that's OK. Either it was an unknown node feature, and you'll find out from their init msg, or it's a channel feature and you won't be able to open a channel. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

09-features.md

rustyrussell · 2019-06-10T21:12:39Z

Technically, this is a local/node feature since it only effects direct peers.

And #571 supports advertizing those features via node_announcement, see 14ced3b

araspitzu · 2019-06-11T08:07:11Z

@rustyrussell right! I took the wrong bits from the temporary assignment in #571, this was meant to use the nodefeature bits as in what previously was called option_i_wumbo_you_wumbo with bits 14/15, I will update the PR.

t-bast · 2019-06-11T09:40:38Z

After re-reading through #571, I agree with @rustyrussell: this is a node feature.

In #605 there are both node and channel feature flags for this. I think the option_wumborama channel flags aren't useful, should we remove them? Or can you explain why you think they are useful? In my opinion just looking at the channel capacity and htlc_maximum_msat give you all the information you need for routing.

araspitzu · 2019-06-11T09:59:05Z

@t-bast indeed this PR does not propose to use option_wumborama on the channel flags but uses a single-option and it should go in the node features (once we unify feature bits). As per description the option means that the offering peer supports opening large channels, a peer willing to send a large htlc should refer to channel_update.htlc_maximum_msat to check if a certain channel can route that.

07-routing-gossip.md

rustyrussell · 2019-06-24T21:17:12Z

09-features.md

+
+| Bits | Name             |Description                                     | Link                                                                |
+|------|------------------|------------------------------------------------|---------------------------------------------------------------------|
+| 14/15 | `option_support_large_channel` | Can create large channels		   | [Rationale](#Rationale) |


I think that link is broken, since Rationale is in a separate BOLT?

Isn't it below at line 45? Rationale

…OLT lightning#1

araspitzu · 2019-07-03T14:48:48Z

Summary of the latest changes:

Rebased on Feature bit unification and renaming #571
Updated feature bits to 8/9
Moved rationale to BOLT-2 replacing old section about the current limit

We simply specify, in each case, where they will appear ("Context"). We replace the `globalfeatures` field in init with a zero. Note also: we REQUIRE minimal `features` field in channel_announcement, since otherwise both sides of channel will not agree and not be able to create their signatures! Consider these theoretical future features: `opt_dlog_chan`: a new channel type which uses a new discrete log HTLC type, but can't support traditional HTLC: * `init`: presents as odd (optional) or even (if traditional channels not supported) * `node_announcement`: the same as above, so you can seek suitable peers. * `channel_announcement`: presents as even (compulsory), since users need to use the new HTLCs. `opt_wumbochan`: a node which allows channels > 2^24 satoshis: * `init`: presents as odd (optional), or maybe even (if you only want giant channels) * `node_announcement`: the same as above, so you can seek suitable peers. * `channel_announcement`: not present, since size of channel indicates capacity. `opt_wumbohtlc`: a channel which allows HTLCs > 2^32 millisatoshis: * `init`: presents as odd (optional), or even (compulsory) * `node_announcement`: the same as above, so you can seek suitable peers. * `channel_announcement`: odd (optional) since you can use the channel without understanding what this option means. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Restore gflen field, as (unreleased) implementations are using it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The feature fields refer to the properties of the channel/node, not the message itself, so we can still propagate them (and should, to avoid splitting the network). If we want to make an incompatible announcement message, we'll use a different type, or insert an even TLV type. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>

…hannel_support # Conflicts: # 01-messaging.md # 02-peer-protocol.md # 04-onion-routing.md # 07-routing-gossip.md # 09-features.md

araspitzu · 2019-10-03T15:37:19Z

Summary of the changes up to 8af0535:

Uses flat features from Flat features: far simpler solution for feature bits. #666
Uses feature bits 14/15 (they're mostly placeholders until actual bits are assigned)

09-features.md

…ement message

t-bast

ACK! We can hopefully merge that around the same time we merge #666

# Conflicts: # 01-messaging.md # 02-peer-protocol.md # 09-features.md

# Conflicts: # 09-features.md

araspitzu · 2020-01-27T08:52:20Z

Commit d5a8978 resolves conflicts with master and updates the feature bits to 48/49, those requested in the waiting room #605

t-bast

ACK d5a8978

09-features.md

Add missing column Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>

araspitzu · 2020-02-04T08:58:19Z

As discussed on the last spec meeting I've updated the feature bits to 18/19 in commit 660dd2e cc: @cdecker

t-bast

ACK 660dd2e

t-bast · 2020-02-18T08:20:38Z

Merging as agreed during the meeting: http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-02-17-19.06.html

A follow-up PR with an advisory for confirmation scaling depending on funding amount will be submitted shortly.

araspitzu mentioned this pull request Apr 3, 2019

BOLT 9: add features wumbo and wumborama #590

Closed

rustyrussell added 5 commits May 6, 2019 16:23

BOLT 1, 7, 9: rename feature bits, combine in gossip.

bb479a8

Rename `globalfeatures` to `channelfeatures` and `localfeatures` to `nodefeatures`.

BOLT 9: Note that features share the same number space.

733428e

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

BOLT 1: don't need to disconnect on unknown channelfeatures.

0f1f7c6

You can still gossip. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Roasbeef requested changes May 29, 2019

View reviewed changes

09-features.md Outdated Show resolved Hide resolved

t-bast added the Meeting Discussion Raise at next meeting label Jun 14, 2019

rustyrussell approved these changes Jun 24, 2019

View reviewed changes

Rebase on feature bits unification, use bits 8/9, move rationale to B…

a41e33e

…OLT lightning#1

araspitzu force-pushed the large_channel_support branch from 8c12568 to a41e33e Compare July 3, 2019 09:30

Move option_support_large_channel rationale to BOLT-2

b6573ee

niftynei removed the Meeting Discussion Raise at next meeting label Jul 22, 2019

t-bast added the Meeting Discussion Raise at next meeting label Aug 5, 2019

Remove 'channel_update.htlc_maximum_msat' max value restriction

0c78b3d

rustyrussell and others added 6 commits September 17, 2019 14:51

fixup! BOLT 9: flatten feature fields.

a3889b5

Restore gflen field, as (unreleased) implementations are using it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Fix-up!

2003ec8

Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>

Merge remote-tracking branch 'rusty/guilt/flat-features' into large_c…

bd74d03

…hannel_support # Conflicts: # 01-messaging.md # 02-peer-protocol.md # 04-onion-routing.md # 07-routing-gossip.md # 09-features.md

Rephrase to use flat features

8af0535

t-bast reviewed Oct 4, 2019

View reviewed changes

09-features.md Outdated Show resolved Hide resolved

Restrict option_support_large_channel to even bits in channel_announc…

e6157a9

…ement message

t-bast approved these changes Oct 4, 2019

View reviewed changes

t-bast mentioned this pull request Oct 4, 2019

BOLT2: Increase Bitcoin max chan size to 2^28-1 (~$10K) #579

Closed

araspitzu mentioned this pull request Nov 18, 2019

Waiting room for feature assignments #605

Closed

Merge remote-tracking branch 'origin/master' into large_channel_support

6f08b6e

# Conflicts: # 01-messaging.md # 02-peer-protocol.md # 09-features.md

araspitzu force-pushed the large_channel_support branch from d304484 to 6f08b6e Compare November 26, 2019 08:52

t-bast mentioned this pull request Jan 21, 2020

Lightning Specification Meeting 2020/02/03 #731

Closed

17 tasks

Merge branch 'master' into large_channel_support

d5a8978

# Conflicts: # 09-features.md

t-bast approved these changes Jan 29, 2020

View reviewed changes

t-bast reviewed Feb 3, 2020

View reviewed changes

09-features.md Outdated Show resolved Hide resolved

araspitzu and others added 2 commits February 3, 2020 20:06

Update 09-features.md

a067f23

Add missing column Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>

Use feature bits 18/19 for option_support_large_channel

660dd2e

t-bast approved these changes Feb 4, 2020

View reviewed changes

t-bast merged commit 3847935 into lightning:master Feb 18, 2020

araspitzu mentioned this pull request Feb 18, 2020

Add advisory section for wumbo channels confirmations #746

Closed

andrerfneves mentioned this pull request Mar 3, 2020

[WIP] Add post for socratic 102 BitDevsNYC/BitDevsNYC.github.io#50

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Single-option large channel proposal #596

Single-option large channel proposal #596

araspitzu commented Apr 2, 2019

rustyrussell commented Jun 10, 2019

araspitzu commented Jun 11, 2019

t-bast commented Jun 11, 2019

araspitzu commented Jun 11, 2019

rustyrussell Jun 24, 2019

araspitzu Jun 25, 2019

araspitzu commented Jul 3, 2019

araspitzu commented Oct 3, 2019

t-bast left a comment

araspitzu commented Jan 27, 2020

t-bast left a comment

araspitzu commented Feb 4, 2020 •

edited

Loading

t-bast left a comment

t-bast commented Feb 18, 2020

Single-option large channel proposal #596

Single-option large channel proposal #596

Conversation

araspitzu commented Apr 2, 2019

rustyrussell commented Jun 10, 2019

araspitzu commented Jun 11, 2019

t-bast commented Jun 11, 2019

araspitzu commented Jun 11, 2019

rustyrussell Jun 24, 2019

Choose a reason for hiding this comment

araspitzu Jun 25, 2019

Choose a reason for hiding this comment

araspitzu commented Jul 3, 2019

araspitzu commented Oct 3, 2019

t-bast left a comment

Choose a reason for hiding this comment

araspitzu commented Jan 27, 2020

t-bast left a comment

Choose a reason for hiding this comment

araspitzu commented Feb 4, 2020 • edited Loading

t-bast left a comment

Choose a reason for hiding this comment

t-bast commented Feb 18, 2020

araspitzu commented Feb 4, 2020 •

edited

Loading