This change aims to facilitate the direct connection of multi-party mechanisms, rather than having these mechanisms interact through two-party channel frameworks or presenting a single multi-party pool as several two-party channels within the Lightning Network. The existing network, primarily based on two-party channels, would then be considered a special case where the number of parties involved (N) equals two. To implement this, alterations in gossip protocols and onion routing, specifically for PTLCs, HTLCs, and onion messages, are necessary.

In terms of gossip protocols, the idea is to modify the channel_announcement message to support a variable number of nodes, with public keys and signatures from each node to indicate their willingness to route over this multi-party mechanism. By employing MuSig2 for signature aggregation, regardless of the number of nodes on a mechanism, only one Schnorr signature is required. However, there's a technical limitation due to BOLT8 restrictions, capping message payloads at 65535 bytes, which theoretically limits the number of nodes in a public multi-party mechanism to approximately 1000. Additionally, dynamic membership within these mechanisms requires the ability to add or remove nodes in gossiped channel_announcements.

The proposal also addresses concerns about gossip spam by suggesting changes to how channel_announcement outpoints are validated against the blockchain. Instead of requiring an unspent UTXO, the existence of the outpoint would suffice, rejecting channel_updates if the TXO is not a UTXO. This approach aims to limit data propagation to the size of the UTXO set, accommodating mechanisms like Ark that frequently update their main UTXO.

Pathfinding algorithms currently assume edges connect exactly two nodes. To integrate multi-party mechanisms, the proposal suggests treating N-party mechanisms as multiple two-party channels linked to a common "virtual" node. This virtual node represents the multi-party mechanism without being part of the actual pathfinding process.

Lastly, for onion routing, the introduction of multi-party mechanisms necessitates additional considerations for identifying the next hop in a route. Since a node could be part of various multi-party mechanisms, and so could the next node, a simple Short Channel ID (SCID) is insufficient for disambiguation. The proposal recommends using a "short node ID," derived from the last 12 or 16 bytes of the node ID, to adequately identify the next node in the routing hop. This modification is intended to maintain compatibility with legacy two-party channels while accommodating the complexities introduced by multi-party mechanisms.