Prevent high S signatures (and possibly other malleability causes) by consensus

このissueにはファイル、テスト、エントリーポイントが記載されていません。提案されたコンセンサスの変更、追加される可能性のあるマリアビリティルール、デプロイ要件について設計上の合意が必要であり、その後でなければ新規コントリビューターは実装方針を特定できません。

Is your feature request related to a problem? Please describe.

Pre-segwit inputs cause problems for services building on both Bitcoin and Liquid, due to potential tx malleability (discussed extensively elsewhere). This increases the complexity of coding software which mediates or processes txs for users.

In Bitcoin the relationship to block miners is adversarial - if it is in their interest to do so, they can malleate a tx (or accept a malleated tx via non-standard means) and mine a valid block with it. In Elements/Liquid however the block producers are financially invested in the integrity of the chain and are are expected to not be malicious. A block producer including a malleated tx which facilitates a double spend or theft could erode the trust in the chain and its functionaries. Note that this could happen if a block producer is hacked for example, and not just out of malice/greed.

Liquid/Elements are potentially more sensitive to this issue given the push to build more complex contract structures, where dependent txs can be invalidated by malleation.

Describe the solution you'd like

High-S signatures are already non-standard and cannot be relayed. I propose for Elements we make such signatures invalid by consensus also. By doing so we prevent any possible bad behaviour by block producers, and at the same time reduce the barrier of entry/complexity of creating services using the chain.

Describe alternatives you've considered

The alternative is to do nothing and continue with the status quo. As above this makes building on Elements chains more difficult which could hamper future growth.

Additional context

Note that anyone holding back an old, validly-signed high-S tx must already transmit it OOB to a block producer in order to have it included in the chain. They, or the block producer can always maleiate the sig back to low-S in order to include it after this change is made.

A consensus failure can only occur while this change is deployed to the block producers, and only if one of them decides to fork the chain deliberately. As above the block producers are not incentivized to destroy the chain they work on, nonetheless this risk should be mitigated where required by whatever means are available (For example, updates to any legal contract).

It is possible that other standardness checks could also become consensus checks for Elements however they are not detailed here.