Hacker News Reader

Comment by TekMol | Hacker News Reader

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.

View on HN

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.

    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.

> 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).

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.

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.

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?

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.

Theres a timelock enforced by the blockchain.

Lightning transactions are all final and irreversible via cryptography mechanisms.

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?

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

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

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...

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

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?

Reply on news.ycombinator.com