Rusty Russell's Coding Blog | Stealing From Smart People



Lightning Networks Part I: Revocable Transactions

[ Note for new readers: the mechanisms described here are from the original LN draft.   These days instead of throwaway keys we use hash preimages for revocation, and output scripts are used for HTLCs, as per ]

I finally took a second swing at understanding the Lightning Network paper.  The promise of this work is exceptional: instant reliable transactions across the bitcoin network. But the implementation is complex and the draft paper reads like a grab bag of ideas; but it truly rewards close reading!  It doesn’t involve novel crypto, nor fancy bitcoin scripting tricks.

There are several techniques which are used in the paper, so I plan to concentrate on one per post and wrap up at the end.

Revision: Payment Channels

I open a payment channel to you for up to $10

A Payment Channel is a method for sending microtransactions to a single recipient, such as me paying you 1c a minute for internet access.  I create an opening transaction which has a $10 output, which can only be redeemed by a transaction input signed by you and me (or me alone, after a timeout, just in case you vanish).  That opening transaction goes into the blockchain, and we’re sure it’s bedded down.

I pay you 1c in the payment channel. Claim it any time!

Then I send you a signed transaction which spends that opening transaction output, and has two outputs: one for $9.99 to me, and one for 1c to you.  If you want, you could sign that transaction too, and publish it immediately to get your 1c.

Update: now I pay you 2c via the payment channel.

Then a minute later, I send you a signed transaction which spends that same opening transaction output, and has a $9.98 output for me, and a 2c output for you. Each minute, I send you another transaction, increasing the amount you get every time.

This works because:

  1.  Each transaction I send spends the same output; so only one of them can ever be included in the blockchain.
  2. I can’t publish them, since they need your signature and I don’t have it.
  3. At the end, you will presumably publish the last one, which is best for you.  You could publish an earlier one, and cheat yourself of money, but that’s not my problem.

Undoing A Promise: Revoking Transactions?

In the simple channel case above, we don’t have to revoke or cancel old transactions, as the only person who can spend them is the person who would be cheated.  This makes the payment channel one way: if the amount I was paying you ever went down, you could simply broadcast one of the older, more profitable transactions.

So if we wanted to revoke an old transaction, how would we do it?

There’s no native way in bitcoin to have a transaction which expires.  You can have a transaction which is valid after 5 days (using locktime), but you can’t have one which is valid until 5 days has passed.

So the only way to invalidate a transaction is to spend one of its inputs, and get that input-stealing transaction into the blockchain before the transaction you’re trying to invalidate.  That’s no good if we’re trying to update a transaction continuously (a-la payment channels) without most of them reaching the blockchain.

The Transaction Revocation Trick

But there’s a trick, as described in the paper.  We build our transaction as before (I sign, and you hold), which spends our opening transaction output, and has two outputs.  The first is a 9.99c output for me.  The second is a bit weird–it’s 1c, but needs two signatures to spend: mine and a temporary one of yours.  Indeed, I create and sign such a transaction which spends this output, and send it to you, but that transaction has a locktime of 1 day:

The first payment in a lightning-style channel.

Now, if you sign and publish that transaction, I can spend my $9.99 straight away, and you can publish that timelocked transaction tomorrow and get your 1c.

But what if we want to update the transaction?  We create a new transaction, with 9.98c output to me and 2c output to a transaction signed by both me and another temporary address of yours.  I create and sign a transaction which spends that 2c output, has a locktime of 1 day and has an output going to you, and send it to you.

We can revoke the old transaction: you simply give me the temporary private key you used for that transaction.  Weird, I know (and that’s why you had to generate a temporary address for it).  Now, if you were ever to sign and publish that old transaction, I can spend my $9.99 straight away, and create a transaction using your key and my key to spend your 1c.  Your transaction (1a below) which could spend that 1c output is timelocked, so I’ll definitely get my 1c transaction into the blockchain first (and the paper uses a timelock of 40 days, not 1).

Updating the payment in a lightning-style channel: you sent me your private key for sig2, so I could spend both outputs of Transaction 1 if you were to publish it.

So the effect is that the old transaction is revoked: if you were to ever sign and release it, I could steal all the money.  Neat trick, right?

A Minor Variation To Avoid Timeout Fallback

In the original payment channel, the opening transaction had a fallback clause: after some time, it is all spendable by me.  If you stop responding, I have to wait for this to kick in to get my money back.  Instead, the paper uses a pair of these “revocable” transaction structures.  The second is a mirror image of the first, in effect.

A full symmetric, bi-directional payment channel.

So the first output is $9.99 which needs your signature and a temporary signature of mine.  The second is  1c for meyou.  You sign the transaction, and I hold it.  You create and sign a transaction which has that $9.99 as input, a 1 day locktime, and send it to me.

Since both your and my “revocable” transactions spend the same output, only one can reach the blockchain.  They’re basically equivalent: if you send yours you must wait 1 day for your money.  If I send mine, I have to wait 1 day for my money.  But it means either of us can finalize the payment at any time, so the opening transaction doesn’t need a timeout clause.


Now we have a generalized transaction channel, which can spend the opening transaction in any way we both agree on, without trust or requiring on-blockchain updates (unless things break down).

