I’ve just opened pull requests for bips and implementation of a combination of BIP119, OP_CHECKSIGFROMSTACK(VERIFY) and OP_INTERNALKEY (together I’m calling these “LNHANCE”).
This combination of features seems to be a potentially safe and powerful starting point for bringing output restricting covenants to bitcoin and simultaneously supporting the next iteration of lightning development in the form of ln-symmetry and PTLCs.
(Copying across from my comment on the Core repo)
This should be opened to bitcoin-inquisition rather than this repo at this stage? I thought that was the whole point of bitcoin-inquisition. I can summarize why bitcoin-inquisition was introduced in the first place if that helps. It might seem overly finicky but having all proposed consensus changes (especially if they are new) discussed in the Core repo just adds too much noise to all the work that is being done on non consensus changes in Core (imo).
Also I’m interested in why you think LN-Symmetry would be better implemented not using APO?
Inquisition is fine, and I’m happy to open a separate PR there for CSFS and INTERNALKEY if that is helpful to reviewers or others in the community. It is not, however, part of the flow for changes to bitcoin core. 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.
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.
In contrast, CTV has a fairly narrow design space. The basic output commitment template is pretty clearly exactly as BIP119 describes it, and this can be combined with a well understood operation (CHECKSIGFROMSTACK) to provide the same committment as that used in @instagibbs LN-Symmetry implementation. Once we have CTV and CSFS in production for some time, we will be much better positioned to further analyze what other sighash modes might be useful for our next Tapscript key versions, or to analyze what hashing modes might be worth adding as a flags byte (or bytes) to CTV.
In short, this approach gives us small building blocks that are lowest common denominator for a variety of 2nd layer enhancements and position us to continue the discussion on future improvements.
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.
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.
Hi! Do you have a short list of the well-understood constructs that can be built using these, along with their relative idea maturity(your estimate is fine 
)?
I think it’d be useful to make it clear what you’re getting. E.g., PTLCs are definitely possible today, but APO-like construction is certainly leaps nicer!
Simple unidirectional NIC (non-interactive channel) that that is immune to TXID malleability and can be natural part of pool vTXOs (virtual UTXOs) from user Alice where you have a coordinator Bob that acts as an LSP:
<sigBob>
<sigAlice>
<template>
---
CHECKTEMPLATEVERIFY
<pubAlice>
OP_CHECKSIGFROMSTACKVERIFY
<pubBob>
OP_CHECKSIGVERIFY
You would have an alternative spending branch with a 24h timelock and Alice single sig. also have a 2-of-2 musig keyspend naturally.
Alice can keep giving Bob newer more favorable distributions. Bob gates them with his single sig.
What Alice would do is give Bob a new <sigAlice> <template> pairs and the new outputs that hash to the template to move funds to Alice. outputs can include HTLCs and then their updated settlement.
Would this also allow construction of other things that APO would? Namely channel factories and Spacechains?
Ping @RubenSomsen
indeed. LN-symmetry is an other big thing it enables. (will try to dig up the contract, pretty sure someone already laid it out) it won’t do everything APO can, and that’s on purpose. just the most important things that are highly desired.
edit:
# S = 500000000
# IK -> A+B
<sig> <state-n-hash> | CTV IK CSFSV <S+1> CLTV
before funding sign first state template:
# state-n-hash { nLockTime(S+n), out(contract, amount(A)+amount(B)) }
# settlement-hash { nSequence(2w), out(A, amount(A)), out(B, amount(B)) }
# contract for state n < m
IF
<sig> <state-m-hash> | CTV IK CSFSV <S+n+1> CLTV
ELSE
<settlement-hash> CTV
ENDIF
CLTV ensures only a larger nLockTime transaction can spend the current on-chain state, the relative timelock for the last co-signed state’s CTV distribution is committed to in the settlement-hash
Here’s a new one, Oracle slashing (just proposed).
That relates closely to simplified DLCs with CTV.
Timeout Trees, pretty well specified.
LN-Symmetry, as written by @instagibbs, ports directly to LNHANCE (probably all of uses for SIGHASH_ANYPREVOUTANYSCRIPT|SIGHASH_ALL).
Ark, as originally proposed by Burak, and depending on ephemeral anchors.
Simple coin pools (with n-n signing required to advance the state of the pool) simple to implement, only useful for small (e.g. family) groups.
Simple CTV Vaults implemented, but somewhat hard to use.
edit to add: Didn’t mention the basic ability of CSFS to be used in delegation. This is often not the best method, but can be useful. Script like <pubkey> SWAP IF 2DUP CSFSV DROP ENDIF CHECKSIG.
And many many many more that I don’t have immediate links to.
Spacechains are already possible without covenants, but yes, just about any covenant proposal that lets you pre-commit the next tx would be useful for spacechains.
Tonight, I created a PR against @ajtowns 's binana to create numbers for CSFS and INTERNALKEY.
I also created draft PRs for ctv, internalkey, csfs alone against core.
These 3 PRs include everything from #29198 except activation and functional tests that depend on CTV being active in regtest. They conflict with each other, due to overlap in SCRIPT_VERIFY_FLAGS numbers, which I’m not sure the best way to deal with.
According to rearden, this would allow for an APO spacechain-like construction. https://twitter.com/reardencode/status/1748452392046334366
Presumably helpful for statechains too.
a similar contract to LN-symmetry can be used for ‘immortal’ statecoins.
you can potentially do something even cooler, by stacking such constructs and thus transfer one end of an LN-symmetry channel, you can in theory reuse a single channel funding for any number of users.
in this case the final ‘distribution’ of the first channel opens the second (latest) one on-chain, then that has it’s own timeout for latest state.
I have been thinking as well about mechanisms with internal fees, i.e. the funds that will be used to pay onchain fees in case of unilateral exit are inside the mechanism, instead of requiring an additional UTXO to be kept onchain to pay for unilateral exits. This allows for reduced blockspace use by not requiring anchor outputs and a CPFP-ing transaction, at the cost of requiring funds to be reserved per mechanism for the onchain fee in case of unilateral exit. Here is an attempt to design an extension for OP_CHECKTEMPLATEVERIFY for this: `sighash_outputdeltabounds` - #2 by ZmnSCPxj
Hi, I’ve made a modified version of rust-bitcoin-script that can do an implementation of LN symmetry script, so anything that needs the bytes for script somewhere can easily get the right format.
Forgive me if my byte counts are off in the example, I wasn’t sure of the exact inputs.
I don’t yet have support for IK, but I think that’s a Taproot thing anyway, so not the same as script.
Thanks to @cguida for nudging me towards doing this. He’ll be using this or something like it in trying to make an LNHANCE CLN plugin.
Nice, thank you!
IKEY is Tapscript only indeed, as it reads the BIP341 internal key from the control block and writes it to the stack.