PolyD_ on Nostr: I wish I could easily describe the nuances and complexities to why we should continue ...
I wish I could easily describe the nuances and complexities to why we should continue upgrading, let alone why one design choice is better than another.
APO's design path is final.
"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."
Once we had implemented Taproot, it was final, if APO has been included with Taproot, it'd be great, no need of this duplicate the key type + 1 single feature. We can't build off it, we'll just duplicate key types again.
So why do we want APO in the first place? The original design choice of Lightning used it before it was later changed to HTLC's. Implementing time locks was a better design choice because the design scope was minimum and the risk analysis was more concrete. Those were our first covenants, simple time locks.
But here's the problem. We didn't actually create proper channels inside Script. We have this bi-state channel syndrome. We call this Asymmetry. Alice has her version of reality and Bob has his version of reality. And we're agree on the final state of reality when closing the channel.
Our original channels that used nSequence didn't do this, we agreed on the final payment, we didn't need our own versions of the transactions. But it was unsafe. 0-confirm transactions are second rate. Someone could sneak in an old state into a block and there was no way to prevent the theft.
So we restored channel functionality with time locks. This window of time allows us to defer commitments to on-chain and create backpressure on blockspace demand. We extended this to routing and envisioned Lightning as a mesh network on this method of deferring chain commitments.
But this symmetry of channels still plagues us. It creates many inefficiencies and prevents many use-cases because Alice and Bob never agree until close-out. APO allows us to agree on payout, just not on pay-in. This would provide symmetry and reduce complexity of channels.
After almost a decade of research, another covenant type with a narrow design window was finalized, output commitments. I like to call them TXID locks or UTXO locks. And what do you call a group of UTXO locks? A Template.
Check Template, Verify. It sounds so simple yet it eludes even the best. If Taproot and Schnorr Signatures provided Signature Aggregation, CTV provides Transaction Aggregation. Like tapscript, you can build trees with CTV. BitVM has a brother.
Like channels, output commitment covenants opens up a window of time in which people can work together to coordinate and save on commitment space on-chain. I tried to explain this emergent behavior on internal scaling with Enigma.
And Enigma has been quite the enigma to many. Especially with a lot of developers. The problem is we've shoehorned out thought process with only channels and have blinders on. We're always thinking about the single next on-chain commitment, never ahead or behind.
CTV fixes two issues, the L2 exit problem. Withdraw from an exchange to LN. On collab closing, move it to another L2 or channel. You can always defer going on-chain, just keep making Templates of what you want to do. Also, payments can be made without needing 0-confirm.
So why don't some developers like it? They're plagued by the bi-state asymmetry still! But it's like asking a fish to fly. CTV has one job. Make Templates. It can also be extended to either TXHASH or TEMPLATE KEY with no issues. It has no closed path development issues like APO.
So what's LNHANCE? it has 3 BIPs. CTV, CSFS (CheckSigFromStack) and IK (Internal Key). IK is simple, it's a 1 byte substitute for a 32-byte key so it's just a space reduction with no design change. CSFS allows us to defer signatures which will allow us to defer channel payments.
This will fix the asymmetry problem and provide us with what's known as LN-Symmetry. This will allow us to build a network of trees filled with symmetry channels that will probably scale beyond anything I can even begin to imagine.
But I don't need CSFS. I think we should fix our channel asymmetry issue and I think LNHANCE is the right choice, but I just need CTV trees. Templates will unlock so many possibilities that just aren't possible today. The very concept of Cold Channels is so alien. No wonder developers can't get it. I don't blame them at all.
I believe we should continue exploring these pockets of time of where we can defer something essential to us and our means of payment. There is still so much left to explore and I hope we're able to do that. Our signal has become so broken and we can't agree on anything anymore. Let us come to consensus one more time.
APO's design path is final.
"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."
Once we had implemented Taproot, it was final, if APO has been included with Taproot, it'd be great, no need of this duplicate the key type + 1 single feature. We can't build off it, we'll just duplicate key types again.
So why do we want APO in the first place? The original design choice of Lightning used it before it was later changed to HTLC's. Implementing time locks was a better design choice because the design scope was minimum and the risk analysis was more concrete. Those were our first covenants, simple time locks.
But here's the problem. We didn't actually create proper channels inside Script. We have this bi-state channel syndrome. We call this Asymmetry. Alice has her version of reality and Bob has his version of reality. And we're agree on the final state of reality when closing the channel.
Our original channels that used nSequence didn't do this, we agreed on the final payment, we didn't need our own versions of the transactions. But it was unsafe. 0-confirm transactions are second rate. Someone could sneak in an old state into a block and there was no way to prevent the theft.
So we restored channel functionality with time locks. This window of time allows us to defer commitments to on-chain and create backpressure on blockspace demand. We extended this to routing and envisioned Lightning as a mesh network on this method of deferring chain commitments.
But this symmetry of channels still plagues us. It creates many inefficiencies and prevents many use-cases because Alice and Bob never agree until close-out. APO allows us to agree on payout, just not on pay-in. This would provide symmetry and reduce complexity of channels.
After almost a decade of research, another covenant type with a narrow design window was finalized, output commitments. I like to call them TXID locks or UTXO locks. And what do you call a group of UTXO locks? A Template.
Check Template, Verify. It sounds so simple yet it eludes even the best. If Taproot and Schnorr Signatures provided Signature Aggregation, CTV provides Transaction Aggregation. Like tapscript, you can build trees with CTV. BitVM has a brother.
Like channels, output commitment covenants opens up a window of time in which people can work together to coordinate and save on commitment space on-chain. I tried to explain this emergent behavior on internal scaling with Enigma.
And Enigma has been quite the enigma to many. Especially with a lot of developers. The problem is we've shoehorned out thought process with only channels and have blinders on. We're always thinking about the single next on-chain commitment, never ahead or behind.
CTV fixes two issues, the L2 exit problem. Withdraw from an exchange to LN. On collab closing, move it to another L2 or channel. You can always defer going on-chain, just keep making Templates of what you want to do. Also, payments can be made without needing 0-confirm.
So why don't some developers like it? They're plagued by the bi-state asymmetry still! But it's like asking a fish to fly. CTV has one job. Make Templates. It can also be extended to either TXHASH or TEMPLATE KEY with no issues. It has no closed path development issues like APO.
So what's LNHANCE? it has 3 BIPs. CTV, CSFS (CheckSigFromStack) and IK (Internal Key). IK is simple, it's a 1 byte substitute for a 32-byte key so it's just a space reduction with no design change. CSFS allows us to defer signatures which will allow us to defer channel payments.
This will fix the asymmetry problem and provide us with what's known as LN-Symmetry. This will allow us to build a network of trees filled with symmetry channels that will probably scale beyond anything I can even begin to imagine.
But I don't need CSFS. I think we should fix our channel asymmetry issue and I think LNHANCE is the right choice, but I just need CTV trees. Templates will unlock so many possibilities that just aren't possible today. The very concept of Cold Channels is so alien. No wonder developers can't get it. I don't blame them at all.
I believe we should continue exploring these pockets of time of where we can defer something essential to us and our means of payment. There is still so much left to explore and I hope we're able to do that. Our signal has become so broken and we can't agree on anything anymore. Let us come to consensus one more time.