mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2024-12-28 17:44:47 +01:00
Code Issues Projects Releases Wiki Activity
d0a55a62b3
core-lightning/doc/lightning-checkmessage.7.md

54 lines
1.5 KiB
Markdown
Raw Normal View History

Minor wording
2021-02-07 17:20:23 +01:00
lightning-checkmessage -- Command to check if a signature is from a node
doc: man pages for checkmessage and signmessage. They're a little subtle, so let's spell out exactly what checkmessage means. In particular, we avoid discussing key derivation from a signature, as it tends to get people (like me!) into trouble: we describe it instead as iterating through every known node. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-10-13 07:19:37 +02:00
=====================================================================
SYNOPSIS
--------
Remove useless \
2022-01-26 18:18:49 +01:00
**checkmessage** *message* *zbase* [*pubkey*]
doc: man pages for checkmessage and signmessage. They're a little subtle, so let's spell out exactly what checkmessage means. In particular, we avoid discussing key derivation from a signature, as it tends to get people (like me!) into trouble: we describe it instead as iterating through every known node. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-10-13 07:19:37 +02:00
DESCRIPTION
-----------
The **checkmessage** RPC command is the counterpart to
**signmessage**: given a node id (*pubkey*), signature (*zbase*) and a
*message*, it verifies that the signature was generated by that node
for that message (more technically: by someone who knows that node's
secret).
As a special case, if *pubkey* is not specified, we will try every
known node key (as per *listnodes*), and verification succeeds if it
matches for any one of them. Note: this is implemented far more
efficiently than trying each one, so performance is not a concern.
RETURN VALUE
------------
doc: schema for listconfigs, compare with documentation. This made me document what are options are now in plugins, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-16 03:12:17 +02:00
[comment]: # (GENERATE-FROM-SCHEMA-START)
On success, an object is returned, containing:
- **verified** (boolean): Whether the signature was valid
doc: man pages for checkmessage and signmessage. They're a little subtle, so let's spell out exactly what checkmessage means. In particular, we avoid discussing key derivation from a signature, as it tends to get people (like me!) into trouble: we describe it instead as iterating through every known node. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-10-13 07:19:37 +02:00
doc: schema for listconfigs, compare with documentation. This made me document what are options are now in plugins, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-16 03:12:17 +02:00
If **verified** is *true*:
- **pubkey** (pubkey): the *pubkey* parameter, or the pubkey found by looking for known nodes
doc: man pages for checkmessage and signmessage. They're a little subtle, so let's spell out exactly what checkmessage means. In particular, we avoid discussing key derivation from a signature, as it tends to get people (like me!) into trouble: we describe it instead as iterating through every known node. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-10-13 07:19:37 +02:00
doc: schema for listconfigs, compare with documentation. This made me document what are options are now in plugins, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-16 03:12:17 +02:00
If **verified** is *false*:
- **pubkey** (pubkey): the *pubkey* (if any) which could have signed this; this is usually not useful!
doc: fix GH/readthedocs rendering of manual pages. They render the comment as if it's in the list. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-09-03 12:07:59 +02:00
doc: schema for listconfigs, compare with documentation. This made me document what are options are now in plugins, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-16 03:12:17 +02:00
[comment]: # (GENERATE-FROM-SCHEMA-END)
doc: man pages for checkmessage and signmessage. They're a little subtle, so let's spell out exactly what checkmessage means. In particular, we avoid discussing key derivation from a signature, as it tends to get people (like me!) into trouble: we describe it instead as iterating through every known node. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-10-13 07:19:37 +02:00
AUTHOR
------
Rusty Russell <<rusty@rustcorp.com.au>> is mainly responsible.
SEE ALSO
--------
lightning-signmessage(7)
RESOURCES
---------
Main web site: <https://github.com/ElementsProject/lightning>
doc: force refresh of all manpages. The idea is that you regenerate the man pages in the same commit you alter them: that's how we know whether to try regenerating them or not (git doesn't store timestamps, so it can't really tell). Travis will now check this, so force them all to sync to this commit. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2020-08-25 03:33:16 +02:00
make-schema: don't include tools/fromschema.py in SHASUMS We were including the entire list of prerequisites when generating a shastamp, which for schemas includes the `tools/fromschema.py` doc. This meant all of our shasums were updating anytime this tool file changed. Instead, we just include the first prerequisite. See: https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html#Automatic-Variables
2022-07-13 17:45:39 +02:00
[comment]: # ( SHA256STAMP:7dcca1fd1708d93b4a0c9b83955630fc4f551c4ffd452fb866c624c72aeaa44d)
Reference in New Issue Copy Permalink