0

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.

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
4
  • 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
    Nov 16, 2017 at 17:56
  • 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.
    – Bjarne Magnussen
    Nov 16, 2017 at 20:49
  • 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
    Nov 16, 2017 at 21:07
  • 1
    Yes, but in fact Alice could create the whole refund transaction herself and just ask Bob to sign it.
    – Bjarne Magnussen
    Nov 17, 2017 at 11:39
1

Yes . I like this video as well, explaining the u and b directional channel. The Lightning Network Explained (Litecoin/Bitcoin)

Improve this answer
4
  • 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
    Nov 16, 2017 at 11:59
  • 1
    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
    Nov 16, 2017 at 12:06
  • I updated my question
    – croraf
    Nov 16, 2017 at 12:11
  • 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
    Nov 16, 2017 at 12:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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