From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Karl Johan Alm <karljohan-alm@garage.co.jp>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
Date: Wed, 14 Mar 2018 10:46:55 +0100 [thread overview]
Message-ID: <CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com> (raw)
In-Reply-To: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]
Thank you.
I can't really see from your proposal if you had thought of this: A soft
fork can make old nodes accept invalid message signatures as valid. For
example, a "signer" can use a witness version unknown to the verifier to
fool the verifier. Witness version is detectable (just reject unknown
witness versions) but there may be more subtle changes. Segwit was not
"detectable" in that way, for example.
This is the reason why I withdrew BIP120. If you have thought about the
above, I'd be very interested.
/Kalle
Sent from my Sinclair ZX81
Den 14 mars 2018 16:10 skrev "Karl Johan Alm via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Hello,
I am considering writing a replacement for the message signing tools
that are currently broken for all but the legacy 1xx addresses. The
approach (suggested by Pieter Wuille) is to do a script based
approach. This does not seem to require a lot of effort for
implementing in Bitcoin Core*. Below is my proposal for this system:
A new structure SignatureProof is added, which is a simple scriptSig &
witnessProgram container that can be serialized. This is passed out
from/into the signer/verifier.
RPC commands:
sign <address> <message> [<prehashed>=false]
Generates a signature proof for <message> using the same method that
would be used to spend coins sent to <address>.**
verify <address> <message> <proof> [<prehashed>=false]
Deserializes and executes the proof using a custom signature checker
whose sighash is derived from <message>. Returns true if the check
succeeds, and false otherwise. The scriptPubKey is derived directly
from <address>.**
Feedback welcome.
-Kalle.
(*) Looks like you can simply use VerifyScript with a new signature
checker class. (h/t Nicolas Dorier)
(**) If <prehashed> is true, <message> is the sighash, otherwise
sighash=sha256d(message).
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 3055 bytes --]
next prev parent reply other threads:[~2018-03-14 9:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-14 8:09 [bitcoin-dev] {sign|verify}message replacement Karl Johan Alm
2018-03-14 9:46 ` Kalle Rosenbaum [this message]
2018-03-14 16:12 ` Anthony Towns
2018-03-15 3:01 ` Karl Johan Alm
2018-03-15 6:43 ` Jim Posen
2018-03-15 7:25 ` Karl Johan Alm
2018-03-15 20:53 ` Jim Posen
2018-03-14 12:36 ` Luke Dashjr
2018-03-15 7:36 ` Karl Johan Alm
2018-03-15 14:14 ` Luke Dashjr
2018-03-16 0:38 ` Karl Johan Alm
2018-03-16 1:59 ` Greg Sanders
2018-03-16 2:04 ` Karl Johan Alm
2018-03-15 10:15 ` Damian Williamson
2018-03-26 8:53 ` Pieter Wuille
2018-03-27 8:09 ` Karl Johan Alm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com' \
--to=kalle@rosenbaum.se \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=karljohan-alm@garage.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox