📅 Original date posted:2013-04-14
📝 Original message:If we're going to extend/expand message signing, can we please add a
proper ASCII-armored format for it? Really, anything that encodes the
signed message next to the signature, so that there's no ambiguities
about what was signed. You can keep the "bare signatures" as an option
for backwards compatiblity, but offer this as the primary one.
What we really want is to have the user copy an ASCII-armored block of
text into the client (or we could have a URI-extension for this), and
the app pops up with a window that says "The following message has a
valid signature from address 1XKjf32kJbf...: <message>".
I know people argue they'd like to get away from raw addresses and
copy-and-paste. But it'll be a while before that happens, and there's a
lot of demand for Armory to become compatible with Bitcoin-Qt signing.
People are obviously using it.
-Alan
On 04/14/2013 01:09 AM, Peter Todd wrote:
> Currently signmessage/verifymessage only supports messages signed by a
> single key. We should extend that to messages signed by n-of-m keys, or
> from the users point of view, P2SH multisig addresses.
>
> rpc.cpp:signmessage() returns the output of SignCompact(). That in turn
> starts with a header byte marking the signs of the various keys to allow
> for key recovery. The header byte can be one of 0x1B, 0x1C, 0x1D or 0x1E
>
>
> For multisig signmessage signatures this is extended:
>
> <01> <varint n> <varint m> <sig or key> {<sig or key>, ...}
>
> Each signature or key can be one of the following forms:
>
> sig: <1B/1C/1D/1E> <32 byte r> <32 byte s>
> compress key: <02/03> <32 byte x>
> uncompressed key: <04> <32 byte x> <32 byte y>
>
> Note that we have to provide all pubkeys, even if they aren't used for a
> given signature, to allow the P2SH address to be reconstructed.
>
> Decoding/encoding is a bit code-intensive due to the all the cases, but
> on the other hand this format keeps the size down to an absolute
> minimum. Alternatively I could use length bytes.
>
> The format is backwards compatible in the sense that older versions will
> fail safely on new signatures, even ones that have been truncated.
> Similarly new signatures are easily distinguished from old, and going
> forward if we for some reason need yet another signature format the
> leading byte can be incremented.
>
> Signing incomplete signatures on messages can be handled by converting
> pubkeys to signatures. Similarly the RPC signmessage command can be
> extended with an optional "existing signature" option.
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130414/f04c815c/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 11:46:27
in reply to nevent1q…47n0
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hSeen on
wss://relay.nostr.bandPublished at
2023-06-07 11:46:27Event JSON
{
"id": "4524789e9090ee3a20ac3a37bd7c54d11dfb7ae8ee8ccbcc8ab9141f4f9901df",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686138387,
"kind": 1,
"tags": [
[
"e",
"9720ad9bd7e43696cd6d2555906617a4ea649c8903d6d52e997b38fa8148ba1b",
"",
"root"
],
[
"e",
"badde3a5378710cadceb1f48fd12a03a9e5e4664148cdececfaaeb83d21f2b6a",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-04-14\n📝 Original message:If we're going to extend/expand message signing, can we please add a\nproper ASCII-armored format for it? Really, anything that encodes the\nsigned message next to the signature, so that there's no ambiguities\nabout what was signed. You can keep the \"bare signatures\" as an option\nfor backwards compatiblity, but offer this as the primary one.\n\nWhat we really want is to have the user copy an ASCII-armored block of\ntext into the client (or we could have a URI-extension for this), and\nthe app pops up with a window that says \"The following message has a\nvalid signature from address 1XKjf32kJbf...: \u003cmessage\u003e\". \n\nI know people argue they'd like to get away from raw addresses and\ncopy-and-paste. But it'll be a while before that happens, and there's a\nlot of demand for Armory to become compatible with Bitcoin-Qt signing. \nPeople are obviously using it.\n\n-Alan\n\n\n\n\n\nOn 04/14/2013 01:09 AM, Peter Todd wrote:\n\u003e Currently signmessage/verifymessage only supports messages signed by a\n\u003e single key. We should extend that to messages signed by n-of-m keys, or\n\u003e from the users point of view, P2SH multisig addresses.\n\u003e\n\u003e rpc.cpp:signmessage() returns the output of SignCompact(). That in turn\n\u003e starts with a header byte marking the signs of the various keys to allow\n\u003e for key recovery. The header byte can be one of 0x1B, 0x1C, 0x1D or 0x1E\n\u003e\n\u003e\n\u003e For multisig signmessage signatures this is extended:\n\u003e\n\u003e \u003c01\u003e \u003cvarint n\u003e \u003cvarint m\u003e \u003csig or key\u003e {\u003csig or key\u003e, ...}\n\u003e\n\u003e Each signature or key can be one of the following forms:\n\u003e\n\u003e sig: \u003c1B/1C/1D/1E\u003e \u003c32 byte r\u003e \u003c32 byte s\u003e\n\u003e compress key: \u003c02/03\u003e \u003c32 byte x\u003e\n\u003e uncompressed key: \u003c04\u003e \u003c32 byte x\u003e \u003c32 byte y\u003e\n\u003e\n\u003e Note that we have to provide all pubkeys, even if they aren't used for a\n\u003e given signature, to allow the P2SH address to be reconstructed.\n\u003e\n\u003e Decoding/encoding is a bit code-intensive due to the all the cases, but\n\u003e on the other hand this format keeps the size down to an absolute\n\u003e minimum. Alternatively I could use length bytes.\n\u003e\n\u003e The format is backwards compatible in the sense that older versions will\n\u003e fail safely on new signatures, even ones that have been truncated.\n\u003e Similarly new signatures are easily distinguished from old, and going\n\u003e forward if we for some reason need yet another signature format the\n\u003e leading byte can be incremented.\n\u003e\n\u003e Signing incomplete signatures on messages can be handled by converting\n\u003e pubkeys to signatures. Similarly the RPC signmessage command can be\n\u003e extended with an optional \"existing signature\" option.\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Precog is a next-generation analytics platform capable of advanced\n\u003e analytics on semi-structured data. The platform includes APIs for building\n\u003e apps and a phenomenal toolset for data science. Developers can use\n\u003e our toolset for easy data analysis \u0026 visualization. Get a free account!\n\u003e http://www2.precog.com/precogplatform/slashdotnewsletter\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130414/f04c815c/attachment.html\u003e",
"sig": "8d00608df7cd97465031da990a761f548584d6e29e135d65fd1963b0ada112e721d9f946f835ac286cb7e9e629d9ded7eaf5fd8675c14900e4148dbbf07c850f"
}