Why LN needs SegWit?

[stdset]

I guess, because of malleability. But how exactly malleability prevents LN from functioning?
Is it because both channel participants need to know txid of the opening tx before signing it?

How LN could be implemented without SegWit?

[1714695604]

1714695604

[1714695604]

1714695604

[shorena]

I guess, because of malleability. But how exactly malleability prevents LN from functioning?

It doesnt, it just makes it more complicated to implement because you need code that looks for modified transaction IDs.

Is it because both channel participants need to know txid of the opening tx before signing it?

How LN could be implemented without SegWit?

The way I understand LN is that it works by repeatedly changing an unbroadcasted transaction to keep track of the current balance. Both can sign. If you want to close the channel you just broadcast the transaction. If the TX ID can be modified and the other party does not notice this you can close the channel while the other party thinks its still open.

[stdset]

If the TX ID can be modified and the other party does not notice this you can close the channel while the other party thinks its still open.

I think it's not that simple. In the scenario you describe, it's enough to keep an eye on the anchoring output to prevent cheating.

But for channel opening it's necessary to construct 2 commitment txes, which spend the anchoring output, which doesn't yet exist. If commitment txes are constructed and the opening tx is broadcast, and then it's txid suddenly changes, the commitment txes become invalid. Looking for modified txids doesn't help here. If so, it seems to me, possible solution could be: constructing a pair of commitment txes for every possible txid of the opening tx, before broadcasting it? this won't work, because we need to construct commitment txes before signing opening tx.

[Wind_FURY]

Good question OP! I would like to hear the answer straight from either a Core developer who worked extensively on Segwit or from a developer who is working on an LN implementation. This question was asked before but no one who really knows about the subject has come forward to answer. If someone has please post the link in this thread.

[johoe]

Malleability affects pre-signed child transactions in chains of unconfirmed transactions.  If you malleate the parent transaction, the child transactions is not valid, anymore. These unconfirmed transaction chains are used in LN to securely open channels or close channels.

SegWit is also useful to pre-sign the child transaction before signing the parent transactions, e.g. for the initial funding transaction you want to have signed emergency close channel transactions before signing the funding transactions.  With SegWit the transaction id does not depend on the signature and can be computed before the funding transaction is signed.

[stdset]

Chains of unconfirmed transactions only needed for channel opening.

The second lightning level, is OP_CSV or OP_MATURITY or whatever is the coolest name. It's relative to when the input got into a block, so it's like relative checklocktimeverify. This is a cool opcode. It lets you say you can spend this, but only once it's a week old, or you know a thousand blocks old. This allows a lot of cool things for lightning channels. The channel open and close transactions are about the same size. The channel duration is indefinite and you can keep it open for as long as you want. Both channels can cooperatively close it "immediately". There is a timeout period for the uncooperative close time, which you can make perhaps 1 week like in the other, if the counterparty disappears and he's gone, you can push the current channel state to the blockchain and then I have to wait a week to collect the money back to a non-lightning P2SH output. You could tweak this from 1 week to 1 day or 1 month or something. You have to watch the blockchain at least once during that period. You have to check the phone or blockchain at least once a week or something. That channel duration matters for the timeout of the checksequenceverify matters for channel monitoring which must still be done by the user.

Frankly, I don't understand, how channels of indefinite duration could be created without SegWit or SIGHASH_NOINPUT or another possible patch, which makes txid independent on signatures. Explanation appreciated.

[Quickseller]

I guess, because of malleability. But how exactly malleability prevents LN from functioning?

It doesnt, it just makes it more complicated to implement because you need code that looks for modified transaction IDs.

Is it because both channel participants need to know txid of the opening tx before signing it?

How LN could be implemented without SegWit?

The way I understand LN is that it works by repeatedly changing an unbroadcasted transaction to keep track of the current balance. Both can sign. If you want to close the channel you just broadcast the transaction. If the TX ID can be modified and the other party does not notice this you can close the channel while the other party thinks its still open.

Multiple transactions must be signed in order to open or close a LN channel, one of which will be dependent on a transactions that has not yet been seen by the network. The transactions are signed in a certain order so that neither party has leverage over the other to be able to force the other party into signing a transaction sending a different amount of bitcoin to the other party then what is agreed upon.

