A second layer transaction does not involve the Bitcoin network.

When Katy wants to pay ₿3 to Billie, Katy just sends a key (via email or some API) to Billie which enables Billie to withdraw ₿3 from the account of Katy. But Billie does not do that. Billie just keeps that message like you keep your login to your bank account.

When Katy wants to pay another ₿5 to Billie, Katy sends a key to Billie which enables Billie to withdraw ₿8 from the account of Katy.

Now Katy paid Billie ₿8 in two transactions. All via email, letter, telephone or - most likely - API. Nothing at all happened on the Bitcoin network.

However, if nothing happens on the Bitcoin network, then the funds aren't locked down, are they?

In other words, Billie has no guarantee that the key she holds will be valid tomorrow; Katy could empty that account at any time, and Billie would then hold nothing except the evidence of Katy's wrongdoing.

Bitcoin supports post dating transactions. The transaction can be updated between parties, off chain. Lightning Network. If a bad actor gets involved, the last transaction updated between both parties rules and is the remainder is refunded upon the timeout of the post dating.

This function is provided by script: https://en.bitcoin.it/wiki/Script

> However, if nothing happens on the Bitcoin network, then the funds aren't locked down, are they?

they are locked down. the funds in a lightning channel are locked in a 2 of 2 multisig address, and can only be moved upon mutual consent (ie. by updating the state of the channel), or by one party after sufficient time has passed (in case of an uncooperative peer).

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.

    Katy could empty that account at any time

That would be a pretty lame virtual bank then :)

Realistically, the spending conditions are either limited by time. So Billie knows she needs to withdraw until a certain date or Katy could betray her. Or the spending conditions contain a punishment for betrayal. So if Katy tries to withdraw money she assigned to Billie, Billie can intervene, get her money and punish Katy.

Can you send 8worthless$ using that method, then move money out of the account via normal transfer?

no, because the funds are locked down while in the lightning channel. see: https://news.ycombinator.com/item?id=29228483

> VIA email or API

Isn’t this an example of a centralized bottleneck?

Parent talks about the „Lightning Network“ — a Layer 2 scaling solution for Bitcoin. Beware: I am still a crypto noob but I am still going to try to explain how I understood the system so far. Edited: Minor terminology and typos.

Roughly speaking the Lightning Network works similar to a „current account“ that businesses have between each other but does not require the actors to trust each other. The parties initiate a transaction by each one sending Bitcoin to a public multi signature address. The resulting transaction cannot be spent by any one alone. Now, this unspent transaction serves as an initial balance and opens a channel between the parties on the layer 2 network. Bitcoin may now be wired back and forth between the parties on layer 2 w/o needed to be settled individually on the Bitcoin block chain. Finally, if all parties agree by signing a second, settling transaction the resulting balance is written back to the Blockchain to whatever address the participants initially agreed upon. Theoretically, there could have been billions of Bitcoin transactions over the years on the Lightning Network which would be eventually represented by only two transactions on the chain.

Now, taproot improves this scheme by introducing Schnorr signatures. Up to now every member of the multisig transaction I just talked about needed to contain the public keys of all parties which in turn needed to be verified against all their private keys. Since transactions are limited in their size, this limited the applicability of multisig transactions. Now, Schnorr signatures allow for aggregation of public keys so the transaction only needs to contain a single number instead of hundreds or thousands. Of course, this also speeds up validations of transactions.

I hope this all made sense. I have yet to see practical applications of a Lightning Network „scheme“ but I heard El Salvador is using it for cheap Bitcoin transactions (although not applying Schnorr signatures yet).

The other half of the Taproot update besides Schnorr signatures is support for MASTs: Merklized Abstract Syntax Trees. This allows you to create scripts (smart contracts) where only the used part of the script needs to be revealed when the funds are transferred. Other parts which were not used—for example, the clauses related to recovering funds in the event of a non-cooperating peer in a Lightning channel when the channel is closed normally—need not be included in the transaction, which both improves privacy and reduces the transaction size (and thus also the fees).

So, basically, a dead code elimination scheme?

I do wonder how it could ensure the code running is the actual code signed for as its hash would be different though.

Because the code is rearranged into a top level arbitrary tree ORs and the hashing commits to this tree.

At signing time, the signer reveals a hash for every non-taken branch, so that the commitment still checks that leaf being executed was an admissible one.

The dead-code elimination goes further than that, because at the top level this hash root is hidden inside a public key which can be a key controlled by all the participants jointly (or some subset if appropriate). At signing time if these top level parties are available and cooperate they can just sign, and no script is ever revealed, it's impossible for third parties to tell it was ever there-- saving resources and preserving privacy.

(And the possibility to complete the transaction using the script means they don't gain from failing to cooperate)

"Bitcoin may now be wired back and forth between the parties on layer 2 w/o needed to be settled individually on the Bitcoin block chain." Cooperatively update the final state would be more precise. And if one party is uncooperative then a timeout contract becomes valid. Your understanding is generally correct. Also bitcoin doesn't use the word crypto which is closely associated with scams. Bitcoin is about the 21 million coin limit so only one currency not cryptocurrencies.

    Parent talks about the „Lightning Network“

I was not talking about the Lightning Network in particular. The LN is a system that does settlement on the Bitcoin blockchain.

So is the "BMW and its suppliers" network I imagined. But this network is simpler and more customized to the needs of this particular use case.

Of course using the LN would be a viable alternative to a custom solution.

I see, so in principle, taproot would facilitate to set up custom scaling solutions for Bitcoin payment schemes.

Perhaps a simplification to this would be a poker night, where at the beginning of the evening everyone puts in some real money and in return get poker chips. At the end of the night people can exchange whatever chips they have left for real money.