<p>Bitcoin-core already enforces low S-values as a standardness rule for transaction relay, but making a transaction non-standard does not cause a softfork. </p>

<p>BIP-146 does call for a softfork by making high S-values in tx signatures invalid, not just nonstandard. </p>

<p>The BIP also states that the majority of txs on the network already adhere to the low S rule, as of Aug 2016. To quote from it:</p>

<blockquote>
  <p>The reference client has produced LOW_S compatible signatures since v0.9.0, and the LOW_S rule has been enforced as relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by these requirements.</p>
</blockquote>

CC BY-SA 4.0
2019-04-29T12:13:29.010Z
If transactions are treated invalid instead of non-standard, wouldn't it result in rejection of blocks which include such transactions, unless these transaction use a different version? That means, there would a split in the chain
Ugam Kamat
CC BY-SA 4.0
2019-04-29T12:19:51.900Z
Yes, thats why I mentioned BIP146 calls for a softwork, and it says so in the second line of the BIP. If a transaction is considered standard vs non-standard between clients on the network, there will not be a split if the transaction is included in a block. But if the transaction was considered valid vs invalid between clients, then it would cause a split if included in a block.
chytrik
CC BY-SA 4.0
2019-04-29T12:29:33.813Z
I agree, but if everything else remains the same and if Low_S signature is implemented with transactions not using it being treated invalid, then it will result in a hard fork. Soft fork is forward compatible so that clients that have not been updated can still function in the current consensus.
Ugam Kamat
CC BY-SA 4.0
2019-04-29T12:34:21.610Z
Softforks are *backwards* compatible, rules are restricted. Old clients will remain on the network, but if a miner creates a block using an older client's rules, then the newer clients will consider that block invalid and a network fork may occur.
chytrik
CC BY-SA 4.0
2019-04-29T12:38:04.400Z
restriction of rules makes sense.
Ugam Kamat
CC BY-SA 4.0
2019-04-29T23:04:00.257Z
Are you missing a "not" in your first sentence? Changing the standardness is _not_ a soft fork, right?
Jannes
CC BY-SA 4.0
2019-04-29T23:11:49.943Z
@Jannes ah, woops! Good catch on the typo, edited to fix. Thanks.
chytrik
CC BY-SA 4.0
2019-04-29T12:11:03.003Z
2019-04-29T23:10:12.430Z
2019-04-29T23:10:12.430Z
chytrik
<p>Is <a href="https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki" rel="nofollow noreferrer">BIP 146</a>, which defines using the low S value, still on the docket to be signalled and implemented given that SegWit fixed the <code>txid</code> malleability issue by moving the witness outside the transaction? I'm asking because it can fix the <code>wtxid</code> malleability which now requires re-syncing of transaction data when it is changed from what it was originally relayed.</p>

<p>Also, will the implementation be a soft-fork which would treat this transactions as non-standard but miners can still include them in the block, or will it treat the transactions with high S value as invalid?</p>

CC BY-SA 4.0
2019-04-29T16:45:11.330Z
BIP146 and BIP147 were written originally to be activated along with SegWit, but after feedback, only BIP147 was included. 146 should probably be marked withdrawn.
Pieter Wuille
<transactions><segregated-witness><signature><transaction-verification><transaction-malleability>
Following SegWit implementation, is BIP-146 signalling and implementation still on the docket?
Ugam Kamat
# Following SegWit implementation, is BIP-146 signalling and implementation still on the docket?

(Asked by: username_0 on 2019-04-29)

Is [BIP 146](https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki), which defines using the low S value, still on the docket to be signalled and implemented given that SegWit fixed the `txid` malleability issue by moving the witness outside the transaction? I'm asking because it can fix the `wtxid` malleability which now requires re-syncing of transaction data when it is changed from what it was originally relayed.

Also, will the implementation be a soft-fork which would treat this transactions as non-standard but miners can still include them in the block, or will it treat the transactions with high S value as invalid?

**Tags:** transactions, segregated-witness, signature, transaction-verification, transaction-malleability

> **Comments:**
> **username_1**: BIP146 and BIP147 were written originally to be activated along with SegWit, but after feedback, only BIP147 was included. 146 should probably be marked withdrawn.  

---

## 1 answers

### Answer by username_2 on 2019-04-29. Score: 1

Bitcoin-core already enforces low S-values as a standardness rule for transaction relay, but making a transaction non-standard does not cause a softfork.

BIP-146 does call for a softfork by making high S-values in tx signatures invalid, not just nonstandard.

The BIP also states that the majority of txs on the network already adhere to the low S rule, as of Aug 2016. To quote from it:

> The reference client has produced LOW\_S compatible signatures since v0.9.0, and the LOW\_S rule has been enforced as relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by these requirements.

> **Comments:**
> **username_0**: If transactions are treated invalid instead of non-standard, wouldn't it result in rejection of blocks which include such transactions, unless these transaction use a different version? That means, there would a split in the chain  
> **username_2**: Yes, thats why I mentioned BIP146 calls for a softwork, and it says so in the second line of the BIP. If a transaction is considered standard vs non-standard between clients on the network, there will not be a split if the transaction is included in a block. But if the transaction was considered valid vs invalid between clients, then it would cause a split if included in a block.  
> **username_0**: I agree, but if everything else remains the same and if Low_S signature is implemented with transactions not using it being treated invalid, then it will result in a hard fork. Soft fork is forward compatible so that clients that have not been updated can still function in the current consensus.  
> **username_2**: Softforks are *backwards* compatible, rules are restricted. Old clients will remain on the network, but if a miner creates a block using an older client's rules, then the newer clients will consider that block invalid and a network fork may occur.  
> **username_0**: restriction of rules makes sense.  
> **username_3**: Are you missing a "not" in your first sentence? Changing the standardness is _not_ a soft fork, right?  
> **username_2**: @username_3 ah, woops! Good catch on the typo, edited to fix. Thanks.  

---

