Good morning list, I followed with some interest the discussion some days ago where MIT DCI Lit wanted to autodetect fellow Lit nodes using the BOLT protocol.
Now, my thoughts: 1. The desired feature, is essentially a question "is this node an X implementation?" 2. However, the feature bits we use currently, is essentially a question "has this node an X feature?" 3. Our feature bits are centrally allocated on the BOLT spec. This makes difficult, permissionless innovation. I think, "has-a" query is better than "is-a" query. But I admit that requiring that features allocate some feature bit are difficult, for the view of permissionless innovation, as it requires coordination across multiple implementations. Yet experimental extensions might be experimental. So rather than code, I decide to waste precious bandwidth and spam the mailing list again. I propose the concept of Unspecified Protocol Extensions. They are "unspecified" as they are not part of the BOLT specifications. Each such protocol extension must select its own random 20-byte identifier. It is strongly suggested that the name of the protocol extension be hashed with RIPEMD160 or some other hash. Alternately, the protocol extension developer can grab 20 random byte from random.org or from their local /dev/random. Further: 1. In BOLT messages, the `type` >= 49152 (0xC000 or more) is reserved for unspecified protocol extensions. 2. In onion hops, the `tlv` `type` >= 192 (0xC0 or more) is reserved for unspecified protocol extensions. 3. In `node_announcement`s with `tlv`, a specific `tlv` `type` is reserved for unspecified protocol extensions. At link level, we add the concept of "current extension". By default, at the start of a connection, there is no current extension and messages >= 49154 are unrecognized. The following new messages are defined. 1. `type`: `can_i_has_extension` (49152) 2. `data` * [`20`: `unspecified_protocol_extension_id`] This message queries if the receiver has a particular extension. The extension id composed of only 0s is the nonexistence of an extension. The sender may set the ID to 0. This indicates that the sender does not intend to send any particular extension in the foreseeable future. The receiver: * SHOULD reply with `i_has_a_extension`. * MAY reply with a `i_has_a_extension` with null ID to indicate it does not have the extension. The sender: * MUST NOT send any extension-specific messages until the other side indicates agreement to process extension-specific messages via `i_has_a_extension`. 1. `type`: `i_has_a_extension` (49153) 2. `data` * [`20`: `unspecified_protocol_extension_id`] This message indicates that the sender is capable of understanding the indicated unspecified protocol extension ID. The receiver can then send future messages within the range 49154->65535 and those will be interpreted as part of the protocol extension. The sender of this message may set the ID to all 0s. This indicates that the sender will not recognize succeeding messages as belonging to any particular extension, and implicitly denies a previous `can_i_has_extension` request. Note that message IDs 49154 to 65535 are effectively multiplexed across different protocol extensions. The message `can_i_has_extension` indicates that the sender would like to send messages with the specified protocol extension in the close future. The message `i_has_a_extension` indicates whether the sender would accept such protocol extensions. This sets the protocol extension for one direction of the channel only. If the protocol extension requires requests and responses from both sides of the connection, then both sides need to request the extension (via `can_i_has_extension`) independently of the other side. For each direction, only one protocol extension is the current protocol extension. For onion hops, the following additional `tlv` `type` is defined: 1. `type`: `im_in_yr_hop_extending_yr_protocol` (192) 2. `len`: 20 3. `data`: * [`20` : `unspecified_protocol_extension_id`] This indicates that future `tlv` `type`s in the range 193 to 255 are to be interpreted as belonging to the specific protocol extension. Similar to message codes, onion hop `tlv` `type`s 193 to 255 are effectively multiplexed across different protocol extensions. Note that this implies that only a single unspecified protocol extension can be used on a hop. An additional `node_announcement` `tlv` `type` is defined: 1. `type`: `hai_im_extended` (TBD) 2. `len`: multiple of 20 3. `data`: * [`len` : `unspecifed_protocol_extension_ids`] This `tlv` type advertises support for the indicated unspecified protocol extensions. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev