<p><strong>Why a witness commitment is necessary at all: Enabling DoS prevention for validating nodes</strong></p>

<p>Block validation is expensive. It requires hashing all data in a block, building Merkle trees, looking up all inputs from the UTXO database, running script and ECDSA validation, do various consistency checks, and updating the UTXO database. If random peers could make us do that amount of work, we'd be exposing ourselves to denial-of-service attacks.</p>

<p>Thankfully, producing blocks is expensive - it requires spending hash power. An attacker could take a valid block, and modify it before relay to turn it invalid. However, since all data relevant for validation directly or indirectly affects the block hash, doing such an attack will invalidate the proof of work. Thus, we can simply make sure that a block's proof of work is valid before doing any of the more costly checks, and that way we make sure that every attacker needs to spend new hash power for each block we try to validate.</p>

<p>Segregated Witness adds more data to blocks that is relevant for validation. In order to make sure that the protection outlined above still works, we must make sure that the new witness data affects the block hash. Otherwise, an attacker could simply take a valid block, make a gazillion modified copies, each with a different invalid witness, and broadcast them. Nodes would need to validate every version.</p>

<p><strong>Why the witness commitment uses a Merkle tree: compact witness proofs</strong></p>

<p>Some outputs (e.g. 1-of-2 multisig) can be spent by different combinations of signers. Certain wallet software may be interested in knowing which party/parties signed off on a spend for display or forensics purposes.</p>

<p>Lightweight nodes can currently request a compact proof for the existence of a transaction (see BIP37). As the witness does not contribute to the txid, the normal Merkle structure does not permit creating such a proof for the witness data. While there is currently no available protocol for requesting such witness proofs, using a Merkle tree for the witness commitment enables this.</p>

<p><strong>Why the witness Merkle root is stored in the coinbase: easiest deployment for miners</strong></p>

<p>Lastly, we need a place to embed the witness Merkle root hash that affects the block hash. Using the block header would have been perfect, but there is no way to add data there without breaking every piece of Bitcoin infrastructure.</p>

<p>The only place flexible enough for storing that data is in a transaction. A special transaction could have been added which contains the commitment, but transactions bring extra overhead. They need inputs and outputs, which need to come from somewhere and go somewhere.</p>

<p>Because of that, the only choice remaining was to embed the commitment in an existing transaction. The coinbase transaction is the logical choice - it is already created by miners anyway, and adding a dummy output to it has low resource costs (due automatic removal of OP_RETURN outputs from the UTXO set).</p>

CC BY-SA 3.0
2017-08-21T07:19:04.003Z
I agree with the first part, but am confused about the second part of the answer. It explains why having a Merkle tree for the witness _somewhere_ is necessary, but not why its root should be in included in the coinbase transaction.
Nikolai
CC BY-SA 3.0
2017-08-21T15:59:51.563Z
Good point, I indeed didn't address that. I've expanded the answer and restructured it a bit.
Pieter Wuille
CC BY-SA 4.0
2022-07-28T11:24:09.490Z
"Otherwise, an attacker could simply take a valid block, make a gazillion modified copies, each with a different invalid witness, and broadcast them. Nodes would need to validate every version."

