Quote from: NewOldUser on July 13, 2016, 04:58:28 PM

I watched the video on lightning.network and have a question about a transaction which uses 3 channels (meaning the transaction with 4 people)

What happens if 3 (the second, the thirth and the fourth) of them work together? The one who will receive the transaction (the last one in the transaction-order) shares the key to unlock the Time-Locked-Transactions with the second person (the one the original sender sends his funds to). Now the second person can get the money from the original sender while the third person neither sends the funds to the fourth person nor claims the funds from the second person.

In that case only the first person paid the second person while the other transactions do not happen as the first person cannot broadcast anything to the blockchain.

All of that only works under the assumption that three of them work together to cheat the fourth person.

My question now is: Is there a code planned that will prevent that or can you steal someone's money that way or did I misunderstand something?

There are no key required for the time-locked transactions. They come from a 2-2 multi-sig address and are already signed by the 1 of 2. The other person just needs to wait and then sign it.

The delay of the time lock is assigned decreasing from the last person so that in case of a refund situation, the last person can get it first.

You can see the process as a Matroska doll. If you have A, B, C, D in a channel, A->B, B->C and C-D subchannels:
A puts 1 BTC in deposit at B by funding a 2-2 multi sig with A+B,
B does the same with C by funding a 2-2 multi sig with B+C,
and finally C does the same with D by funding a 2-2 multi sig with C+D. So logically, 1 BTC went from A to A+B, B to B+C and C to C+D. D can't take the whole 1 BTC because it needs C signature. But D can see the money there and can consider 1 BTC credit line.

This part is important.

Ideally, A could give 1 BTC to B in deposit, and B does the same with C. However, in this scheme, A has to trust B. B could decide to keep the 1 BTC and not give it to C.

So instead, A puts it in a trust fund (i.e. a multi-sig A+B). B can't get the money from A but sees it there. He funds another multi-sig with C. However, it's worth noticing that A has spent 1 BTC and so did B because B took 1 BTC from his own pocket to fund B+C. Without a refund capability, if A goes away B has lost 1 BTC since the A+B multi-sig cannot be spent without A signature.

With an additional hop, we see that C is in the same risky situation. He spent 1 BTC from his pocket to fund C+D.

The refund path is designed to eliminate this risk.

A pays D for stuff up to 1 BTC and then they close the channel (or fund the channel further).

* If they want to close, D broadcasts the transaction for the balance spending from C+D that has R.
C sees R on the blockchain, so he can identify that D has closed the channel. He broadcasts his transaction closing B+C.
And B does the same.

* If not, A wants to get his money back.
Obviously B, C want to get their money back too. D is the one who failed to close the channel - so he gets nothing.
The lightning network must make sure that C gets the 1 BTC back first so that it can refund B who then can refund A.
So the lock time for C must be lower than for B.

I think they should also explain what happens in a partially closed channel. For instance, with A B C, C wants to close the channel with B but A doesn't want to close with B. Is it possible?
Can A deposit 10 BTC with B and then have channels from B-C for 1 BTC and B-D for 9 BTC?

That should be ok but I don't think it was covered.
Also, do they need their new SIGHASH types with Segwit? I don't think so.

PS: I skimmed over the video so apologies if some of the questions were answered.

hhanh00

Posts

Merits