public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Karl Johan Alm <karljohan-alm@garage.co.jp>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
Date: Tue, 27 Mar 2018 17:09:41 +0900	[thread overview]
Message-ID: <CALJw2w7UJ6JT9jpuV9c9OtOMrqNNGR0OJauwnMo7DJfWG=L_SQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBhAaw7uqdz6ZoMCkut2GM=3=F22FiHw6J_aLwTMEcqt1g@mail.gmail.com>

Pieter,

Thanks for the feedback. Comments below:

On Mon, Mar 26, 2018 at 5:53 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> One solution is to include a version number in the signature, which
> explicitly corresponds to a set of validation flags. When the version number
> is something a verifier doesn't know, it can be reported as inconclusive
> (it's relying on features you don't know about).
>
> An solution is to verify twice; once with all consensus rules you know
> about, and once with standardness rules. If they're both valid, the
> signature is valid. If they're both invalid, the signature is invalid. If
> they're different (consensus valid but standardness invalid), you report the
> signature validation as inconclusive (it's relying on features you don't
> know about). This approach works as long as new features only use previous
> standardness-invalid scripts, but perhaps a version number is still needed
> to indicate the standardness flags.

I think the double verify approach seems promising. I assume old nodes
consider new consensus rule enforcing transactions as non-standard but
valid. If this is always the case, it may be an idea to simply fail
verification with a message indicating the node is unable to verify
due to unknown consensus rules.

>> RPC commands:
>>
>> sign <address> <message> [<prehashed>=false]
>
> Why not extend the existing signmessage/verifymessage RPC? For legacy
> addresses it can fall back to the existing signature algorithm, while using
> the script-based approach for all others.

Yes, I initially thought it would be better to not use it as the
legacy behavior could be depended on god knows where, but I think
adding a legacy mode or simply doing the old way for 1xx is
sufficient.

>> (**) If <prehashed> is true, <message> is the sighash, otherwise
>> sighash=sha256d(message).
>
>
> That's very dangerous I'm afraid. It could be used to trick someone into
> signing off on an actual transaction, if you get them to sign a "random
> looking" prehashed message. Even if you have a prehashed message, there is
> no problem with treating it as hex input to a second hashing step, so I
> think the prehashed option isn't needed. It's why the existing message
> signing functionality always forcibly prefixes "Bitcoin signed message:", to
> avoid signing something that unintentionally corresponds to a message
> intended for another goal.

Eek.. good point...


      reply	other threads:[~2018-03-27  8:10 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
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 [this message]

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='CALJw2w7UJ6JT9jpuV9c9OtOMrqNNGR0OJauwnMo7DJfWG=L_SQ@mail.gmail.com' \
    --to=karljohan-alm@garage.co.jp \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pieter.wuille@gmail.com \
    /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