5
In BOLT 02 we read that the funding TX should only consume segwit inputs.
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.
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;funding_locked);Second, as to why this is a SHOULD instead of a MUST. This has to do with the IETF definition:
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.
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.
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 – 2019-04-15T14:40:50.040
1The 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 – 2019-04-17T18:50:29.293