Is it fair to say that this mostly applies to new nodes in IBD? Since BIP152 (compact blocks) was merged before SegWit activated, live nodes would not be affected too much as the attacker would quickly get disconnected from sending invalid transactions and we just need 1 peer to send us the transaction with valid witness data?
stickies-v
CC BY-SA 4.0
2022-07-28T12:01:41.200Z
@stickies-v I don't see how that's related. If the witness data was not committed to by the PoW, it is trivial for attackers to construct many invalid variants of the same valid block, without invalidating PoW. They could use each copy once or many times, and be disconnected for it or not. With PoW committing to the witness, it is simply impossible to construct such a block in the first place without huge hashrate.
Pieter Wuille
CC BY-SA 4.0
2022-07-28T13:20:56.133Z
@pieter-wuille My point is that with compact blocks, in the best-case scenario, a node would already have received (and validated) all the transactions before the new compact block arrives, so the attacker would have no witness data (or anything else) to tamper with? More generally, when an attacker tampers with witness data, it is obvious which transaction in the block is invalid, so only new version(s) of that transaction would need to be revalidated and not the entire block?
stickies-v
CC BY-SA 4.0
2022-07-30T01:20:42.460Z
I don't think compact blocks matters, as it's just a bandwidth optimization. Arguably, it helps the attacker as it means they only have to send the modified/damaged transactions to the victim, and not the whole block. You're right that script/signature caching reduce the problem of needing to revalidate every possible variation of blocks you receive, though caches are also finite, and eventually lose entries.
Pieter Wuille
CC BY-SA 4.0
2022-08-01T12:39:42.070Z
Ah, perhaps your point is that with compact blocks a potential victim node will learn about the correct block sooner, and once they do, they are immune to DoS attacks that attempt to feed a mutated version of that block. That does help, but attackers can generally easily race the network if their goal is getting the (invalid) block as soon as possible to a particular victim.
Pieter Wuille
CC BY-SA 3.0
2017-08-20T22:21:24.457Z
2017-08-22T20:57:09.523Z
2017-08-22T20:57:09.523Z
Pieter Wuille
<p>I just read this article to understand SegWit better: <a href="https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618/" rel="noreferrer">https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618/</a> There's a part that doesn't quite make sense to me:</p>
<blockquote>
<p>But there is one problem: If signatures have no effect on the makeup of the blockchain, the blockchain no longer serves as proof that the correct signatures were included in transactions.</p>
<p>To make sure that signatures are embedded in the blockchain regardless, a Segregated Witness-enabled miner adds a trick, too. Rather than creating only a Merkle Tree out of all of the transactions, it also creates a Merkle Tree out of all Segregated Witnesses, to mirror the transaction tree. <strong>The Segregated Witness Merkle Root, then, is included in the input field of the coinbase transaction. As such the Segregated Witness Merkle Root changes the transaction data of the coinbase transaction, its transaction ID, therefore influences the block header and, ultimately, the makeup of the blockchain.</strong></p>
</blockquote>
<p>Is this accurate? If so, what exactly does it achieve?</p>
<p>Including the merkle root of the <em>transactions</em> in the block header prevents tampering with the transaction list, but I don't see any value in tampering with the signatures.</p>

CC BY-SA 3.0
2017-08-21T16:02:58.507Z
There is a mistake in the quote: the witness Merkle root is stored in an *output* of the coinbase transaction.
Pieter Wuille
CC BY-SA 3.0
2017-08-22T12:37:24.883Z
@PieterWuille could you link to a more accurate description of SegWit that isn't the proposal? (something comparable in level of detail to Bitcoin wiki)
Nikolai
CC BY-SA 3.0
2017-08-22T19:26:53.917Z
I don't have any.
Pieter Wuille
<segregated-witness>
Why include the Segregated Witness Merkle Root in the input field of the coinbase transaction?
Nikolai
# Why include the Segregated Witness Merkle Root in the input field of the coinbase transaction?

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

I just read this article to understand SegWit better: <https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618/> There's a part that doesn't quite make sense to me:

> But there is one problem: If signatures have no effect on the makeup of the blockchain, the blockchain no longer serves as proof that the correct signatures were included in transactions.
>
> To make sure that signatures are embedded in the blockchain regardless, a Segregated Witness-enabled miner adds a trick, too. Rather than creating only a Merkle Tree out of all of the transactions, it also creates a Merkle Tree out of all Segregated Witnesses, to mirror the transaction tree. **The Segregated Witness Merkle Root, then, is included in the input field of the coinbase transaction. As such the Segregated Witness Merkle Root changes the transaction data of the coinbase transaction, its transaction ID, therefore influences the block header and, ultimately, the makeup of the blockchain.**

Is this accurate? If so, what exactly does it achieve?

Including the merkle root of the *transactions* in the block header prevents tampering with the transaction list, but I don't see any value in tampering with the signatures.

**Tags:** segregated-witness

> **Comments:**
> **username_1**: There is a mistake in the quote: the witness Merkle root is stored in an *output* of the coinbase transaction.  
> **username_0**: @username_1 could you link to a more accurate description of SegWit that isn't the proposal? (something comparable in level of detail to Bitcoin wiki)  
> **username_1**: I don't have any.  

---

## 1 answers

### Answer by username_1 on 2017-08-20. Score: 22 | Accepted answer

**Why a witness commitment is necessary at all: Enabling DoS prevention for validating nodes**

