9 standards
Signing and verifying as something an application asks for in its own right, rather than as part of building a transaction: signing a message, proving one request is genuine, and signing a list of what a server may be asked to do.
Also searched as sign, verify, HMAC, signed proof, attestation.
9 standards, spread across 6 of the 12 topics.
Proving a message really came from you usually means keeping a signing key inside the application, which is both risky and easy to get wrong. This lets an application ask the wallet to sign on the user's behalf, and can produce a signature only the intended recipient is able to check.
Filed under Wallet
Signatures is the main subject of these 3.
Proving a message really came from you usually means keeping a signing key inside the application, which is both risky and easy to get wrong. This lets an application ask the wallet to sign on the user's behalf, and can produce a signature only the intended recipient is able to check.
Signing a plain message is not the same problem as signing a transaction, and doing it ad hoc leads to signatures nobody else can check. This defines how messages are signed and verified, including signatures only the intended recipient can confirm.
Smart contracts sometimes need to check a signature over arbitrary data, like a price or a game move, but Bitcoin's scripting language can only verify one kind of signature cheaply, and that kind does not work for arbitrary data. Until now, apps that needed this had to generate and hold the special signing key themselves, which meant the user had no way to see, control, or recover it through their wallet. This lets the wallet hold and use that key instead, so the app never has to.
These are about something else, and deal with signatures on the way.
Sometimes you want to lock coins so that anyone who knows a particular secret can claim them, without publishing the secret itself. This describes a way to do that using a value which already appears inside every signature.
Revealing a shared secret is only useful if the recipient can confirm it is the right one, and handing over the key that proves it defeats the point. This lets the prover demonstrate correctness without revealing anything more.
Proving you hold a key normally takes a back-and-forth, which is more than a single request should need. This lets one request carry its own proof, usable once and no more.
A service can get cut off from its users when a domain registrar suspends a name, a host is seized, or an app store delists it, even though the service itself is still running fine. Normally there is no way for a client to find a service again once the one path it knew about disappears, short of shipping a brand new app update. This gives a client a way to rediscover the service through a record nobody can take down, because it lives on the blockchain.
Proving something existed and was signed at a certain time normally means publishing the thing itself. This puts only a hash on the chain and issues a certificate anyone can check, so the content stays private.
Anyone could mint a digital asset on Bitcoin and slap a name on it, but a person holding that asset later had no reliable way to know who actually made it or whether a signature claim was real or copy-pasted from somewhere else. Without a fixed, checkable link between an asset and its creator, buyers were trusting unverifiable labels, and marketplaces had no consistent way to show provenance. This makes it possible to prove, cryptographically and tied to the exact transaction, which wallet identity issued a given asset.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic