<blockquote>
  <p>Why didn't Bitcoin implement segwit in the first place?</p>
</blockquote>

<p>The reason Bitcoin didn't initially have SegWit is up to interpretation, I would say that it simply was not thought of prior to transaction malleability. Although that is not its <em>only</em> goal. Segregated Witness was an idea proposed in <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP 141</a> as a <a href="https://en.bitcoin.it/wiki/Softfork" rel="nofollow noreferrer">soft-fork</a>, meaning it did not require an entire network upgrade. Due to the nature of a soft-fork, it is backwards compatible with previous versions of the Bitcoin software. Over time, it has been <a href="https://transactionfee.info/charts/payments/segwit" rel="nofollow noreferrer">gradually adopted</a>. </p>

<blockquote>
  <p>Why and how does non-segwit Bitcoin enable a miner to change a transaction's txid?</p>
</blockquote>

<p>Mastering Bitcoin is referring to something called <a href="https://en.bitcoin.it/wiki/Transaction_malleability" rel="nofollow noreferrer">transaction malleability</a>. Traditionally, the <code>txid</code> was a hash of ALL the data in the transaction including the signatures. Transaction malleability meant a signature could be slightly modified such that the <code>txid</code> would be changed entirely while the signature still remained valid.</p>

<p>As David has mentioned in his own answer:</p>

<blockquote>
  <p>changing even a single byte in the transaction completely changes the transaction ID.</p>
</blockquote>

<p>This created an opportunity for a "Denial-of-Service" attack where while the transaction was still valid, and every part of the transaction would have the same inputs/outputs, nodes could reject modified transactions and prevent them from confirming. With SegWit, the signatures (as implied by the name "Segregated Witness") are <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#motivation" rel="nofollow noreferrer">no longer</a> part of this hash. Eliminating the issue entirely.</p>

<p>I recommend reading <a href="https://qz.com/175565/why-nobody-can-withdraw-bitcoins-from-one-of-the-currencys-largest-exchanges/" rel="nofollow noreferrer">this article</a> for more information on how exactly it is done in practice.</p>

CC BY-SA 4.0
2018-10-28T00:15:15.400Z
2018-10-28T00:31:05.587Z
2018-10-28T00:31:05.587Z
Mason Ticehurst
<blockquote>
  <p>Why didn't Bitcoin implement segwit in the first place?</p>
</blockquote>

<p>Nobody thought of it at the time. There wasn't interest in things like off-chain scaling at the time.</p>

<blockquote>
  <p>Why and how does non-segwit Bitcoin enable a miner to change a transaction's txid?</p>
</blockquote>

<p>The signature for each input only covers critical parameters of the transaction such as who it makes payments to and how much. It is possible to modify the transaction and preserve the signature validity by not changing anything critical. Since the transaction ID is the hash of the entire transaction, changing even a single byte in the transaction completely changes the transaction ID.</p>

CC BY-SA 4.0
2018-10-28T00:29:01.560Z
Transaction malleability totally messed up the original wallet and would cause effective funds loss (the wallet would never release coins for respending when killed by parent tx malleability).  It was just an un-thought of vulnerability. Segwit is desirable without any thought to off-chain anything, and was first proposed in 2012 without any reference to it importance for smart contracts.
G. Maxwell
CC BY-SA 4.0
2018-10-28T00:30:38.260Z
Had anyone thought of the malleability probably in the early days, it would likely have lead to a smaller change just to fix malleability, not segwit. But, of course, counterfactuals are hard to establish.
David Schwartz
CC BY-SA 4.0
2018-10-28T00:33:01.837Z
That isn't at all clear to me, both the full data and the witnessless data must be committed to, no matter how it's constructed.  When we created segwit we first did it as a from scratch redo for elements with no need to be compatible and only later realized we could retrofit it into Bitcoin. The two versions were almost identical. As a result I think it's likely that if the flaw was originally known the solution would be equivalent at a high level description level, other than also supporting the old style-- of course.
G. Maxwell
CC BY-SA 4.0
2018-10-28T00:12:08.123Z
2018-10-28T00:12:08.123Z
David Schwartz
<p>Why didn't Bitcoin implement <a href="https://github.com/bitcoinbook/bitcoinbook/blob/362f0b340f6b10b4dcac82a06062ca92528fe7df/ch07.asciidoc#segregated-witness" rel="noreferrer">segwit</a> in the first place?</p>

<p>Why and how does non-segwit Bitcoin enable a miner to change a transaction's <a href="https://bitcoin.org/en/glossary/txid" rel="noreferrer"><code>txid</code></a>?</p>

