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?
-
Possible duplicate of Why SHOULD the funding tx consume BIP 141 inputs?– Rene PickhardtCommented May 8, 2019 at 14:04
-
Potential duplicate question to bitcoin.stackexchange.com/questions/84967/… could you please comment if the other question / answers help?– Rene PickhardtCommented May 8, 2019 at 14:05
-
That 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 TikhomirovCommented May 8, 2019 at 14:17
-
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 PickhardtCommented May 8, 2019 at 14:23
-
1In my understanding it must produce segwit outputs. What it consumes should not matter– Rene PickhardtCommented May 8, 2019 at 16:52
|
Show 5 more comments
1 Answer
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.
