10
1
I'm reading the lightning network whitepaper, and at some point it states this:
Therefore, it is possible in bitcoin to devise a bitcoin script whereby all old transactions are invalidated, and only the new transaction is valid.
I would like to know the specifics of how this can be done. Seems to me that what they are describing here is some kind of transaction overriding? It is somewhat different from the mechanism I understood a micro payment channel works.
6
Lightning payment channels are established by two parties Alice and Bob paying into a 2-of-2 multisignature address. Concurrently, they create two "exit-transactions", one for each participant which pay out the current allotment of the payment channel, txAliceExit_1 and txBobExit_1. These exit transactions lock the fund of the executing party for some blocks.
When a payment is performed between Alice and Bob, they update the balance, create two new "exit-transactions", txAliceExit_2 and txBobExit_2.
To invalidate the previous "exit-transactions" each party gives the counterparty another transaction that builds on the previous exit transaction by spending the party's output to the counterparty if the old "exit-transaction" were broadcast to the network, txAliceExit_1-TakeAll and txBobExit_1-TakeAll. I.e. if Bob executes txBobExit_1 the funds are time-locked for a little bit, meanwhile txAliceExit_1-TakeAll would become valid and Alice could take them before he can spend them.
1
A commitment transaction is a transaction that sends person A's bitcoins to person A, and person B's bitcoins to an intermediate address (let's call it B*). B* can be spent by person B, but only after the input to that transaction is 1000 blocks deep (ie after about a week). But person A can also spend from B* if person A obtains B's commitment secret.
So once new commitment transactions are created (which use fresh secrets and hashes), both parties exchange their old secrets allowing, for example, A to spend from B*. Since B* will only receive money if B posts an outdated commitment transaction, B* wouldn't have any money for A to spend. But if B does post an outdated commitment transaction, A has 1 week to notice and spend B*'s money for himself.
So the exchange of old secrets is what invalidates the old transaction. But some machine still has to watch the blockchain to ensure that action is taken if an outdated transaction is posted.
You can read more details here: https://governology.wordpress.com/2017/07/21/so-you-wanna-understand-bitcoin-part-2/
Is there a decrementing time lock in this implementation of lightning channel, or is there a second implementation with decrementing time lock? Or is decrementing time lock used only in lightning network (multiple interconnected channels) – croraf – 2017-11-25T16:42:14.937
Excellent explanation!! thank you very much! I assume this would require the implementation (or acceptance) of new currently not supported opcodes, am I right? or can this scripting be done with the bitcoin protocol as it is now? (april 2016) – Bilthon – 2016-04-11T22:17:06.580
2
@Bilthon: This relies on multisignature transactions and the use of the recently activated
– Murch – 2016-04-12T08:46:05.377OP_CHECKLOCKTIMEVERIFY. AFAIK it also requires the transaction malleability fix that will be introduced withSegWit. Currently, an attacker could use malleability to change a previous exit transaction, invalidating the follow-upTakeAlltransaction.@Bilthon: According to Rusty Russel and David Harding we'll need
– Murch – 2016-04-13T00:38:22.723OP_CHECKSEQUENCEVERIFYadditionally for the anti-cheat transactions. This op-code is not implemented yet.What mechanism is used to ensure the invalidation transaction can only be spent if the old exit transaction is posted? – B T – 2017-07-17T07:09:07.323
@BT: Since the 'TakeAll' transaction builds on top of the invalidated 'ExitTransaction', it is only valid if the ExitTransaction was posted first. – Murch – 2017-07-17T14:57:14.363
@Murch Ok, so in that case, if Alice posts an outdated exit transaction, what prevents her from posting a transaction that uses that transaction as an input to another transaction before the invalidation transaction has time to post? Even if both parties post transactions at the same time, it seems like there's still a 50% chance Alice will be able to steal some money via the outdated exit transaction. – B T – 2017-07-17T21:38:14.850
@BT There are two exit transactions, because they will lock the funds for the one that publishes the exit transaction for a period of time in the range of a few hours to a week (up to the channel owners) which gives the other time to publish the anti-cheat transaction in case they have it, as there is no wait for that. – Murch – 2017-07-17T21:45:02.647
1But where is the money for an anti-cheat transaction coming from? It can't be from the opening address, because then people could steal money at any time using the anti-cheat transaction. And it can't be from the destination of the exit-transaction because then it wouldn't be valid for 1 week. So what address is this money coming from? – B T – 2017-07-18T23:28:59.347
1The destination of each exit-transaction has two possible resolutions: Either it was a valid unilateral channel closing, matures through the wait period and becomes spendable to the closer, or it was an attempt to steal funds, and the channel partner has the secret to spend the money even before the wait is over. The wait time only applies to the closer. The secret is revealed to the channel partner when the partners agree on a new state of the channel, so the channel partner will be able to punish transgressions to this agreement. – Murch – 2017-07-19T03:33:25.647
1
@BT: I think the question you're looking for is this one: https://bitcoin.stackexchange.com/q/48053/5406
– Murch – 2017-07-19T03:46:22.463Does this protocol use decrementing timelocks in 2 parties lightning channel or is decrementing timelocks another implementation of lightning channel (or decrementing timelocks is not used in 2 parties lightning channel)? – croraf – 2017-11-25T16:23:22.503
@croraf: You're thinking of Christian Decker's Duplex Micropayment Channels. – Murch – 2017-11-25T17:19:14.840
I'm talking about https://m.youtube.com/watch?t=174s&v=MpfvhiqFw7A. So lightning network doesn't use decrementing lock times?
– croraf – 2017-11-26T00:18:18.640I'm talking about m.youtube.com/watch?t=174s&v=MpfvhiqFw7A and https://youtu.be/8zVzw912wPo?t=10m42s. So lightning network doesn't use decrementing lock times?
– croraf – 2017-11-26T00:34:53.363Lightning network uses commitment transactions that are invalidated every time the balances in the channel are updated. I don't think that this requires decrementing lock times. – Murch – 2017-11-27T15:24:40.693