Quote from: gmaxwell on December 27, 2016, 11:06:41 AM

Lightning does not require segwit. Simply repeating it over and over again will not make it true.

Maybe that's because nobody understands how a permanent LN channel could be opened without malleability fix?
How about the following protocol? Is it how it is supposed to work with CSV but without malleability fix?

Quote from: TierNolan on December 11, 2016, 11:58:37 AM

This is a protocol for opening a permanent lightning channel even if malleability is not fixed. It only requires check locktime and check sequence verify.

Both sides put down a deposit to eliminate the hold-out risk. If either of the parties refuses to proceed either the other party is compensated or both get a full refund.

Step 1

Alice picks A1 and sends HA1, Hash(A1), to Bob.
Bob picks B1 and sends HB1, Hash(B1), to Alice.

They can both create this transaction.

Code:

TX1:
0) Pays 3x: (Alice + HA1 after T1) or (Bob after T1 + T2) or (2 of 2 Alice + Bob)
1) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
2) Pays x: (HA1 + Bob) or (2 of 2 Alice + Bob)
3) Pays 3x: (Bob + HB1 after T1) or (Alice after T1 + T2) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

Alice and Bob create the transaction and sign and broadcast it.

Abort during step 1

If one party signs the transaction and then the other refuses, then the signer should send at least one of the inputs to another address. This invalidates the transaction.

Abort after step 1

Alice can wait T1 and then reclaim output 0. This automatically gives Bob HA1, which allows him claim output 2.

Likewise, Bob can wait T1 and then reclaim output 3. This automatically gives Alice HB1, which allows her claim output 1.

This is a full refund all parties.

If Alice refuses to claim output 0, then Bob can claim it after [T1 + T2] (and output 3), which gives him 6x and Alice nothing.

Likewise, if Bob refuses to claim output 3, then Alice gets 6x and Bob nothing.

Both parties are incentivized to comply with the abort at this stage.

Step 2

Alice and Bob create the initial channel state transaction. This supports a channel close that gives x to Alice and x to Bob and spends outputs 1 and 2.

The initial state transaction is different for Bob and Alice due to the way Lightning works. Only Alice has both signatures for her version and only Bob has both signatures for his version.

Step 2a

Alice signs Bob's version of the transaction and sends the signature to Bob.

Abort after step 2a

If Bob broadcasts his initial state transaction, then that counts as him closing the channel. Alice gets her x refund and then can reclaim output 0 (after T1).

If he doesn't broadcast it, then she can just follow the same abort procedure from step 1.

Bob can abort using the procedure from step 1 or broadcasting the initial state transaction.

In all cases, Alice and Bob get their money back.

Step 2b

Bob signs Alice's version of the transaction and sends the signature to Alice.

Abort after step 2b

Alice (or Bob) can simply close the channel so that both get x each from outputs 1 and 2.

Once the channel is closed, she can then claim output 0 safely (after 1 week).

Likewise, Bob gets x when the channel is closed (he can close it himself too) and then claims output 3 safely.

This gives both parties a full refund.

Step 3

Alice and Bob create a transaction which sends outputs 0 and 3 back to them. This requires both outputs to be 2 of 2 signed (so 2 signatures each).

This transaction is broadcast. If either party refuses to sign, then it counts as an abort after step 2b.

Once step 3 is finished, they now have established an initial lightning channel state with unlimited duration.

It is important that neither reveal their hash lock as that allows the other to spend the funding output.