What do these LN dynamics (which seem to have existed for a little while already now) have to do with Taproot?

OP was describing something in the context of Taproot and now you and others are talking about Lightning. What is the new development here?

Roughly, Taproot will make Lightning Transactions much more efficient and indistinguishable from simple transactions by introducing a new „Pay-To-Taproot“ validation type.

https://blog.chainalysis.com/reports/bitcoin-taproot-upgrade

Lightning channel opens/closes are 2-of-2 multisig transactions. Taproot would make them indistinguishable from singlesig transactions.

Whoa now, how did we start talking about lightning? Has it been lightning all the time? Because that's always supported instant, near-free transactions (with a _bunch_ of problems too, that I'll not worry about).

> In parallel to that, we plan to use Taproot’s new “tapleaf” script versioning scheme to implement Simplicity, our upcoming blockchain programming language.

https://medium.com/blockstream/taproot-activation-enhanced-t...

Does this stop a double spend?

Yes, why wouldn't it? The funds are locked in a 2 of 2 multisig address.

I'm confused then, doesn't this still need one transaction in the block chain for every transaction?

No, the transaction is fully signed and can be broadcast at any time by either party to settle. It doesn't have to be broadcasted and further transactions can be done on top and they just keep it private between themselves.

I'm missing how you can have a transaction that is not broadcasted but that prevents a double spend. Can't I give two different people signed transactions for the same bitcoins? How could the second recipient know I've already spent the balance on the first? Apologies for the no-doubt naive questions, it just sounds impossible.

There would first be 1 broadcasted on-chain transaction setting up the channel, with X of my bitcoin and Y of your bitcoin being locked up. This prevents double spend. Then, you and I pass n signed transactions between each other updating our balances Xt & Yt for each t, t+1, ...t+n. At any time, either one of us can broadcast the final transaction with the most up to date balance and unlock the coins.

So it requires one on-chain transaction per pair of parties instead of one per transaction? Clever and I suppose useful but seems a little limited in use, given that the funds are locked the whole time. Good for two parties that frequently have transactions going in both directions?

That's right. You can also form a chain of these channels, so Alice can pay Bob even though she doesn't have a channel with him, if they both connect to Carol using atomic transactions that update the 2 channels accordingly.

Is it that the not-on-the-Bitcoin-blokchain account gets updated on a separate "layer 2" Blockchain that's cheaper? If so, why would that second chain stay cheaper?

Lightning transactions are all final and irreversible via cryptography mechanisms.

Theres a timelock enforced by the blockchain.

Don't LN channels require a (quite expensive) transaction to open and close?

>quite expensive

Are you talking about compared to regular transactions, or because network fees (per byte) are high?

Quite expensive, as in $1?

That $1 enables as many transactions as you want between party A and B, of which party B may have dozens of open channels with other nodes to facilitate routing from party A to C etc.