1
The current Lightning implementations use P2WSH script format for multisig in the funding transaction. But it is also possible to use the CHECKMULTISIG opcode "natively", i.e., without P2WSH (see Mastering Bitcoin, Chapter 7). Can it be used for channel establishment? What would be the pros and cons? Was multisig used in Lightning at some point, or did Lightning go straight to P2WSH?
3
The main issue about using a non-segwit inputs in the funding transaction or a p2sh output as the channel anchor is the transaction malleability.
The recovery guarantee before a channel is funded relies on the commitment transaction building on top of the funding transaction. If the funding transactions txid were to be malleated, the commitment transaction becomes invalid and the funder becomes beholden to their channel partner for recovery.
In the case of using a p2sh output as the channel anchor, malleation of a unilateral force-close could be used to prohibit the counterparty from punishing the publication of an outdated channel state.
Therefore the funding transaction must be non-malleable and the channel anchor must be held in a script that is not malleable upon spending.
Possible duplicate of Why SHOULD the funding tx consume BIP 141 inputs?
– Rene Pickhardt – 2019-05-08T14:04:03.827Potential duplicate question to https://bitcoin.stackexchange.com/questions/84967/why-should-the-funding-tx-consume-bip-141-inputs could you please comment if the other question / answers help?
– Rene Pickhardt – 2019-05-08T14:05:01.597That question is interesting by itself but not exactly what I'm asking. I'm wondering whether one can or did use in the "plaintext" scripts (without P2WSH) with OP_CHECKMULTISIG in Lightning (very early versions perhaps?). – Sergei Tikhomirov – 2019-05-08T14:17:14.097
I think that didn't happen because of the malleability issues connected to non segwit transactions. If that does not answer your question I will dig a little deeper or wait for other lightning devs to help out. I am no segwit expert but I think that should be the reason (: – Rene Pickhardt – 2019-05-08T14:23:16.420
So the tx is non-malleable only if it creates P2WSH outputs? From the question linked above I understand why it must consume only Segwit inputs (SHOULD, strictly speaking, assuming there are other ways to ensure non-malleability), but why does it also have to create only Segwit outputs? – Sergei Tikhomirov – 2019-05-08T14:31:13.140
If the output was not segwit another node could catch the published funding TX and malleate it and broadcast the mandated one with a higher fee. Now the txid of the funding TX would change and the commitment tx would be worthless as it points to nirvana. The channel partner could now blackmail the initiator. To prevent this we use P2WSH as discussed in the other thread (or I have misunderstood the answers to my thread g which I don't want to rule out) – Rene Pickhardt – 2019-05-08T14:38:23.073
@RenePickhardt I think what Sergei is trying to point out is that why the commitment transactions NEEDS to have SegWit output? Those pay the individual addresses of the channel partners and the txid is not referenced. – Ugam Kamat – 2019-05-08T14:43:48.427
That would make sense to me but the question talks specifically about the funding TX. Now I am confused ;( – Rene Pickhardt – 2019-05-08T14:52:45.387
@RenePickhardt to prevent the "points to nirvana" scenario the funding tx must not commit to signatures (hence segwit) - that's what I understand. Does it imply that the funding tx must consume only segwit inputs, create only segwit outputs, or both? – Sergei Tikhomirov – 2019-05-08T15:03:12.637
1In my understanding it must produce segwit outputs. What it consumes should not matter – Rene Pickhardt – 2019-05-08T16:52:10.847