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

<p>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 <em>does</em> post an outdated commitment transaction, A has 1 week to notice and spend B*'s money for himself. </p>

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

<p>You can read more details here: <a href="https://governology.wordpress.com/2017/07/21/so-you-wanna-understand-bitcoin-part-2/" rel="nofollow noreferrer">https://governology.wordpress.com/2017/07/21/so-you-wanna-understand-bitcoin-part-2/</a></p>

CC BY-SA 3.0
2017-11-25T16:42:14.937Z
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
CC BY-SA 3.0
2017-07-21T21:30:09.457Z
2017-07-21T21:30:09.457Z
B T
<p>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, <code>txAliceExit_1</code> and <code>txBobExit_1</code>. These exit transactions lock the fund of the executing party for some blocks.</p>

<p>When a payment is performed between Alice and Bob, they update the balance, create two new "exit-transactions", <code>txAliceExit_2</code> and <code>txBobExit_2</code>. </p>

<p>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, <code>txAliceExit_1-TakeAll</code> and <code>txBobExit_1-TakeAll</code>. I.e. if Bob executes <code>txBobExit_1</code> the funds are time-locked for a little bit, meanwhile <code>txAliceExit_1-TakeAll</code> would become valid and Alice could take them before he can spend them.</p>

CC BY-SA 3.0
2016-04-11T22:17:06.580Z
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
CC BY-SA 3.0
2016-04-12T08:46:05.377Z
@Bilthon: This relies on multisignature transactions and the use of the recently activated [`OP_CHECKLOCKTIMEVERIFY`](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki). AFAIK it also requires the transaction malleability fix that will be introduced with `SegWit`. Currently, an attacker could use malleability to change a previous exit transaction, invalidating the follow-up `TakeAll` transaction.
Murch
CC BY-SA 3.0
2016-04-13T00:38:22.723Z
@Bilthon: [According to Rusty Russel and David Harding](https://www.reddit.com/r/Bitcoin/comments/4egobx/how_does_the_lightning_network_work_in_simple/d207rvp) we'll need `OP_CHECKSEQUENCEVERIFY` additionally for the anti-cheat transactions. This op-code is not implemented yet.
Murch
CC BY-SA 3.0
2017-07-17T07:09:07.323Z
What mechanism is used to ensure the invalidation transaction can only be spent if the old exit transaction is posted?
B T
CC BY-SA 3.0
2017-07-17T14:57:14.363Z
@BT: Since the 'TakeAll' transaction builds on top of the invalidated 'ExitTransaction', it is only valid if the ExitTransaction was posted first.
Murch
CC BY-SA 3.0
2017-07-17T21:38:14.850Z
@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
CC BY-SA 3.0
2017-07-17T21:45:02.647Z
@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
CC BY-SA 3.0
2017-07-18T23:28:59.347Z
But 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
CC BY-SA 3.0
2017-07-19T03:33:25.647Z
The 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
CC BY-SA 3.0
2017-07-19T03:46:22.463Z
@BT: I think the question you're looking for is this one: https://bitcoin.stackexchange.com/q/48053/5406
Murch
CC BY-SA 3.0
2017-11-25T16:23:22.503Z
Does 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
CC BY-SA 3.0
2017-11-25T17:19:14.840Z
@croraf: You're thinking of Christian Decker's Duplex Micropayment Channels.
Murch
CC BY-SA 3.0
2017-11-26T00:18:18.640Z
I'm talking about https://m.youtube.com/watch?t=174s&v=MpfvhiqFw7A. So lightning network doesn't use decrementing lock times?
croraf
CC BY-SA 3.0
2017-11-26T00:34:53.363Z
I'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
CC BY-SA 3.0
2017-11-27T15:24:40.693Z
Lightning 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
CC BY-SA 3.0
2016-04-11T16:36:49.763Z
2016-04-11T16:36:49.763Z
Murch
<p>I'm reading the lightning network whitepaper, and at some point it states this:</p>

<blockquote>
  <p>Therefore, it is possible in bitcoin to devise a bitcoin script
  whereby all old transactions are invalidated, and only the new
  transaction is valid.</p>
</blockquote>

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

<transactions><lightning-network><ln-penalty-transaction>
Transaction overriding in lightning network
Bilthon
# Transaction overriding in lightning network

(Asked by: username_0 on 2016-02-13)

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.

**Tags:** transactions, lightning-network, ln-penalty-transaction


---

## 2 answers

### Answer by username_3 on 2016-04-11. Score: 7 | Accepted answer

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.

> **Comments:**
> **username_0**: 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)  
> **username_3**: @username_0: This relies on multisignature transactions and the use of the recently activated [`OP_CHECKLOCKTIMEVERIFY`](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki). AFAIK it also requires the transaction malleability fix that will be introduced with `SegWit`. Currently, an attacker could use malleability to change a previous exit transaction, invalidating the follow-up `TakeAll` transaction.  
> **username_3**: @username_0: [According to Rusty Russel and David Harding](https://www.reddit.com/r/Bitcoin/comments/4egobx/how_does_the_lightning_network_work_in_simple/d207rvp) we'll need `OP_CHECKSEQUENCEVERIFY` additionally for the anti-cheat transactions. This op-code is not implemented yet.  
> **username_1**: What mechanism is used to ensure the invalidation transaction can only be spent if the old exit transaction is posted?  
> **username_3**: @BT: Since the 'TakeAll' transaction builds on top of the invalidated 'ExitTransaction', it is only valid if the ExitTransaction was posted first.  
> **username_1**: @username_3 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.  
> **username_3**: @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.  
> **username_1**: But 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?  
> **username_3**: The 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.  
> **username_3**: @BT: I think the question you're looking for is this one: https://bitcoin.stackexchange.com/q/48053/5406  
> **username_2**: Does 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)?  
> **username_3**: @username_2: You're thinking of Christian Decker's Duplex Micropayment Channels.  
> **username_2**: I'm talking about https://m.youtube.com/watch?t=174s&v=MpfvhiqFw7A. So lightning network doesn't use decrementing lock times?  
> **username_2**: I'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?  
> **username_3**: Lightning 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.  

---

### Answer by username_1 on 2017-07-21. Score: 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/>

> **Comments:**
> **username_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)  

---

