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.

  • There is a mistake in the quote: the witness Merkle root is stored in an output of the coinbase transaction. Commented Aug 21, 2017 at 16:02
  • @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
    Commented Aug 22, 2017 at 12:37
  • I don't have any. Commented Aug 22, 2017 at 19:26

1 Answer 1


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).

  • 1
    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
    Commented Aug 21, 2017 at 7:19
  • 2
    Good point, I indeed didn't address that. I've expanded the answer and restructured it a bit. Commented Aug 21, 2017 at 15:59
  • 1
    @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. Commented Jul 28, 2022 at 12:01
  • 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. Commented Jul 30, 2022 at 1:20
  • 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. Commented Aug 1, 2022 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.