For example, to open a LN channel, both you and I would send 10 BTC to a multisig address, however the entire 20 BTC must be sent at the same time, otherwise one of us would need to sign a transaction authorizing the spending of the other's BTC, and could use this fact to entice you into signing a transaction sending BTC to the other party that does not belong to them. In order to ensure that each of our 10 BTC is sent to the LN channel at the same time, we tell each-other the inputs of the funding transaction, and create a single funding transaction that is signed by each of us.

If we signed the above transaction first, then neither one of us would be forced to sign a closing transaction sending each of us the 10 BTC that rightfully belongs to each of us. If for example, I were to need BTC, I could sign a transaction closing the channel, sending 10 BTC to each of us, and send this transaction to you for your signature, but you would not be forced to sign this transaction -- there is nothing that would stop you from asking that I sign a transaction that sends you 13 BTC, and sends me 7 BTC, and if I need money enough then I would have to sign this transaction, however you would always have the ability to receive your 10 BTC yourself because I already sent you a signed transaction sending each of us the 10 BTC that rightfully belongs to each of us. In order to prevent this kind of scenario from happening, we would first exchange the inputs that will be used for the funding transaction, allowing us to create an unsigned funding transaction, then create a closing transaction that gives each of us the 10 BTC that rightfully belong to each of us, sign the closing transaction, then sign/broadcast the opening transaction. If the opening transaction were to have it's txid changed, then the closing transaction would be invalid, and we would both be in a situation in which the other would be vulnerable to the kind of blackmail described above.

This is a very high-level explanation on how LN will work. However using LN is not suppose to involve trusting the person you have an open channel with.

[TierNolan]

Frankly, I don't understand, how channels of indefinite duration could be created without SegWit or SIGHASH_NOINPUT or another possible patch, which makes txid independent on signatures. Explanation appreciated.

You could have both sides put down a deposit agreeing to fix any mutation of the transaction.

Step 1

HA1 is Alice's hash lock and HB1 is Bob's hash lock.

Code:

TX1:
0) Pays 3x: (Alice + HA1 after 1 week) or (Bob after 2 weeks) 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 1 week) or (Alice after 2 weeks) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

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

Abort after step 1

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

Likewise, Bob can wait a week 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 2 weeks (and output 3), which gives him 6x and Alice nothing.

Therefore 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 actually different for Bob and Alice due to the way Lightning works.  The trick is that 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 1 week).

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.

Step 2b

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

Abort after step 2b

Alice 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.

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.

[stdset]

This is amazing! Many thanks.

A couple of questions however:
1) How large deposit outputs (0 and 3) must really be? I think 3x is an overkill, even 1x is enough?
2) If the channel is funded asymmetrically, for instance if Alice unilaterally funds it (initial state: Alice: x, Bob: 0), how does it affect everything? Outputs 0 and 2 aren't needed at all?

[TierNolan]

1) How large deposit outputs (0 and 3) must really be? I think 3x is an overkill, even 1x is enough?

They need to be large enough so that the abort for step 1 works.

If a party disappears, then the other party gets both deposits as refund.  This means that (slightly more than) 1x would be sufficient.

2) If the channel is funded asymmetrically, for instance if Alice unilaterally funds it (initial state: Alice: x, Bob: 0), how does it affect everything? Outputs 0 and 2 aren't needed at all?

I don't think it would work well with asymmetric setup.

If Alice is paying to a 2 of 2 output, then Bob has to pay the deposit to guarantee that he will cover any mutations.

For asymmetric funding, the initial transaction would be.

Code:

TX1:
0) Pays 1.1*y: (Alice + HA1 after 1 week) or (Bob after 2 weeks) or (2 of 2 Alice + Bob) 
1) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
2) Pays y: (HA1 + Bob) or (2 of 2 Alice + Bob)
3) Pays 1.1*x: (Bob + HB1 after 1 week) or (Alice after 2 weeks) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

That gives each party 1.1*(x + y) if the other party disappears after step 1.

For a unilateral channel, Bob still needs to provide a deposit during the setup, but gets it back once the channel is setup.

Code:

TX1:
0) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
1) Pays 1.1*x: (Bob + HB1 after 1 week) or (Alice after 2 weeks) or (2 of 2 Alice + Bob)
2) Pays Alice's change: (Alice)
3) Pays Bob's change: (Bob)

Bob pays 1.1x and Alice pays x.

If Bob disappears, Alice can claim output 1 after 2 weeks and get 1.1x back.

