10

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.

  • 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 Apr 11 '16 at 22:17
  • 2
    @Bilthon: This relies on multisignature transactions and the use of the recently activated OP_CHECKLOCKTIMEVERIFY. 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 Apr 12 '16 at 8:46
  • 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? – B T Jul 18 '17 at 23:28
  • 1
    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 Jul 19 '17 at 3:33
  • 1
    @BT: I think the question you're looking for is this one: bitcoin.stackexchange.com/q/48053/5406 – Murch Jul 19 '17 at 3:46
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 Nov 25 '17 at 16:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.