<blockquote>
  <p>As far as I know, the malleability issue was fixed with the Segwit soft fork in August 2017.</p>
</blockquote>

<p>Yes.</p>

<blockquote>
  <p>Was the malleability issue fixed with SIGHASH_NOINPUTor with some other method?</p>
</blockquote>

<p>No, using SegWit.</p>

<p>SegWit stands for segregated witness. It's a generic and backward compatible change that results in signatures no longer contributing to txids. As the txids of previous transaction outputs being spent are included in what transactions sign, this indirectly results in malleation no longer resulting in the invalidation on descendant transactions.</p>

CC BY-SA 4.0
2017-11-20T18:15:55.657Z
2018-05-06T20:54:00.430Z
2018-05-06T20:54:00.430Z
Pieter Wuille
<p>Section 3.1.2 of the <a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">Lightning paper</a> (Version 0.5.9.2, last modified 14 January 2016) discusses ways to fix the transaction malleability issue, which prevented Bitcoin transactions from spending UTXO from yet unconfirmed transactions. Specifically, it mentioned <code>SIGHASH_NOINPUT</code> transaction type.</p>

<p>As far as I know, the malleability issue was fixed with the Segwit soft fork in August 2017. Was the malleability issue fixed with <code>SIGHASH_NOINPUT</code> or with some other method? How does it affect the Lightning network design as described in the paper?</p>

<p>A <a href="https://bitcoin.stackexchange.com/questions/22918/how-is-the-transaction-malleability-issue-being-fixed">related (very old) question</a>, <a href="https://bitcoin.stackexchange.com/questions/36726/do-new-sighash-types-need-a-hard-fork-or-a-soft-fork">another one</a>.</p>

<lightning-network><transaction-malleability>
Lightning network: how was malleability actually fixed?
Sergei Tikhomirov
# Lightning network: how was malleability actually fixed?

(Asked by: username_0 on 2017-11-20)

Section 3.1.2 of the [Lightning paper](https://lightning.network/lightning-network-paper.pdf) (Version 0.5.9.2, last modified 14 January 2016) discusses ways to fix the transaction malleability issue, which prevented Bitcoin transactions from spending UTXO from yet unconfirmed transactions. Specifically, it mentioned `SIGHASH_NOINPUT` transaction type.

As far as I know, the malleability issue was fixed with the Segwit soft fork in August 2017. Was the malleability issue fixed with `SIGHASH_NOINPUT` or with some other method? How does it affect the Lightning network design as described in the paper?

A [related (very old) question](https://bitcoin.stackexchange.com/questions/22918/how-is-the-transaction-malleability-issue-being-fixed), [another one](https://bitcoin.stackexchange.com/questions/36726/do-new-sighash-types-need-a-hard-fork-or-a-soft-fork).

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


---

## 1 answers

### Answer by username_1 on 2017-11-20. Score: 6 | Accepted answer

> As far as I know, the malleability issue was fixed with the Segwit soft fork in August 2017.

Yes.

> Was the malleability issue fixed with SIGHASH\_NOINPUTor with some other method?

No, using SegWit.

SegWit stands for segregated witness. It's a generic and backward compatible change that results in signatures no longer contributing to txids. As the txids of previous transaction outputs being spent are included in what transactions sign, this indirectly results in malleation no longer resulting in the invalidation on descendant transactions.


---

