Add ability to sign and check arbitrary messages using the failing_noop operation to local forger

[jevonearth]

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

Signing arbitrary data is a common activity in blockchain, but it presents risks in that a wallet, if permissive, can sign a malicious operation that is purporting to be arbitrary data.

Describe the solution you'd like

The florencenet protocol amendment introduced a new operation type called failing_noop which is an operation type that is guaranteed to never be included in the chain.

Acceptance criteria

• Implement abstractions in Taquito to easily sign arbitrary data wrapped in a failing_noop operation.
• Implement abstractions in Taquito to easily check the signature validity of a signed failing_noop operation.
• Make sure it works for both contract and wallet API
• An integration tests that attempts to inject a valid failing_noop operation that are expected to fail
• Abstractions should be similar to already implemented RPC forger

Describe alternatives you've considered

Prior to this operation type, wallet developers implemented a data structure to help mitigate this risk. See: https://docs.google.com/document/d/1ZgA7mZNrWl1YZ0snzjiFw1ahyXjvWFS1GvU5-caUDCE/edit

Additional context

If Taquito implements the ability to sign and check data using this operation type, wallet developers are more likely to restrict the signing of arbitrary data that comes in the form of a failing_noop operation.

See Tezos MR https://gitlab.com/tezos/tezos/-/merge_requests/2361 for more information.

[Innkst]

We have support for this in RPC forger, but could add it to local forger and create an integration test.

[fredcy]

Near as I can tell, the local forger does not yet support the failing_noop operation kind. If so, could it be please be added?

[Innkst]

@fredcy would you be able to share some details on how you are using it? It will help us to know more about your use case.

[fredcy]

I am trying to create a proof of concept dApp that signs arbitrary text messages over Beacon. I have it working using the ad hoc "0501"-prefixed Micheline string value method and I want to try using a failing_noop approach that was once recommended as a better alternative.

Several of us plan to write a new tzip to document the current 0501 string value method already implemented by some dApps and wallets, and to write another new tzip to document an alternative safe-signing approach based on failing_noop.

[Innkst]

See related request with the use case description here #2507