<p>Because a <a href="https://bitcoin.stackexchange.com/a/54951/60443">soft fork by definition</a> follows stricter rules than the normal chain, you would have to make assumptions based on the block data. For example, if a soft fork no longer allows certain scripts, you might be able to determine that by noticing that those scripts are no longer present in any blocks from that miner. However, it would be a guess since it is still a valid block, and just might happen to not contain those scripts.</p>
<p>There might be other changes that would be more obvious, but still a guess because the blocks will remain valid according to consensus rules.</p>
<p><strong>Edit:</strong>
Regarding Segwit (<a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP141</a>), the block indeed contains extra data regarding the witness data, specifically the <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure" rel="nofollow noreferrer">commitment structure</a> which contains a witness root hash:</p>
<blockquote>
<p>A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.</p>
<p>The commitment is recorded in a scriptPubKey of the coinbase transaction.</p>
</blockquote>
<p>However, without knowing what to expect (and without the witness data, which was not sent to old nodes), this data is meaningless. One thing that does give away data that may appear to be extraneous is the use of the <code>OP_RETURN</code> script code, since this allows arbitrary data to be included in a transaction, and this is used in the commitment structure.</p>
<p>It is also interesting to see how BIP141 handled older nodes, by simply not sending witness data, see <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#backward-compatibility" rel="nofollow noreferrer">Backwards Compatibility</a>. The segwit transactions appear to be anyone-can-spend scripts to older nodes, so the only thing they lose out on is the ability to validate segregated witness transactions, since it will assume such transactions are always valid. They don't know about or propagate witness data.</p>

CC BY-SA 4.0
2019-12-10T17:02:13.960Z
I agree but could such a soft fork be a contentions fork? I imagine there could be contentious soft fork that the miners would adopt where we can see there is foreign data besides the block that are being propagated. Right? or the data is not going to be propagated unless all nodes installed that soft fork and decide to propagate it. Do old nodes propagate the segregated witness data part of the blocks?
zndtoshi
CC BY-SA 4.0
2019-12-10T17:31:37.737Z
@zndtoshi see edited answer with more info on segwit
JBaczuk
CC BY-SA 4.0
2019-12-10T15:52:20.187Z
2019-12-10T17:31:23.307Z
2020-06-16T11:10:03.350Z
JBaczuk
<p>Can we analyze the blocks or the data sent per block in order to see if it includes new data that we do not recognize and assume that's a soft fork and invalidate such a block?
Can a softforked mining node send data that a user's fullnode can't tell it's foreign?</p>

<soft-fork>
Can we detect contentious soft forks created by the miners?
zndtoshi
# Can we detect contentious soft forks created by the miners?

(Asked by: username_0 on 2019-12-10)

Can we analyze the blocks or the data sent per block in order to see if it includes new data that we do not recognize and assume that's a soft fork and invalidate such a block?
Can a softforked mining node send data that a user's fullnode can't tell it's foreign?

**Tags:** soft-fork


---

## 1 answers

### Answer by username_1 on 2019-12-10. Score: 1

Because a [soft fork by definition](https://bitcoin.stackexchange.com/a/54951/60443) follows stricter rules than the normal chain, you would have to make assumptions based on the block data. For example, if a soft fork no longer allows certain scripts, you might be able to determine that by noticing that those scripts are no longer present in any blocks from that miner. However, it would be a guess since it is still a valid block, and just might happen to not contain those scripts.

There might be other changes that would be more obvious, but still a guess because the blocks will remain valid according to consensus rules.

**Edit:**
Regarding Segwit ([BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)), the block indeed contains extra data regarding the witness data, specifically the [commitment structure](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure) which contains a witness root hash:

> A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.
>
> The commitment is recorded in a scriptPubKey of the coinbase transaction.

However, without knowing what to expect (and without the witness data, which was not sent to old nodes), this data is meaningless. One thing that does give away data that may appear to be extraneous is the use of the `OP_RETURN` script code, since this allows arbitrary data to be included in a transaction, and this is used in the commitment structure.

It is also interesting to see how BIP141 handled older nodes, by simply not sending witness data, see [Backwards Compatibility](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#backward-compatibility). The segwit transactions appear to be anyone-can-spend scripts to older nodes, so the only thing they lose out on is the ability to validate segregated witness transactions, since it will assume such transactions are always valid. They don't know about or propagate witness data.

> **Comments:**
> **username_0**: I agree but could such a soft fork be a contentions fork? I imagine there could be contentious soft fork that the miners would adopt where we can see there is foreign data besides the block that are being propagated. Right? or the data is not going to be propagated unless all nodes installed that soft fork and decide to propagate it. Do old nodes propagate the segregated witness data part of the blocks?  
> **username_1**: @username_0 see edited answer with more info on segwit  

---

