Following SegWit implementation, is BIP-146 signalling and implementation still on the docket?

0

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?

Ugam Kamat

Posted 2019-04-29T11:52:18.960

Reputation: 5 180

1BIP146 and BIP157 were written originally to be activated along with SegWit, but after feedback, only BIP147 was included. 146 should probably be marked withdrawn. – Pieter Wuille – 2019-04-29T16:45:11.330

@PieterWuille You mean BIP 157 was included? – Ugam Kamat – 2019-04-29T16:47:32.330

Eh, I mean BIP147. – Pieter Wuille – 2019-04-29T17:01:11.477

Answers

0

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.

chytrik

Posted 2019-04-29T11:52:18.960

Reputation: 10 276

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 – 2019-04-29T12:13:29.010

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 – 2019-04-29T12:19:51.900

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 – 2019-04-29T12:29:33.813

1Softforks 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 – 2019-04-29T12:34:21.610

restriction of rules makes sense. – Ugam Kamat – 2019-04-29T12:38:04.400

Are you missing a "not" in your first sentence? Changing the standardness is not a soft fork, right? – Jannes – 2019-04-29T23:04:00.257

@Jannes ah, woops! Good catch on the typo, edited to fix. Thanks. – chytrik – 2019-04-29T23:11:49.943

Asked: 2019-04-29T11:52:18.960

Viewed: 55 times

Active: 2019-09-27T01:02:10.277