LNHANCE bips and implementation

LNHANCE bips and implementation

Original Postby michaelfolkson

Posted on: January 7, 2024 19:55 UTC

The discussion revolves around the use of an optional place for testing significant changes before proposing them for activation in Bitcoin Core.

While this is optional, the concern raised is that without a unified approach, the repository could become cluttered with numerous pull requests from different authors, each incorporating their preferred opcodes and sighash flags. This scenario is likely to exacerbate the issue of noise within the repository, which already poses challenges.

An important point highlighted is the goal of achieving LN-Symmetry, with APO (Alternative Public Outputs) being one method among many. However, APO is critiqued for potentially limiting future development. It introduces new key types for existing signature operations (sigops) paired with a set of sighash flags that are not easily upgradable—any future upgrades would necessitate the introduction of additional key types. An open PR against APO presents an alternative design for these sighash flags, indicating that there's substantial room for deliberation over their design. Moreover, it is mentioned that there's a recognized issue whereby the flags should commit to either the control block or the merkle path to the script in execution during certain modes, signifying a lack of direct upgradeability.

The conversation also touches upon a specific BIP PR, which was not known to one of the discussants. The point of contention seems to be whether the issues raised are universally acknowledged as 'known' within the community. Nonetheless, there is an acknowledgment that APO introduces a new public key type, a fact that stands regardless of differing opinions on its implications.