LNHANCE bips and implementation

[michaelfolkson]

@reardencode

It is an optional place to test significant changes before they are proposed for activation in bitcoin core if that is helpful to the process for any particular change.

I mean… sure it is optional. But if everyone takes your approach we get tens of different PRs in the Core repo from different authors all with different combinations of their favorite opcodes and sighash flags and supposedly that helps review and makes progress towards activation. In a repo that already suffers from being unnecessarily noisy. But ok, whatever.

@reardencode

APO is one way to achieve LN-Symmetry. In the range of possible ways to achieve LN-Symmetry, APO is somewhat of a closed development path. It introduces new key types for the existing sigops with a concrete set of sighash flags that cannot later be upgraded without adding another new set of key types. I have a PR open against APO that suggests an alternative design for those sighash flags, and there is a known issue that they should be changed to commit to the control block or merkle path to the script being executed in some modes. In short, there is a large design space for those sighash flags and a lack of direct upgradeability.

Thanks, I wasn’t aware of this BIP PR you opened. I suspect that isn’t a universally agreed “known issue” unless you can point me to a different discussion I missed. But it does introduce a new public key type, if that’s your criticism I guess that holds.