The main issue appears to be the assignment of values for types and feature bits, as well as ensuring that new features do not conflict with those already implemented by other developers. The developer suggests using a unique identifier for each feature instead of centralized number assignment, such as a hash of the feature name, to simplify independent testing before creating new pull requests for a BOLT assignment.The proposed solution is a new protocol called Experimental Features Protocol, which is intended for testing protocol features that may not become standard BOLTs. The protocol includes lightning base protocol messages and general experiment messages. The experiment message has a unique ID for each feature supported, and the payload should have the same format as a regular Lightning message described in BOLT #1. The sending node must send the init_experiments message with experiment_name_hash set to 0 before any other experiment message is sent. The receiving node must fail the channel if the experiment_name_hash is unknown or disabled and must fail all channels if channel_id is 0.The experimental features protocol aims to eradicate the chance of conflicting implementations by moving all experimental features to a new message where they are wrapped in a unique feature name. Additionally, this message can serve as a generic transport mechanism between any two lightning nodes who have agreed to support the experiment_name_hash, as there is no restriction on the format of the payload. This may make it possible to serve HTTP over Lightning.In addition, there is a suggestion to start having Lightning Network Improvement Proposals (LIPs) placed on the github.com/lightning account in a repo called lips, which would fill the gap between distributed ideas within the community and a centralized place to collect future enhancements for BOLT1.1. Some potential LIPs could include Watchtowers, Autopilot, AMP, Splicing, Routing Protocols, Broadcasting past Routing statistics, eltoo, and more.The current process surrounding creating, modifying and drafting BOLT documents needs to be better documented as confusion arose regarding the process. The current minimal process among various implementations has worked well so far but there may need to be more structure put in place to ensure transparency for newcomers. René Pickhardt recently proposed that they start having their own LIPs (Lightning Network Improvement proposals) in the grand tradition of BIPs. The LIPs should be placed on github.com/lightning account in a repo called lips or within the lightning rfc repo. A draft has already been created for LIP-0001 which describes the process and is 95% influenced by BIP-0002. René Pickhardt realized that many ideas are distributed within the community and there is no central place where future enhancements for BOLT1.1 can be collected. Potential LIPs could include watchtowers, autopilot, AMP, splicing, routing protocols, broadcasting past routing statistics, eltoo etc. Pickhardt volunteered to work on a LIP for Splicing. Olaoluwa Osuntokun asked why another repo was needed when they already have the equivalent of improvement proposals: BOLTs. Historically new standardization documents are proposed initially as issues or PR's when ultimately accepted.A member of the Lightning Network community proposed the creation of LIPs (Lightning Network Improvement Proposals) similar to BIPs (Bitcoin Improvement Proposals). The purpose of LIPs would be to collect future enhancements for BOLT1.1, which many ideas are currently distributed within the community and there is no central place to collect them. Potential LIPs could include watchtowers, autopilot, AMP, splicing, routing protocols, broadcasting past routing statistics, eltoo, and more. The proposer suggested that LIPs should be placed in the github.com/lightning account in a repo called lips or within the lightning rfc repo. However, another member of the community pointed out that BOLTs already function as improvement proposals and are historically proposed initially as issues or PRs when ultimately accepted. The original proposer apologized for spamming mailboxes with their suggestion because they misunderstood the current process.René Pickhardt, a contributor to the Lightning Network, has proposed the creation of Lightning Network Improvement Proposals (LIPs) in a similar vein to Bitcoin Improvement Proposals (BIPs). He suggests that these proposals be placed in a new repository called lips within the github.com/lightning account, or within the lightning rfc repo. The purpose of this proposal is to have a centralized location for future enhancements for BOLT 1.1, the current Lightning Network protocol. Potential LIPs could include watchtowers, autopilot, AMP, splicing, routing protocols, broadcasting past routing statistics, eltoo, and more. Pickhardt plans to work on a LIP for splicing.On July 22,