Sign and verify a message

piJade · runs entirely in this page · nothing is sent anywhere

These are the first receive address of each account. The path decides which key signs, so it also decides which address the signature proves; change the last number to reach the second address, the third, and so on.

Give the page an address to ask whether this signature proves control of it; type it, or press the code button in the field and read it off the device. Left empty, the page shows the address the path above leads to instead.

Format

Standard (Electrum) the only format the device produces

How this works, and what it does not prove

A message signature proves that whoever made it holds the private key behind an address, without revealing that key. The device signs a digest of your text with the key at the derivation path you choose, and anyone holding the message, the signature and the address can check the claim for themselves. No coins move, nothing is broadcast, and the signature says nothing about a balance.

The round trip

The device is never plugged into anything. Both directions are a camera reading a screen: this page draws a code for the device, the device draws one back.

  1. Choose the address type with the buttons under Path, or type a path yourself, and write your text in Message. Press Sign by QR and the code appears below the form.
  2. On piJade open Session, then the wallet fingerprint, then Sign Message. The camera opens. Hold it over the code on this screen.
  3. piJade shows the message, its digest and the derivation path. Read them. Approving signs the message that was scanned, the whole of it. The screen has room for 191 bytes and Sign by QR draws no code from 192 bytes up, so a message this page produced is always one the screen can show in full. A message longer than 96 bytes is spread over two screens, and the summary screen lets you approve without opening the message at all, so step through both screens before you approve.
  4. piJade draws the signature as its own QR code, under Scan QR.
  5. Come back here, press Scan signature and hold your camera over the device screen. If the camera is unavailable, or the browser refuses it, Choose photo reads a still image of the same screen instead.
  6. The verdict appears as soon as the signature is read, and Verify works it out again at any time. With Address left empty the page shows which address the signing key controls; fill that field in and the page answers whether this signature proves control of that exact address.

Checking someone else's signature needs no device at all: type their message, their signature and their address into the three fields and press Verify.

The path decides which address

One seed holds every address you will ever use, and the derivation path picks one key out of it. The three presets are the first receive address of the three account types a single-signature wallet keeps: m/44' for legacy addresses starting 1, m/49' for nested segwit starting 3, m/84' for native segwit starting bc1q. The last number walks along the addresses of that account, so m/84'/0'/0'/0/1 is the second native segwit receive address.

This is where the confusion usually starts. A signature made under m/44' is not a signature for the native segwit address in your wallet's list: those come from m/84', a different key that shares nothing with it but the seed. Pick the type your wallet is showing you before you sign, and the address that comes back is one you can find in that list.

The device can hand you an address to check against, so it need not be typed out. Open Session, the wallet fingerprint, then Address Explorer; pick Receive or Change, choose an address, and the tick draws it as a QR code under Show QR. The code button inside the Address field reads it with the same camera that reads signatures.

Taproot addresses (m/86', starting bc1p) are outside this round trip. They are not proved with a plain recoverable ECDSA signature, which is the only kind the device produces, so there is no preset for one and a Taproot path is not treated as an address type here.

The signature format

The device produces a recoverable ECDSA signature over the usual Bitcoin signed-message digest, base64 encoded, with the header byte written as 31 + recovery id for a compressed key, whatever the derivation path. That is what Standard (Electrum) describes, and it is the only thing the device emits, which is why the field above states it rather than offering a choice. Name that format when a tool asks which one a signature is in.

One consequence is worth knowing. A strict BIP137 verifier reads that same header byte as a statement about the address type: 31 to 34 means legacy, 35 to 38 nested segwit, 39 to 42 native segwit. Since the device writes 31 plus the recovery id everywhere, such a verifier accepts the legacy case and reports an address-type mismatch under a segwit path, although the signature itself is sound. This page recovers the key and compares addresses instead, so what it reports here does not depend on that byte.

What a signature carries, and what it does not

A signature carries the message and the key, never a derivation path. This page recovers the public key from the signature itself, which is enough to work out the single-signature addresses that key controls, and the Path field only decides which of them to show. Editing that field changes what is listed and proves nothing about the signature; a path that is none of 44', 49' or 84' leaves all three listed, because nothing narrows them down.

A match says the signature was made by the key behind that address. It does not say the address is yours: check that the address is the one your own wallet shows at the path you signed under. And a signature only ever proves the message it covers, so read the message before you trust what it says. That message has to be entered here byte for byte, trailing spaces and line breaks included, because the signature covers a digest of the text rather than the text you can see.

What is inside the QR code

One format is accepted; anything else is refused with Not a message to sign:

signmessage <path> ascii:<text>

The path cannot contain a space, because the space is the separator. The text is everything after ascii: and may contain spaces. The device decides whether the path is usable; if it is not, it says Invalid bip32 path.

This page works offline

The QR code is drawn in your browser, the camera frames and photographs are read in your browser, and nothing you type or photograph is sent anywhere. Everything the page needs is inside this one file, so saving it and opening the copy works with no network at all. The device itself never reaches this page; only the phone or computer showing it does.

Do not sign what you have not read. The signature covers the whole message that was scanned, including any part the screen did not have room to show. Signing something you do not understand can produce a document used against you later. If you are unsure, cancel; cancelling costs nothing.