<p>Many different approaches for payment channels exist. They differ in the way that refund from the payment channel is guaranteed. </p>

<p>One solution is having Bob to send Alice presigned but timelocked refund transaction, which simply spends from C (from output that Alice will use to fund C) and refunds Alice. As you say the amount must beforehand be agreed upon so that it is correctly reflected by the presigned refund transaction; but it is <em>not</em> necessary to make any conditional checks as you mention them in step 3 since if C's coins have been already spent or not allocated at all the refund transaction will immediately be invalidated. After Bob sends Alice the refund transaction, then Alice can make a funding transaction.</p>

<p>Alternatively for unidirected payment channels, Alice could make use of a more complex contract using OP_CHECKSEQUENCEVERIFY (<a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki</a>). The contract would be something like in the example "Escrow with Timeout" but without the 3rd-party Escrow and only using Alice and Bob. In this way Alice would be assured that no matter how much she initially funds the payment channel, she will be solely able to spend from it again in the future at a time she specifies within the contract. There would therefore not be a need for a presigned refund transaction.</p>

<p>Updating the state of the payment channel is similar in both cases.</p>

CC BY-SA 3.0
2017-11-16T17:56:26.983Z
Not just the amount has to be agreed upon, but Bob has to know the Alice's initial funding transaction's hash and output index so he can reference it in his refunding 2-2 transaction?
croraf
CC BY-SA 3.0
2017-11-16T20:49:28.397Z
Yes, for the first option the refund transaction must reference the multi-sig output (payment channel) and therefore must reference the funding transaction hash. That is the reason transaction malleability was an issue before segwit implementation. The second option however does not require a presigned refund transaction and Alice can be sure to be able to solely spend from the output after some time has passed. Before this time has passed however both Alices and Bob signature are required to spend from the output.
Bjarne Magnussen
CC BY-SA 3.0
2017-11-16T21:07:21.077Z
This means in the first option Alice will make a funding transaction stub, show that to Bob? Using this stub Bob will make and sign a refund transaction. Then Alice will sign the funding transaction stub and broadcast it.
croraf
CC BY-SA 3.0
2017-11-17T11:39:06.453Z
Yes, but in fact Alice could create the whole refund transaction herself and just ask Bob to sign it.
Bjarne Magnussen
CC BY-SA 3.0
2017-11-16T17:30:27.227Z
2017-11-16T20:51:12.740Z
2017-11-16T20:51:12.740Z
Bjarne Magnussen
<p>Yes .
I like this video as well, explaining the u and b directional channel.
<a href="https://www.youtube.com/watch?v=MpfvhiqFw7A" rel="nofollow noreferrer">The Lightning Network Explained (Litecoin/Bitcoin)</a> </p>

CC BY-SA 3.0
2017-11-16T11:59:04.830Z
Thanks Haddar. I'm interested in details of step 1 and 2. Does it go like this: Alice and Bob first create 2-2 address C, then they agree on the funds Alice puts in, then Bob makes and signs a conditional 2-2 transaction that says "IF Alice puts her funds in she gets them back IF another transaction is not made from C within nLock"?
croraf
CC BY-SA 3.0
2017-11-16T12:06:07.217Z
Alice and Bob generate 2-2 multisig address, Bob sign and broadcast a tx with nLock from that multisig to Alice address, then Alice can start fund the multisig address ...
Haddar Macdasi
CC BY-SA 3.0
2017-11-16T12:11:57.400Z
I updated my question
croraf
CC BY-SA 3.0
2017-11-16T12:43:12.013Z
I think step 3 is too much, Bob only needs to sign a spend multisig as input with the amount they agree on into Alice address after nLock - and show the tx to Alice / broadcast it.
Haddar Macdasi
CC BY-SA 3.0
2017-11-16T11:36:49.090Z
2017-11-16T11:36:49.090Z
Haddar Macdasi
<p>Let's observe direct unidirectional lightning channel between Alice and Bob.</p>

<p>How does this start technically:</p>

<ol>
<li>They first create a 2-2 address C.</li>
<li>They agree on the funds Alice will put into C, say 1BTC.</li>
<li><p>Bob makes a "conditional refund 2-2 transaction" that has 3 conditions:</p>

<p>a) if Alice put 1BTC into address C</p>

<p>b) if nLock time passed between the time she put money in</p>

<p>c) in no transaction was made from C and put on blockchain</p>