<p>From <a href="https://github.com/bitcoinbook/bitcoinbook/blob/362f0b340f6b10b4dcac82a06062ca92528fe7df/ch07.asciidoc#transaction-identifiers" rel="noreferrer"><em>Mastering Bitcoin</em> ch. 7 § "Transaction identifiers"</a>:</p>

<blockquote>
  <p>Before segwit, transactions could have their signatures subtly modified by third parties, changing their transaction ID (hash) without changing any fundamental properties (inputs, outputs, amounts).</p>
</blockquote>

<segregated-witness><consensus><transaction-malleability><transaction-id>
Why didn't Bitcoin implement segwit in the first place?
Geremia
# Why didn't Bitcoin implement segwit in the first place?

(Asked by: username_0 on 2018-10-27)

Why didn't Bitcoin implement [segwit](https://github.com/bitcoinbook/bitcoinbook/blob/362f0b340f6b10b4dcac82a06062ca92528fe7df/ch07.asciidoc#segregated-witness) in the first place?

Why and how does non-segwit Bitcoin enable a miner to change a transaction's [`txid`](https://bitcoin.org/en/glossary/txid)?

From [*Mastering Bitcoin* ch. 7 § "Transaction identifiers"](https://github.com/bitcoinbook/bitcoinbook/blob/362f0b340f6b10b4dcac82a06062ca92528fe7df/ch07.asciidoc#transaction-identifiers):

> Before segwit, transactions could have their signatures subtly modified by third parties, changing their transaction ID (hash) without changing any fundamental properties (inputs, outputs, amounts).

**Tags:** segregated-witness, consensus, transaction-malleability, transaction-id


---

## 2 answers

### Answer by username_1 on 2018-10-28. Score: 3 | Accepted answer

> Why didn't Bitcoin implement segwit in the first place?

The reason Bitcoin didn't initially have SegWit is up to interpretation, I would say that it simply was not thought of prior to transaction malleability. Although that is not its *only* goal. Segregated Witness was an idea proposed in [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) as a [soft-fork](https://en.bitcoin.it/wiki/Softfork), meaning it did not require an entire network upgrade. Due to the nature of a soft-fork, it is backwards compatible with previous versions of the Bitcoin software. Over time, it has been [gradually adopted](https://transactionfee.info/charts/payments/segwit).

> Why and how does non-segwit Bitcoin enable a miner to change a transaction's txid?

Mastering Bitcoin is referring to something called [transaction malleability](https://en.bitcoin.it/wiki/Transaction_malleability). Traditionally, the `txid` was a hash of ALL the data in the transaction including the signatures. Transaction malleability meant a signature could be slightly modified such that the `txid` would be changed entirely while the signature still remained valid.

As username_2 has mentioned in his own answer:

> changing even a single byte in the transaction completely changes the transaction ID.

This created an opportunity for a "Denial-of-Service" attack where while the transaction was still valid, and every part of the transaction would have the same inputs/outputs, nodes could reject modified transactions and prevent them from confirming. With SegWit, the signatures (as implied by the name "Segregated Witness") are [no longer](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#motivation) part of this hash. Eliminating the issue entirely.

I recommend reading [this article](https://qz.com/175565/why-nobody-can-withdraw-bitcoins-from-one-of-the-currencys-largest-exchanges/) for more information on how exactly it is done in practice.


---

### Answer by username_2 on 2018-10-28. Score: 2

> Why didn't Bitcoin implement segwit in the first place?

Nobody thought of it at the time. There wasn't interest in things like off-chain scaling at the time.

> Why and how does non-segwit Bitcoin enable a miner to change a transaction's txid?

The signature for each input only covers critical parameters of the transaction such as who it makes payments to and how much. It is possible to modify the transaction and preserve the signature validity by not changing anything critical. Since the transaction ID is the hash of the entire transaction, changing even a single byte in the transaction completely changes the transaction ID.

> **Comments:**
> **username_3**: Transaction malleability totally messed up the original wallet and would cause effective funds loss (the wallet would never release coins for respending when killed by parent tx malleability).  It was just an un-thought of vulnerability. Segwit is desirable without any thought to off-chain anything, and was first proposed in 2012 without any reference to it importance for smart contracts.  
> **username_2**: Had anyone thought of the malleability probably in the early days, it would likely have lead to a smaller change just to fix malleability, not segwit. But, of course, counterfactuals are hard to establish.  
> **username_3**: That isn't at all clear to me, both the full data and the witnessless data must be committed to, no matter how it's constructed.  When we created segwit we first did it as a from scratch redo for elements with no need to be compatible and only later realized we could retrofit it into Bitcoin. The two versions were almost identical. As a result I think it's likely that if the flaw was originally known the solution would be equivalent at a high level description level, other than also supporting the old style-- of course.  

---

