<p>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. </p>

<p>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. </p>

<p>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.</p>

<p>Therefore the funding transaction must be non-malleable and the channel anchor must be held in a script that is not malleable upon spending.</p>

CC BY-SA 4.0
2019-05-08T17:27:49.257Z
2019-05-08T17:27:49.257Z
Murch
<p>The current Lightning implementations use <a href="https://github.com/lightningnetwork/lightning-rfc/blob/6bd1981fc08268049f3ad78437c28fb634f1406e/03-transactions.md#funding-transaction-output" rel="nofollow noreferrer">P2WSH script format</a> for multisig in the funding transaction. But it is also possible to use the <code>CHECKMULTISIG</code> opcode "natively", i.e., without P2WSH (see <a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc#multisignature" rel="nofollow noreferrer">Mastering Bitcoin, Chapter 7</a>). 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?</p>

CC BY-SA 4.0
2019-05-08T14:04:03.827Z
Possible duplicate of [Why SHOULD the funding tx consume BIP 141 inputs?](https://bitcoin.stackexchange.com/questions/84967/why-should-the-funding-tx-consume-bip-141-inputs)
Rene Pickhardt
CC BY-SA 4.0
2019-05-08T14:05:01.597Z
Potential 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
CC BY-SA 4.0
2019-05-08T14:17:14.097Z
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 Tikhomirov
CC BY-SA 4.0
2019-05-08T14:23:16.420Z
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
CC BY-SA 4.0
2019-05-08T14:31:13.140Z
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
CC BY-SA 4.0
2019-05-08T14:38:23.073Z
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
CC BY-SA 4.0
2019-05-08T14:43:48.427Z
@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
CC BY-SA 4.0
2019-05-08T14:52:45.387Z
That would make sense to me but the question talks specifically about the funding TX. Now I am confused ;(
Rene Pickhardt
CC BY-SA 4.0
2019-05-08T15:03:12.637Z
@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
CC BY-SA 4.0
2019-05-08T16:52:10.847Z
In my understanding it must produce segwit outputs. What it consumes should not matter
Rene Pickhardt
<lightning-network><script><multi-signature>
Multisig without P2WSH in Lightning
Sergei Tikhomirov
# Multisig without P2WSH in Lightning

(Asked by: username_0 on 2019-05-08)

The current Lightning implementations use [P2WSH script format](https://github.com/lightningnetwork/lightning-rfc/blob/6bd1981fc08268049f3ad78437c28fb634f1406e/03-transactions.md#funding-transaction-output) 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](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc#multisignature)). 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?

**Tags:** lightning-network, script, multi-signature

> **Comments:**
> **username_1**: Possible duplicate of [Why SHOULD the funding tx consume BIP 141 inputs?](https://bitcoin.stackexchange.com/questions/84967/why-should-the-funding-tx-consume-bip-141-inputs)  
> **username_1**: Potential 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?  
> **username_0**: 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?).  
> **username_1**: 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 (:  
> **username_0**: 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?  
> **username_1**: 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)  
> **username_2**: @username_1 I think what username_0 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.  
> **username_1**: That would make sense to me but the question talks specifically about the funding TX. Now I am confused ;(  
> **username_0**: @username_1 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?  
> **username_1**: In my understanding it must produce segwit outputs. What it consumes should not matter  

---

## 1 answers

### Answer by username_3 on 2019-05-08. Score: 3 | Accepted 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.


---