<p>then Alice gets 1BTC back from this address.
He signs that transaction and sends to Alice. Alice can sign and broadcast this transaction after nLock time to retrieve her 1BTC if a) b) and c) are fulfilled.</p></li>
<li>Alice now puts 1BTC into 2-2 address C.</li>
</ol>

<p>EDIT: Can you confirm each step.</p>

<p>For example: Is step 2 needed, or can Bob in step 3 just say if nLock time passed and no transaction was put on blockchain from C, whoever put money in C gets its money back in full amount.</p>

<lightning-network>
Lightning network smart contract technical explaination (unidirectional payment channel)
croraf
# Lightning network smart contract technical explaination (unidirectional payment channel)

(Asked by: username_0 on 2017-11-16)

Let's observe direct unidirectional lightning channel between Alice and Bob.

How does this start technically:

1. They first create a 2-2 address C.
2. They agree on the funds Alice will put into C, say 1BTC.
3. Bob makes a "conditional refund 2-2 transaction" that has 3 conditions:

   a) if Alice put 1BTC into address C

   b) if nLock time passed between the time she put money in

   c) in no transaction was made from C and put on blockchain

   then Alice gets 1BTC back from this address.
   He signs that transaction and sends to Alice. Alice can sign and broadcast this transaction after nLock time to retrieve her 1BTC if a) b) and c) are fulfilled.
4. Alice now puts 1BTC into 2-2 address C.

EDIT: Can you confirm each step.

For example: Is step 2 needed, or can Bob in step 3 just say if nLock time passed and no transaction was put on blockchain from C, whoever put money in C gets its money back in full amount.

**Tags:** lightning-network


---

## 2 answers

### Answer by username_1 on 2017-11-16. Score: 1 | Accepted answer

Many different approaches for payment channels exist. They differ in the way that refund from the payment channel is guaranteed.

One solution is having Bob to send Alice presigned but timelocked refund transaction, which simply spends from C (from output that Alice will use to fund C) and refunds Alice. As you say the amount must beforehand be agreed upon so that it is correctly reflected by the presigned refund transaction; but it is *not* necessary to make any conditional checks as you mention them in step 3 since if C's coins have been already spent or not allocated at all the refund transaction will immediately be invalidated. After Bob sends Alice the refund transaction, then Alice can make a funding transaction.

Alternatively for unidirected payment channels, Alice could make use of a more complex contract using OP\_CHECKSEQUENCEVERIFY (<https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki>). The contract would be something like in the example "Escrow with Timeout" but without the 3rd-party Escrow and only using Alice and Bob. In this way Alice would be assured that no matter how much she initially funds the payment channel, she will be solely able to spend from it again in the future at a time she specifies within the contract. There would therefore not be a need for a presigned refund transaction.

Updating the state of the payment channel is similar in both cases.

> **Comments:**
> **username_0**: Not just the amount has to be agreed upon, but Bob has to know the Alice's initial funding transaction's hash and output index so he can reference it in his refunding 2-2 transaction?  
> **username_1**: Yes, for the first option the refund transaction must reference the multi-sig output (payment channel) and therefore must reference the funding transaction hash. That is the reason transaction malleability was an issue before segwit implementation. The second option however does not require a presigned refund transaction and Alice can be sure to be able to solely spend from the output after some time has passed. Before this time has passed however both Alices and Bob signature are required to spend from the output.  
> **username_0**: This means in the first option Alice will make a funding transaction stub, show that to Bob? Using this stub Bob will make and sign a refund transaction. Then Alice will sign the funding transaction stub and broadcast it.  
> **username_1**: Yes, but in fact Alice could create the whole refund transaction herself and just ask Bob to sign it.  

---

### Answer by username_2 on 2017-11-16. Score: 1

Yes .
I like this video as well, explaining the u and b directional channel.
[The Lightning Network Explained (Litecoin/Bitcoin)](https://www.youtube.com/watch?v=MpfvhiqFw7A)

> **Comments:**
> **username_0**: Thanks username_2. I'm interested in details of step 1 and 2. Does it go like this: Alice and Bob first create 2-2 address C, then they agree on the funds Alice puts in, then Bob makes and signs a conditional 2-2 transaction that says "IF Alice puts her funds in she gets them back IF another transaction is not made from C within nLock"?  
> **username_2**: Alice and Bob generate 2-2 multisig address, Bob sign and broadcast a tx with nLock from that multisig to Alice address, then Alice can start fund the multisig address ...  
> **username_0**: I updated my question  
> **username_2**: I think step 3 is too much, Bob only needs to sign a spend multisig as input with the amount they agree on into Alice address after nLock - and show the tx to Alice / broadcast it.  

---

