While in reality the txout tree isn’t actually being enforced, every bit of code interacting with the tree and each party can be tested as though it is, and since NOP and CheckSig are allowed in standard scripts, the protocol can be tested on mainnet with real funds.
I call this kind of testing a cargo cult protocol lmao.
Overall pretty great analysis. I'll probably reference it pretty often. I'm pretty hyperfixated on multi-party channels right now and I did already know that vtxos would be a helpful extension, but this does clear up a few implementation specifics I didn't know about yet. So thanks for that.
reply
Our first covenant-specic opcode proposal, OP_CheckTemplateVerify — or “CTV” as it’s commonly referred to — aims to create a very specific, restricted, covenant opcode by doing exactly one thing: hashing the spending transaction in a specified way that does not commit to the input UTXOs, and checking the resulting digest against the top stack element. This allows the spending transaction to be constrained in advance, without making true recursive covenant restrictions possible.
I had never really understood OP_CTV before reading this paragraph. Bravo
reply
Thanks!
reply
160 sats \ 5 replies \ @OT 2 Sep
This us the first I've heard about being technically able to open 1.1 billion LN channels per year.
reply
This is only for the outputs of the transaction. Would actually be much smaller in reality
reply
You can batch open lightning channels, and it doesn't take many in a batch to effectively amortize away the txins and change.
reply
0 sats \ 2 replies \ @OT 2 Sep
Yes, its hard to know how much block space LN will consume.
I was just surprised that these numbers would mean that its possible to have over 20k TX per block. I see 3-5k at the moment, but I don't think I've seen more that 6-7k. Is that because some TX have batched outputs?
reply
The numbers are about txouts, not transactions. They're assuming LN channels are batch opened, which is already implemented and commonly done.
reply
Yeah kinda
reply
Read the whole thing. Very technical and very detailed. I personally cannot follow it all but thank you so much for writing it for the plebs as a summary! Tons of links and things to research later... I personally liked this part:
"There is a good argument that we should get additional operational experience with Lightning and its approximately 1-UTXO-per-user scaling, before pushing the limits even further with UTXO sharing schemes." Makes sense to me! +1
reply
My personal recommendation: do a consensus cleanup soft-fork, followed by CTV
Great! :)
reply
21 sats \ 0 replies \ @anon 8 Sep
This is similar to the one of scenarios created by Paul Sztorc in 2022. He called it "The (Implausible) Best Case Scenario" and noted that these assumptions "are quite absurd." https://www.truthcoin.info/blog/lightning-limitations/ What do you all think about this?
reply
This is a fantastic article. Well-researched, neatly formatted, full of references, great summaries and an unbiased view of the current Bitcoin layer-2 space.
My compliments to the chef. 😙🤌
reply
Wow! Amazing review! So much to gulp in there. I'm reading it slowly and slowly, trying to understand.
Thanks @petertodd for this question answer format!
reply
Thanks for sharing, I will try my best to comb through it even though it looks to be very technical! Great work putting this out for the community to review !
reply
This post is sus 🤨🤨🤨
reply
10 sats \ 0 replies \ @k00b 2 Sep
Why?
reply
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.