Block validation is expensive. It requires hashing all data in a block, building Merkle trees, looking up all inputs from the UTXO database, running script and ECDSA validation, do various consistency checks, and updating the UTXO database. If random peers could make us do that amount of work, we'd be exposing ourselves to denial-of-service attacks.

Thankfully, producing blocks is expensive - it requires spending hash power. An attacker could take a valid block, and modify it before relay to turn it invalid. However, since all data relevant for validation directly or indirectly affects the block hash, doing such an attack will invalidate the proof of work. Thus, we can simply make sure that a block's proof of work is valid before doing any of the more costly checks, and that way we make sure that every attacker needs to spend new hash power for each block we try to validate.

Segregated Witness adds more data to blocks that is relevant for validation. In order to make sure that the protection outlined above still works, we must make sure that the new witness data affects the block hash. Otherwise, an attacker could simply take a valid block, make a gazillion modified copies, each with a different invalid witness, and broadcast them. Nodes would need to validate every version.

**Why the witness commitment uses a Merkle tree: compact witness proofs**

Some outputs (e.g. 1-of-2 multisig) can be spent by different combinations of signers. Certain wallet software may be interested in knowing which party/parties signed off on a spend for display or forensics purposes.

Lightweight nodes can currently request a compact proof for the existence of a transaction (see BIP37). As the witness does not contribute to the txid, the normal Merkle structure does not permit creating such a proof for the witness data. While there is currently no available protocol for requesting such witness proofs, using a Merkle tree for the witness commitment enables this.

**Why the witness Merkle root is stored in the coinbase: easiest deployment for miners**

Lastly, we need a place to embed the witness Merkle root hash that affects the block hash. Using the block header would have been perfect, but there is no way to add data there without breaking every piece of Bitcoin infrastructure.

The only place flexible enough for storing that data is in a transaction. A special transaction could have been added which contains the commitment, but transactions bring extra overhead. They need inputs and outputs, which need to come from somewhere and go somewhere.

Because of that, the only choice remaining was to embed the commitment in an existing transaction. The coinbase transaction is the logical choice - it is already created by miners anyway, and adding a dummy output to it has low resource costs (due automatic removal of OP\_RETURN outputs from the UTXO set).

> **Comments:**
> **username_0**: I agree with the first part, but am confused about the second part of the answer. It explains why having a Merkle tree for the witness _somewhere_ is necessary, but not why its root should be in included in the coinbase transaction.  
> **username_1**: Good point, I indeed didn't address that. I've expanded the answer and restructured it a bit.  
> **username_2**: "Otherwise, an attacker could simply take a valid block, make a gazillion modified copies, each with a different invalid witness, and broadcast them. Nodes would need to validate every version."  Is it fair to say that this mostly applies to new nodes in IBD? Since BIP152 (compact blocks) was merged before SegWit activated, live nodes would not be affected too much as the attacker would quickly get disconnected from sending invalid transactions and we just need 1 peer to send us the transaction with valid witness data?  
> **username_1**: @username_2 I don't see how that's related. If the witness data was not committed to by the PoW, it is trivial for attackers to construct many invalid variants of the same valid block, without invalidating PoW. They could use each copy once or many times, and be disconnected for it or not. With PoW committing to the witness, it is simply impossible to construct such a block in the first place without huge hashrate.  
> **username_2**: @username_1-username_1 My point is that with compact blocks, in the best-case scenario, a node would already have received (and validated) all the transactions before the new compact block arrives, so the attacker would have no witness data (or anything else) to tamper with? More generally, when an attacker tampers with witness data, it is obvious which transaction in the block is invalid, so only new version(s) of that transaction would need to be revalidated and not the entire block?  
> **username_1**: I don't think compact blocks matters, as it's just a bandwidth optimization. Arguably, it helps the attacker as it means they only have to send the modified/damaged transactions to the victim, and not the whole block. You're right that script/signature caching reduce the problem of needing to revalidate every possible variation of blocks you receive, though caches are also finite, and eventually lose entries.  
> **username_1**: Ah, perhaps your point is that with compact blocks a potential victim node will learn about the correct block sooner, and once they do, they are immune to DoS attacks that attempt to feed a mutated version of that block. That does help, but attackers can generally easily race the network if their goal is getting the (invalid) block as soon as possible to a particular victim.  

---

