LNHANCE a soft-fork package

[moonsettler]

Dear List,

We propose to introduce a soft-fork package named LNHANCE Bitcoin, which is made up of 4 opcodes:

OP_CHECKTEMPLATEVERIFY (CTV): https://github.com/bitcoin/bips/tree/master/bip-0119.mediawiki
OP_CHECKSIGFROMSTACK (CSFS): https://github.com/bitcoin/bips/blob/master/bip-0348.md
OP_INTERNALKEY (IKEY): https://github.com/bitcoin/bips/blob/master/bip-0349.md
OP_PAIRCOMMIT (PC): https://github.com/lnhance/bips/blob/paircommit/bip-0442.md

Soft-fork Implementation:
https://github.com/lnhance/bitcoin/pulls

Website:
https://lnhance.org

It would be possible to replace CTV with TEMPLATEHASH (TH) and PC with CAT. I would not be opposed to that personally.

However these 4 opcodes were selected to reduce the unintended consequences as much as possible, while still give us an
efficient LN-Symmetry (formerly eltoo) implementation. (see BIP-442 for details!)

The following behaviors are out of scope for LNHANCE and should not be enabled as a side effect without explicit consensus:

- Fine-grained introspection
- State-carrying covenants
- Bigint operations
- New arithmetic capabilities using lookup tables

Q: Why not CAT instead of PC?
A: CAT enables introspection, including parent transaction introspection, state carrying and script intractable exogenous asset protocols.
This was way out of scope for the intended changes and possibly way out of the comfort zone of many bitcoiners.

Q: Why CTV and not TEMPLATEHASH?
A: We don't see anything technically wrong with TH, makes an even more efficient LN-Symmetry implementation possible.
The main contention by some of us is that by committing to the annex, it provides a motivation to start relaying non-empty annex.

Q: Why not use the annex?
A: Unstructured annex is the perfect place for any inscription or exogenous asset protocol payload.
We wished to avoid introducing additional social trauma resulting from new token hype cycles.

Q: Is TH+IKEY+CSFS an acceptable alternative to LNHANCE?
A: Supports most of the target use cases. It is a viable alternative.

Q: Is there a signet?
A: Not currently, we are working on setting it up this month.

Q: Will you open a PR to core?
A: That has been tried in the past and proven to be a dead end.

Q: Is there an activation client?
A: Yes, code is maintained, however it is way under reviewed. No binary releases for now. If you can build it, you can run it!

Q: What kind of activation are we talking about?
A: Modified BIP-9 with LOT=true and MUST_SIGNAL phase added. But whatever people want, that part is not so interesting.
Proposed params: https://github.com/lnhance/bitcoin/commit/193e34e2fef9111308251af85a6a122425960c36

Q: Paul Sztorc said the Lightning Network (LN) is a fraud, are you trying to perpetuate a fraud?
A: Maybe. We believe this package would make LN and LN adjacent other L2s (covenant pools, timeout trees, Ark, etc.) better and more scalable.

Q: How can I help?
A: Code reviews are most needed. We have structured the commits so, that you can focus on the changes most interesting to you.

Q: Who is sponsoring this work?
A: We accept anonymous donations with no strings attached.

BR,
moonsettler

[Brandon Black]

As the original proposer of LNHANCE, let it be known that I still think
it's a great direction for bitcoin script improvements. This set of
opcodes is carefully crafted to offer significant utility with minimal
footguns or even sharp corners.

I am also a fan of the competing TEMPLATEHASH+CSFS+IKEY proposal which
removes the blunted corner of modifying legacy script while adding the
blunted corner of committing to the annex. It also removes the hacky
sibling commitment via scriptSig, loses the ability to use simple vaults
with legacy ECDSA-only signing infrastructure, and saves just under 8vB
in a typical lightning symmetry uncontested force close scenario.

Both are excellent directions to move bitcoin script and I hope to see
one of the two enforced on the network in the (not too distant) future.

Best,

--Brandon