<blockquote>
<p>If I'm understanding segwit correctly, miners have to verify signatures in order to include a transaction into a block that they are mining. However, miners are not required to verify signatures in order to decide that a block a different miner mined is valid. Is this correct?</p>
</blockquote>
<p>Miners can do what they want to construct blocks, including creating blocks with invalid signatures. They can even try construct blocks by just creating random data, and hoping it's valid.</p>
<p>However, blocks without valid signatures (or other validity problems) will not be accepted by the network. All full nodes verify all signatures in all blocks, so if a miner constructs a block with an invalid signature, they've just wasted a enormous amount of effort to produce something everyone will just ignore, and forgone the ability to be paid for that block. The same is true for building <em>on top</em> of an invalid block; thus miners are incentivized to validate the blocks they build on top of too - but they don't have if they like losing money.</p>
<p>None of this has anything to do with segwit. Segwit moved signatures to a different place, where they don't affect txids, and can be stripped cleanly so pre-segwit nodes can ignore them, but doesn't mean nodes don't validate anything less (except old nodes, which don't care about the segregated area).</p>
<blockquote>
<p>It sounds to me like most do still verify though?</p>
</blockquote>
<p>Definitely.</p>
<blockquote>
<p>Are signatures discarded eventually?</p>
</blockquote>
<p>Not in any current full node implementation that I know of.</p>
<p>Bitcoin Core supports pruning old block data, which deletes both witness and non-witness data equally. That also means other nodes can't synchronize off a pruned node anymore.</p>
<p>In theory it's possible to implement a pruning mode that deletes just the witnesses. That would also prevent other (post-segwit) nodes from synchronizing off them, but they could still serve some light clients. This is not implemented.</p>
<blockquote>
<p>Should a mining pool temporarily gain 51% control of the blockchain, can they insert transactions, and not include the segwit for a block or two because, by the time other miners are allowed to mine, those signatures will have expired?</p>
</blockquote>
<p>I don't understand what you mean here, but signatures don't &quot;expire&quot;.</p>

CC BY-SA 4.0
2021-01-28T23:07:47.303Z
So how can you trim away the signatures if you still need them and how can segwit improve transaction bandwidth if all of the same data still needs to be sent every block. Or am I missing the whole point of segwit, because I thought that was it?
mczarnek
CC BY-SA 4.0
2021-01-28T23:14:57.020Z
You can trim signatures away because segwit outputs look like "anyone can spend" to old nodes. New nodes need the signatures. It doesn't improve bandwidth, it's a block size increase from the perspective of new nodes, but one with better incentive alignment as it makes the data that doesn't go into the UTXO set (which all nodes need to maintain) relatively cheaper. It was combined with other changes that make validation relative cheaper in some worst case situations, and introduce non-malleable transaction identifiers, which do contribute to scalability.
Pieter Wuille
CC BY-SA 4.0
2021-01-28T23:23:22.693Z
Got it, read multiple articles about this.. that explanation actually made sense. Short and concise, thanks.
mczarnek
CC BY-SA 4.0
2021-01-28T23:00:21.197Z
2021-01-28T23:17:48.273Z
2021-01-28T23:17:48.273Z
Pieter Wuille
<p>If I'm understanding segwit correctly, miners have to verify signatures in order to include a transaction into a block that they are mining. However, miners are not required to verify signatures in order to decide that a block a different miner mined is valid. Is this correct? It sounds to me like most do still verify though?</p>
<p>Are signatures discarded eventually?</p>
<p>Should a mining pool temporarily gain 51% control of the blockchain, can they insert transactions, and not include the segwit for a block or two because, by the time other miners are allowed to mine, those signatures will have expired?</p>

<mining-theory><segregated-witness><block-validity>
What prevents miners from inserting fake transactions given SegWit?
mczarnek
# What prevents miners from inserting fake transactions given SegWit?

(Asked by: username_0 on 2021-01-28)

If I'm understanding segwit correctly, miners have to verify signatures in order to include a transaction into a block that they are mining. However, miners are not required to verify signatures in order to decide that a block a different miner mined is valid. Is this correct? It sounds to me like most do still verify though?

Are signatures discarded eventually?

Should a mining pool temporarily gain 51% control of the blockchain, can they insert transactions, and not include the segwit for a block or two because, by the time other miners are allowed to mine, those signatures will have expired?

**Tags:** mining-theory, segregated-witness, block-validity


---

## 1 answers

### Answer by username_1 on 2021-01-28. Score: 6

> If I'm understanding segwit correctly, miners have to verify signatures in order to include a transaction into a block that they are mining. However, miners are not required to verify signatures in order to decide that a block a different miner mined is valid. Is this correct?

Miners can do what they want to construct blocks, including creating blocks with invalid signatures. They can even try construct blocks by just creating random data, and hoping it's valid.

However, blocks without valid signatures (or other validity problems) will not be accepted by the network. All full nodes verify all signatures in all blocks, so if a miner constructs a block with an invalid signature, they've just wasted a enormous amount of effort to produce something everyone will just ignore, and forgone the ability to be paid for that block. The same is true for building *on top* of an invalid block; thus miners are incentivized to validate the blocks they build on top of too - but they don't have if they like losing money.

None of this has anything to do with segwit. Segwit moved signatures to a different place, where they don't affect txids, and can be stripped cleanly so pre-segwit nodes can ignore them, but doesn't mean nodes don't validate anything less (except old nodes, which don't care about the segregated area).

> It sounds to me like most do still verify though?

Definitely.

> Are signatures discarded eventually?

Not in any current full node implementation that I know of.

Bitcoin Core supports pruning old block data, which deletes both witness and non-witness data equally. That also means other nodes can't synchronize off a pruned node anymore.

In theory it's possible to implement a pruning mode that deletes just the witnesses. That would also prevent other (post-segwit) nodes from synchronizing off them, but they could still serve some light clients. This is not implemented.

> Should a mining pool temporarily gain 51% control of the blockchain, can they insert transactions, and not include the segwit for a block or two because, by the time other miners are allowed to mine, those signatures will have expired?

I don't understand what you mean here, but signatures don't "expire".

> **Comments:**
> **username_0**: So how can you trim away the signatures if you still need them and how can segwit improve transaction bandwidth if all of the same data still needs to be sent every block. Or am I missing the whole point of segwit, because I thought that was it?  
> **username_1**: You can trim signatures away because segwit outputs look like "anyone can spend" to old nodes. New nodes need the signatures. It doesn't improve bandwidth, it's a block size increase from the perspective of new nodes, but one with better incentive alignment as it makes the data that doesn't go into the UTXO set (which all nodes need to maintain) relatively cheaper. It was combined with other changes that make validation relative cheaper in some worst case situations, and introduce non-malleable transaction identifiers, which do contribute to scalability.  
> **username_0**: Got it, read multiple articles about this.. that explanation actually made sense. Short and concise, thanks.  

---

