Waiting room for feature assignments

[rustyrussell]

trafficstars

Features are assigned along with spec approval, so they don't happen in this order, but here's a list of things with made-up assignments for testing:

New local / node features:

Bits	Name	Description
18/19	option_simplified_commitment	New commitment transaction format
20/21	option_error_codes	error message contains error code
22/23	option_splice	Funding transactions can be upgraded
24/25	option_i_wumbo_you_wumbo	Can create large channels
28/29	option_dual_fund	Flexible funding negotation
30/31	option_will_fund_for_food	node_announcment contains funding rate
32/33	option_2p_ecdsa	Single-key funding negotiation
34/35	option_inv_gossip	Gossip pulled rather than pushed
36/37	option_fec_gossip	Gossip set reconciliation
38/39	option_schnorr_gossip	Compact gossip messages
40/41	option_offer_tx_proof	Can provide tx proofs
42/43	option_want_tx_proof	Wants tx proofs
48/49	option_static_remotekey	Static key for remote output, symmetric delays

And our first global / channel features:

Bits	Name	Description	channel_announcment
26/27	option_wumborama	Can handle large payments	Odd
44/45	option_status	Sends soft-error status responses	Odd
46/47	option_switch_ephkey	Can switch ephemeral keys	Odd

[rustyrussell]

This was actually assigned at the IRC meeting:

Bits	Name	Description
8/9	option_variable_onion	Supports new onion format a-la #619

[rustyrussell]

This was assigned at the IRC meeting:

Bits	Name	Description
10/11	option_extended_gossip_queries	Supports flags/checksums/timestamps a-la #557

[t-bast]

This was assigned at the IRC meeting:

Bits	Name	Description
12/13	option_static_remotekey	Static key for remote output

[t-bast]

I'd like to reserve the following bits in the waiting room:

Bits	Name	Description
50/51	trampoline_routing	allow payments via trampoline nodes
52/53	gossip_filters	allow gossip filters

[araspitzu]

#596 implements wumbo with a single option so i'd like to reserve the following bits for it:

Bits	Name	Description
48/49	option_support_large_channel	Can create large channels

[halseth]

Should we decide on a range of bits to use for experimental features?

[t-bast]

I think you can safely use values > 255, I don't expect us to finalize that amount of features in the foreseeable future :D Or simply reserve bits 54/55 (or any higher value) here so that other people don't use it for a conflicting experimentation?

[cdecker]

I'd like to reserver the following bits

Bits	Name	Description
54/55	keysend	This node supports the keysend protocol for spontaneous payments

Notice that this is only really relevant for node_annoucements and should only ever be used in the optional variant bit=55, since it is and likely will always be an optional feature.

[cdecker]

I think you can safely use values > 255, I don't expect us to finalize that amount of features in the foreseeable future :D Or simply reserve bits 54/55 (or any higher value) here so that other people don't use it for a conflicting experimentation?

The problem with setting aside a range is that it'd be rather in the high bit range, thus every experimental feature will immediately blow up the size of the featurebit strings (bits>255 result in 32 bytes of mostly empty featurebit strings).

[t-bast]

For the record, here are feature bits that we will use for experimental features in Phoenix:

Bits	Name	Description
128/129	zero_reserve_channels	This node may have an empty channel reserve
130/131	zero_conf_channels	This node accepts unconfirmed channels
132/133	wake_up_notification_client	This node can be woken up by push notifications
134/135	wake_up_notification_provider	This node can send push notifications to nodes that support it
136/137	pay_to_open_client	This node accepts paying for on-the-fly channel creation
138/139	pay_to_open_provider	This node can open channels on-the-fly
140/141	trusted_swap_in_client	This node accepts channel creation via trusted swaps-in.
142/143	trusted_swap_in_provider	This node can open channels in exchange for a swap-in.
144/145	channel_backup_client	This node can send backups to be stored by its peers.
146/147	channel_backup_provider	This node can store backups on behalf of their peers.
154/155	splice_prototype	Prototype to experiment with splicing

They aren't announced to the network yet, but our node may start announcing wake_up_notification_provider, pay_to_open_provider, trusted_swap_in_provider and channel_backup_provider in the future. This will make it easier for us to then transition to official features when they land.

[ZmnSCPxj-jr]

https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/23

Bits	Name	Description	Context
729	option_lsps0_lsp	This node is an LSPS LSP conforming to the LSPS0 specification.	IN

[rustyrussell]

Closing this, as we now assign issues in the titles of PRs.