The next post will discuss Hashed Timelock Contracts (HTLCs) which can be used to create chains of payments…

Notes For Pedants:

In the payment channel open I assume OP_CHECKLOCKTIMEVERIFY, which isn’t yet in bitcoin.  It’s simpler.

I ignore transaction fees as an unnecessary distraction.

We need malleability fixes, so you can’t mutate a transaction and break the ones which follow.  But I also need the ability to sign Transaction 1a without a complete Transaction 1 (since you can’t expose the signed version to me).  The paper proposes new SIGHASH types to allow this.

[EDIT 2015-03-30 22:11:59+10:30: We also need to sign the other symmetric transactions before signing the opening transaction.  If we released a completed opening transaction before having the other transactions, we might be stuck with no way to get our funds back (as we don’t have a “return all to me” timeout on the opening transaction)]

RSS Feed

11 Comments for Lightning Networks Part I: Revocable Transactions

joshuad31 | March 31, 2015 at 7:30 am

I really want to understand bitcoin lightning but its too dense for me. When trying to digest payment channels I came up with this but this seems a huge over simplification because it doesn’t involve this weird temporary transaction where I give away my private key. So what am I missing? Why do payment channels need a more elaborate trick than what I illustrate here:

JF | April 3, 2015 at 6:58 pm

@joshuad31 because payment channels are one way: in your example Alice can cheat Bob by publishing the 90-10 check (date: today) instead of the later 80-20. You need a way to invalidate older checks.

Roy Badami | April 7, 2015 at 5:51 am

Thanks for your exposition of this – I’m still ploughing through this and the paper is, as you say, pretty heavy going.

One quick comment: “A Minor Variation To Avoid Timeout Fallback”, second para, “The second is 1c for me”. That’s a typo, right? The 1c surely still has to be for the other party, right, not for me?



Author comment by rusty | April 7, 2015 at 8:06 pm

Thanks, fixed!

joshuad31 | April 11, 2015 at 6:30 am

@JF no there is something called n-lock time which means that you must wait. If Alice pushes the 90 10 check with Bobs signature to the blockchain after she has signed and given the 80 20 check to Bob with her signature then n-lock time will mean that Bob’s 80 20 published check with both signatures and no n-lock time will always be cashed before Alice’s check. Alice’s check will therefore attempt to double spend bitcoin that will already be spent thus the transaction will be invalid. You have to read the whitepaper carefully its not easy to understand.

Victor | April 22, 2015 at 9:26 am

What I did not get is how in Payment Channels part of article receiver is protected from sender creating and publishing new transaction, which spends whole $10?

Author comment by rusty | April 22, 2015 at 3:50 pm

The original $10 output is in the blockchain, and requires both signatures, so neither can spend it on their own.

joshuad31 | May 8, 2015 at 11:58 am

ok so the 3rd time I read this post in the past month or so and finally I get why I didn’t get it:

“So the effect is that the old transaction is revoked: if you were to ever sign and release it, I could steal all the money. Neat trick, right?”

One thing that makes your explanation of this difficult is that the 9.99 and 0.01 transaction has a 1 day time lock and the 9.98 and 0.02 transaction also has a 1 day timelock.

How about the 0.01 transaction having a 24 hour lock and the 0.02 transaction having a 23 hour lock. So if you try and sign the 0.01 transaction since mine has a shorter lock time I can get my transaction validated before yours.

Also its hard to take two parallel lines and connect them. the payment that starts this channel is a 2 of 2 multisig transaction with a timelock. What is hard is seeing how that money which has been committed already on the blockchain relates to these other payments using other signatures. I use my signature 1 and you used your signature 1 to sign the 2 of 2 committing 10 dollars of my money to the blockchain. But these parallel payments between us which update the value of the channel between us are related to some other money. It can’t be the initial multisig since that one cannot be unlocked by a this new signature 2 of yours which is created by a temporary address.

So its really weird. There is the payment channel which I get then there is this parallel channel which spends parallel money that is related to temporary sigs. Why cant I spend this parallel money? I don’t need your signature to spend it do I? Seems weird.

Author comment by rusty | May 27, 2015 at 9:20 am

Ah, I see your confusion. For the old transaction (the $9.99 and 1c one), if you were to publish that, I can spend the $9.99 output (because it just needs my signature). But you’ve also given me your old private key, so I can also sign a transaction which spends the 1c immediately (it only needs your old private key and my private key). You don’t have my private key, so you can’t make such a transaction, and are stuck with the existing transaction 1a, which has that 1 day timeout.

Hope that clarifies!

tricass | September 8, 2015 at 11:48 am

I too am having the same confusion as @joshuad31. From your last reply you mention you have both private keys to spend the 1c. But how does that help you when that input ($10) has already been spent with one output to you for $9.99 and the other for 1c to the other party but with a locktime of 1 day?

How do you craft a replacement transaction to spend that 1c?

Author comment by rusty | September 8, 2015 at 11:53 am

Let’s see if I can remember the original scheme… (It’s been modified in the current prototype, and simplified).

The “to self” output requires both signatures. You have a transaction which spends that, signed by them, but it’s fine locked.

Since they have your key (as well as their own of course) they can create a transaction which spends the output immediately.



Find it!

Theme Design by

Tag Cloud