From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3237316A0 for ; Tue, 27 Mar 2018 08:10:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7D33F575 for ; Tue, 27 Mar 2018 08:10:10 +0000 (UTC) Received: from ip-10-217-1-36.ap-northeast-1.compute.internal (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 3CC0314C0D3 for ; Tue, 27 Mar 2018 17:10:09 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1) by 0 with SMTP; 27 Mar 2018 17:10:09 +0900 X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id 5484C4C079 for ; Tue, 27 Mar 2018 17:10:06 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw24.oz.hdemail.jp (ip-10-185-138-250.ap-northeast-1.compute.internal [10.185.138.250]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 72AF414C0B9 for ; Tue, 27 Mar 2018 17:10:04 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from mail-qt0-f198.google.com (lb05.oz.hdemail.jp [54.238.57.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw24.oz.hdemail.jp (Postfix) with ESMTP id F2FF2148C10A for ; Tue, 27 Mar 2018 17:10:03 +0900 (JST) X-Received: by mail-qt0-f198.google.com with SMTP id m3so8279505qte.2 for ; Tue, 27 Mar 2018 01:10:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wTx8YqVZcScYPng4lHk8tuPWqiLojR3gsPd3tu/imgc=; b=UaLClPccUf/AEyFzJJ9kUXHnj7hFoDCH1yu4it/Vz+OXI+AsZxG8W/itLTxMrTXwUf 8CG2taseKB+ygR+FRp17RF+InWlBthfI2pxFhxgmcQb97QIbEHFBZPbHccjL1ioP2KYd Yty7ykkG2yKbmIzKNLzFQHfRsEdNcVIFP3e+zLXeCaMf2nF3+XCo2UAWNeRcwGy0P5oe uBISpo51u4O9UghMUMsAIzMZ0poKrySrjJ8zvBNedR4H/vsnRPLBXXWwakhNgeJjLn9J CBlui6eLuJ1wZqHuQmUaa1R7nWyOgvReJJFK/WK75uyO9jj4UCfWmOSA22mgl1jUVWEH OHuQ== X-Gm-Message-State: AElRT7G0usrt973u2e9yb/cMiYw1yU8ehpPFH2pGTTCysq7+ZMBPMuzI dB1l+54iJE3bo/PgAnFkAN7zpUKtt8P/CciJr6TMncvoM45VxwZBxpEFRD95APvkb+8VJy0U2RW 3i4xin/n1gZOLzz1k3dwwo0xrlzYL3oyXT67K+0hBD1ZUA5VtjfhM2Jl6oyzJg6OzIoLtnLBEIz 59TK/aDiYb+pOcMWFOIYADn9o8qXETy7kiMZjyWSkR7T3VbcwBBHdA/RE33e2dX4w9ptwUiIjJP siecvLOaoueEkkS+91L4/wzSycZMdbJO87Ska23DDhXWWmLrn50rjom4cw96CionLeLmS0fsCCP mtxxG8N7iAjeRjP7y6wB4mJbQ8M= X-Received: by 10.237.42.67 with SMTP id k3mr61638439qtf.24.1522138202578; Tue, 27 Mar 2018 01:10:02 -0700 (PDT) X-Google-Smtp-Source: AG47ELv5MzLt/sdEvS0GdDqfcVf1q920D/bnvXHb+PqMLncav7rwhrc8ozJBIGZ1WxNs1T0j/qo7UKNXPNtHUUNHXtQ= X-Received: by 10.237.42.67 with SMTP id k3mr61638391qtf.24.1522138202212; Tue, 27 Mar 2018 01:10:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.12.208.26 with HTTP; Tue, 27 Mar 2018 01:09:41 -0700 (PDT) In-Reply-To: References: From: Karl Johan Alm Date: Tue, 27 Mar 2018 17:09:41 +0900 Message-ID: To: Pieter Wuille Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] {sign|verify}message replacement X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 08:10:11 -0000 Pieter, Thanks for the feedback. Comments below: On Mon, Mar 26, 2018 at 5:53 PM, Pieter Wuille 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
[=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 is true, 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...