If Alice disappears, Bob can claim output 1 after 1 week and get his 1.1x back.  Alice can reclaim output 0 at any point after that and get her x back.

If it works out, Bob's money is tied up for 1 week.

The times could be made shorter (1-2 hours), since they are only for initial setup.

[stdset]

Thanks for the answers.
With this:

Outputs 0 and 2 aren't needed at all?

I meant of course this:

Alice unilaterally funds it (initial state: Alice: x, Bob: 0)

not a general case.
But thanks for considering general case too.

For a unilateral channel, Bob still needs to provide a deposit during the setup, but gets it back once the channel is setup.

To make it clear, we are still talking about bidirectional channel, it's just the initial state what is unilateral.

The times could be made shorter (1-2 hours), since they are only for initial setup.

Now, when blocks are full, I think it's better not to make times shorter. Otherwise the following can happen:
Let's say Bob becomes uncooperative.
1) Alice waits t hours, claims output 0.
2) Alice's tx is hanging unconfirmed, but since Bob runs a full node, he receives it, gets HA1 from it.
3) Bob immediately claims outputs 2 and 3, his accomplice pool confirms this tx.
4) After 2t hours Alice's tx is still unconfirmed, Bob claims output 0 as well, his pool confirms all Bob's txes.
Only output 1 is left for Alice, everything else is taken by Bob and his pool.

Edit: to make time considerations clearer, let's rewrite tx1 the following way:

Code:

TX1:
0) Pays 1.1*y: (Alice + HA1 after t) or (Bob after (t + T)) or (2 of 2 Alice + Bob) 
1) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
2) Pays y: (HA1 + Bob) or (2 of 2 Alice + Bob)
3) Pays 1.1*x: (Bob + HB1 after t) or (Alice after (t + T)) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

I agree, that t can be safely shortened to several hours, but T must be long enough (a week or even more), so that channel opening could be safely aborted regardless of network congestion.

[TierNolan]

To make it clear, we are still talking about bidirectional channel, it's just the initial state what is unilateral.

Right, though it is only bi-directional once Alice has actually sent a micropayment to Bob.

Code:

TX1:
0) Pays 1.1*y: (Alice + HA1 after t) or (Bob after (t + T)) or (2 of 2 Alice + Bob) 
1) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
2) Pays y: (HA1 + Bob) or (2 of 2 Alice + Bob)
3) Pays 1.1*x: (Bob + HB1 after t) or (Alice after (t + T)) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

I agree, that t can be safely shortened to several hours, but T must be long enough (a week or even more), so that channel opening could be safely aborted regardless of network congestion.

Setting the time is a security trade off.  Both t and T need to be long enough that users can safely get their transactions included in time.

An idea I had about network congestion was that transactions could pre-buy block space.

A block size rule of this type would be 10MB per block total size, but all blocks are capped at 1MB "modified" block size too.

Normally, a transaction's modified size would just be the size of the transaction.  For each output, it can add additional loading.  This increases the modified size of that transaction but then decreases the modified size of the spending transaction.

A 500 byte transaction could have an output that is loaded at 500 bytes.  That transaction would count as a 1000 byte transaction for modified block size purposes.

If the output is spent by a 490 byte transaction, then that transaction would count as -10 bytes.

Essentially, the transaction's modified size would be

actual size + sum(output loading) - sum(input loading)

When loading an output, that transaction costs more but then the spending transaction costs less.

This means that the channel open transactions could be loaded so that the channel close transactions don't actually use up block space.

If there was a lot of congestion miners could still include up to 10MB of channel close transactions per block.  The average block size would be 1MB but could be increased by 10X in an emergency.

[stdset]

This is an interesting concept. At first glance I don't see any problems with it. Was it already discussed somewhere?

[TierNolan]

This is an interesting concept. At first glance I don't see any problems with it. Was it already discussed somewhere?

I don't know if anyone suggested it before.

It is based on some of my ideas for inter-chain atomic transfers with legacy coins (where only one of the two coins supports check locktime verify).

[stdset]

I don't know if anyone suggested it before.

It is based on some of my ideas for inter-chain atomic transfers with legacy coins (where only one of the two coins supports check locktime verify).

I think it deservers at least a separate thread. It's interesting to know core devs and well known bitcoin experts opinion on it.
In my opinion great advantage of this concept compared to other concepts proposed to solve the same problem is simplicity. It requires hardfork, but so are others.