1

Is BIP 146, 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?

Improve this question
1
  • 2
    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
    Apr 29, 2019 at 16:45

1 Answer 1

Reset to default
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.

Improve this answer
7
  • 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
    Apr 29, 2019 at 12:13
  • 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
    Apr 29, 2019 at 12:19
  • 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
    Apr 29, 2019 at 12:29
  • 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.
    – chytrik
    Apr 29, 2019 at 12:34
  • restriction of rules makes sense.
    – Ugam Kamat
    Apr 29, 2019 at 12:38

Your Answer

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

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