# New TZIP draft: Signer requests **URL:** \ **Category:** TZIP\ **Created:** [September 21, 2022, 7:24pm UTC](https://forum.tezosagora.org/t/new-tzip-draft-signer-requests/4751 "2022-09-21T19:24:51Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![oteku](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/oteku/32/1592_2.png) [@oteku](https://forum.tezosagora.org/u/oteku)\ **Post date:** [September 21, 2022, 7:24pm UTC](https://forum.tezosagora.org/t/new-tzip-draft-signer-requests/4751/1 "2022-09-21T19:24:51Z")
I draft a TZIP as a reference of Magic Bytes used by signer applications and the workflow to reserve a new byte. > **[create tzip26 (!195) · Merge requests · Tezos / tzip · GitLab](https://gitlab.com/tezos/tzip/-/merge_requests/195)** > > A reference of Magic Bytes used by signer applications and the workflow to reserve a new byte. With incoming Layer 2 like Deku or SCORU I would like to propose a convention to ease integration with wallet editors or any signer application. All comments are welcome ---
**Author:** ![tom](https://forum.tezosagora.org/letter_avatar_proxy/v4/letter/t/3d9bf3/32.png) [@tom](https://forum.tezosagora.org/u/tom)\ **Post date:** [October 10, 2022, 7:29pm UTC](https://forum.tezosagora.org/t/new-tzip-draft-signer-requests/4751/2 "2022-10-10T19:29:48Z")
For people who know about the “`failing_noop`”, there is a kind of obvious question here, which is ignored by the TZIP: why not use `failing_noop` as it was ostensibly designed for this? I could try to explain why I think the TZIP’s idea is better, and I might do so later. I would like to learn more about current tool behavior before I try to do that, though, since to me the most convincing argument _for_ failing\_noop is that it is “already supported” in some sense by tools. Right now, I just want to give a brief description of the failing\_noop for others who might consider this question. Here, I think, is the intended failing\_noop schema: ```auto 0x030x11 ``` The 0x03 is the Tezos generic operation magic byte, which by some strange logic 😉 is being used (with 0x11) to indicate that the message is _not_ a Tezos operation… No one has ever specified how you are supposed to set or verify the ``. I think `tezos-client sign message` sets it to the current head block hash or to whatever the user specifies. I think there was something somewhere (forget what) suggesting to use the genesis block hash. The original application of failing\_noop (in the rejected “Florence + baker account” protocol amendment) used zero bytes… The implementer of failing\_noop has suggested to me in private that this question be left up to the application – I am not very happy about that idea, but it could work. The 0x11 is the id (17) for the failing\_noop operation kind, which is defined in the protocol to always fail with an error. The `` is the 4-byte big-endian length of the following message bytes. The `` is arbitrary bytes. Or is it? The Florence + baker account usage of failing\_noop used a 4-byte tag prefix, which was presumably the hash of some description of the message type. This convention was never documented anywhere publicly. The developer of failing\_noop has recently proposed using a single “dapp-specific magic byte” as a prefix in the message. Two notes for now: It’s not _completely_ clear whether the above schema is really the only failing\_noop schema. E.g. one can craft an operation containing _two_ failing\_noops (that is why the message length is there) – should these always be rejected by validators? Additionally, it’s unclear whether the schema might change over time if the implementation details in Tezos change. Neither answer seems attractive – we don’t want the schema to change over time, but if it does not change with Tezos then it will seemingly no longer achieve its design goal, of being a Tezos message which means “this is not a Tezos message.” ---
**Author:** ![gsebil08](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/gsebil08/32/1738_2.png) [@gsebil08](https://forum.tezosagora.org/u/gsebil08)\ **Post date:** [October 26, 2022, 1:36pm UTC](https://forum.tezosagora.org/t/new-tzip-draft-signer-requests/4751/3 "2022-10-26T13:36:31Z")
Hi there, I have written a quick hackmd to explain the purpose of this Magic Byte. You can find it [here](https://hackmd.io/@marigold-dev/BycXLaA7o), feel free to comment it 🙂 , all comments are welcome! Cheers ---
**Author:** ![Britcoin](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/britcoin/32/1645_2.png) [@Britcoin](https://forum.tezosagora.org/u/Britcoin)\ **Post date:** [December 9, 2022, 4:00pm UTC](https://forum.tezosagora.org/t/new-tzip-draft-signer-requests/4751/4 "2022-12-09T16:00:06Z")
I read the discussion on gitlab and it seems it just stopped around over a month ago, I am curious where this TZIP proposal goes. ---
**Author:** ![zamrokk](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/zamrokk/32/1634_2.png) [@zamrokk](https://forum.tezosagora.org/u/zamrokk)\ **Post date:** [December 9, 2022, 6:18pm UTC](https://forum.tezosagora.org/t/new-tzip-draft-signer-requests/4751/5 "2022-12-09T18:18:14Z")
Deku integration in BeaconSDK is at 50% I am having a look at the section about magic bytes these days On Deku side, it is already deployed on the Deku-C instance on ghostnet The main blocker right now is the availability of Airgap team to review the actual PR, they committed to include it in the next BeaconSDK release (I don’t have a date yet). There is another PR on Temple that is following. I did a working partial demo (not including yet the magic byte signing, but the other way of doing transfer) if you are curious : [dekuTransferDemo - YouTube](https://www.youtube.com/watch?v=P5cUlmby0kk) Thank you @Britcoin for asking. The thread is in private slack so there is no obvious visibility about it