<blockquote>
  <p>If [a funding transaction only consuming segwit inputs] was for preventing tx malleability it should be a MUST.</p>
</blockquote>

<p>Slightly above the quoted text, it says: "The sender MUST set: [...] <code>funding_txid</code> to the transaction ID of a non-malleable transaction."</p>

<p>Segwit inputs are not required in case the sender knows a non-segwit way to create a malleability-resistant funding transaction.  For example, the sender could be a miner who mines their own transactions and doesn't expect reorgs (a silly example, I admit).</p>

<p>It's worth considering what happens if the funding transaction is mutated.  The funding transaction pays a 2-of-2 multisig, but we want to ensure that the sender can get his money back if the receiver becomes uncooperative, so the receiver signs the first commitment transaction (initial channel balance) before the funding transaction is broadcast, so if the funding transaction's txid changes, the first commitment is invalid and the sender can only recover his initial deposit by begging the receiver to provide another signature for the 2-of-2 multisig.  In this failure case, the receiver loses nothing and may even benefit by charging a fee for his signature.  That means only the sender needs to care about choosing a malleability-resistant input.  Since that's the case, it seems unnecessary to force them to use segwit via a MUST but best to simply very strongly recommend that they not shoot themselves in the foot via a SHOULD.</p>

CC BY-SA 4.0
2019-04-15T14:40:50.040Z
But the last part of your answer holds für the outputs of finding tx which must not be malleable because the funding TX could be changed as you mentioned. But that should not matter for the inputs of the funding TX as they are previously mined and should not change anyway?
Rene Pickhardt
CC BY-SA 4.0
2019-04-17T18:50:29.293Z
The part of a transaction that is subject to third-party malleability is the scriptSig field, which is part of the input field of a transaction.  Remember that an input isn't the previous output being spent, the input is a reference to the prevout along with a signature (or other proof) that the spend is authorized.
David A. Harding
CC BY-SA 4.0
2019-04-15T10:22:21.470Z
2019-04-15T10:22:21.470Z
David A. Harding
<p>The following is my humble understanding, I am not an expert in BOLTs.</p>

<p>First, the reason to include this requirement is indeed transaction malleability. If malleable outputs are consumed for the funding transactions, then:</p>

<ul>
<li><code>funding_txid</code> may change after the transaction is broadcasted;</li>
<li>checking the status of the tx may fail (<code>funding_locked</code>);</li>
<li>the channel will never be established even though the funding tx is send.</li>
</ul>

<p>Second, as to why this is a SHOULD instead of a MUST. This has to do with <a href="https://www.ietf.org/rfc/rfc2119.txt" rel="nofollow noreferrer">the IETF definition</a>:</p>

<blockquote>
  <p>SHOULD   This word, or the adjective "RECOMMENDED", mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.</p>
</blockquote>

<p>SHOULD is not critical to the specifications and some clients may have a reason to ignore this recommendation. For example, I may write a client that does not include on-chain BIP141-only bitcoin wallet and instead connects to an existing one. This will make setup easier and cheaper for some users (no additional on-chain transaction). But I need to understand the implications and handle malleable transactions in case their <code>txid</code> changes.</p>

CC BY-SA 4.0
2019-03-11T11:52:51.460Z
2019-03-11T11:52:51.460Z
Dmitry Laptev
<p>In BOLT 02 we read that the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-funding_created-message" rel="nofollow noreferrer">funding TX should only consume segwit inputs</a>. </p>

<blockquote>
  <p>The sender: when creating the funding transaction: SHOULD use only BIP141 (Segregated Witness) inputs.</p>
</blockquote>

<p>What is the reason for that? If it was for preventing tx malleability it should be a MUST. Also I thought the inputs that are consumed don't matter for this context. </p>

<lightning-network><segregated-witness><transaction-malleability>
Why SHOULD the funding tx consume BIP 141 inputs?
Rene Pickhardt
# Why SHOULD the funding tx consume BIP 141 inputs?

(Asked by: username_0 on 2019-02-28)

In BOLT 02 we read that the [funding TX should only consume segwit inputs](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-funding_created-message).

> The sender: when creating the funding transaction: SHOULD use only BIP141 (Segregated Witness) inputs.

What is the reason for that? If it was for preventing tx malleability it should be a MUST. Also I thought the inputs that are consumed don't matter for this context.

**Tags:** lightning-network, segregated-witness, transaction-malleability


---

## 2 answers

### Answer by username_1 on 2019-04-15. Score: 2

> If [a funding transaction only consuming segwit inputs] was for preventing tx malleability it should be a MUST.

Slightly above the quoted text, it says: "The sender MUST set: [...] `funding_txid` to the transaction ID of a non-malleable transaction."

Segwit inputs are not required in case the sender knows a non-segwit way to create a malleability-resistant funding transaction. For example, the sender could be a miner who mines their own transactions and doesn't expect reorgs (a silly example, I admit).

It's worth considering what happens if the funding transaction is mutated. The funding transaction pays a 2-of-2 multisig, but we want to ensure that the sender can get his money back if the receiver becomes uncooperative, so the receiver signs the first commitment transaction (initial channel balance) before the funding transaction is broadcast, so if the funding transaction's txid changes, the first commitment is invalid and the sender can only recover his initial deposit by begging the receiver to provide another signature for the 2-of-2 multisig. In this failure case, the receiver loses nothing and may even benefit by charging a fee for his signature. That means only the sender needs to care about choosing a malleability-resistant input. Since that's the case, it seems unnecessary to force them to use segwit via a MUST but best to simply very strongly recommend that they not shoot themselves in the foot via a SHOULD.

> **Comments:**
> **username_0**: But the last part of your answer holds für the outputs of finding tx which must not be malleable because the funding TX could be changed as you mentioned. But that should not matter for the inputs of the funding TX as they are previously mined and should not change anyway?  
> **username_1**: The part of a transaction that is subject to third-party malleability is the scriptSig field, which is part of the input field of a transaction.  Remember that an input isn't the previous output being spent, the input is a reference to the prevout along with a signature (or other proof) that the spend is authorized.  

---

### Answer by username_2 on 2019-03-11. Score: 2

The following is my humble understanding, I am not an expert in BOLTs.

First, the reason to include this requirement is indeed transaction malleability. If malleable outputs are consumed for the funding transactions, then:

* `funding_txid` may change after the transaction is broadcasted;
* checking the status of the tx may fail (`funding_locked`);
* the channel will never be established even though the funding tx is send.

Second, as to why this is a SHOULD instead of a MUST. This has to do with [the IETF definition](https://www.ietf.org/rfc/rfc2119.txt):

> SHOULD This word, or the adjective "RECOMMENDED", mean that there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course.

SHOULD is not critical to the specifications and some clients may have a reason to ignore this recommendation. For example, I may write a client that does not include on-chain BIP141-only bitcoin wallet and instead connects to an existing one. This will make setup easier and cheaper for some users (no additional on-chain transaction). But I need to understand the implications and handle malleable transactions in case their `txid` changes.


---

