Skip to content

NEP-message-signing#213

Open
ajara87 wants to merge 1 commit intomasterfrom
nep-message-signing
Open

NEP-message-signing#213
ajara87 wants to merge 1 commit intomasterfrom
nep-message-signing

Conversation

@ajara87
Copy link
Member

@ajara87 ajara87 commented Dec 8, 2025

Add message singing proposal

wallet sign message <message>
</pre>

A conforming implementation MUST:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The standard is written in a way that ensures there is a single implementation. NEPs shouldn't specify CLI commands.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you Roman. I'll rewrite it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to add that it be described in a language agnostic way. I see a lot of C# code in there

That is:

* 4 bytes: `networkMagic` in little-endian.
* Followed by 32 bytes: the serialized `hash` (`UInt256`).
Copy link
Contributor

@ixje ixje Dec 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why UInt256 got involved here.

Can't we just say something along the lines of


The data to be signed using secp256r1 is a byte array consisting of; a + b where

  • a is the networkMagic encoded as a 32-bit little-endian unsigned integer
  • b is the sha256(sha256(payload)) digest where payload is formatted as described in <section xyz>

All these C# code references from the neo project make no sense for other languages and should be irrelevant for a specification.

Instead, I would suggest to add a section with test vectors so implementers can verify their implementations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you @ixje I'm rewriting the proposal. It will be uploaded next weak.

Copy link
Member

@shargon shargon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My data Idea:

NetworkMagic (GetSignData already added) + Ocode.RET + 4 bytes for ValidUntilBlock + 4/8 bytes for nonce + message

This allow:

  • Avoid to use the message as script because the first RET and transaction wrapper.
  • Refuse a signature if the block was reached.
  • Refuse a signature if it's the wrong network.

@roman-khimov
Copy link
Contributor

Wallets do no work this way. Wallets sign the thing described in the proposal. It's not new, it just tries to outline things that are known for years, de facto standard.

@erikzhang
Copy link
Member

I believe the message signature should always be verifiable and should not include a ValidUntilBlock.

@roman-khimov
Copy link
Contributor

roman-khimov commented Dec 30, 2025

Refuse a signature if the block was reached.
Refuse a signature if it's the wrong network.

Abstract message is not a transaction, these things are out of scope to me. It's message and its interpretation that matters wrt this. The main thing this standard tries to do is to avoid signing a valid transaction.

@shargon
Copy link
Member

shargon commented Jan 5, 2026

I believe the message signature should always be verifiable and should not include a ValidUntilBlock.

But if we include the blockchain protection (using GetSignData) we will be incompatible with the wallet implementation also

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants