Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 10E66121E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 14 Mar 2018 16:12:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C0375CD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 14 Mar 2018 16:12:23 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=[10.74.50.213])
	by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian))
	id 1ew90l-0005xj-JT; Thu, 15 Mar 2018 02:12:20 +1000
Date: Wed, 14 Mar 2018 12:12:11 -0400
In-Reply-To: <CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
	<CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Kalle Rosenbaum <kalle@rosenbaum.se>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Kalle Rosenbaum via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Karl Johan Alm <karljohan-alm@garage.co.jp>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: Anthony Towns <aj@erisian.com.au>
Message-ID: <C0F50D50-C514-47BE-BC93-A5BD01E5826E@erisian.com.au>
X-Spam-Score: -2.9
X-Spam-Score-int: -28
X-Spam-Bar: --
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2018 16:12:24 -0000

On 14 March 2018 5:46:55 AM GMT-04:00, Kalle Rosenbaum via bitcoin-dev <bit=
coin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>Thank you=2E
>
>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=2E For
>example, a "signer" can use a witness version unknown to the verifier
>to
>fool the verifier=2E Witness version is detectable (just reject unknown
>witness versions)  but there may be more subtle changes=2E Segwit was not
>"detectable" in that way, for example=2E
>
>This is the reason why I withdrew BIP120=2E If you have thought about the
>above, I'd be very interested=2E
>
>/Kalle
>
>Sent from my Sinclair ZX81
>
>Den 14 mars 2018 16:10 skrev "Karl Johan Alm via bitcoin-dev" <
>bitcoin-dev@lists=2Elinuxfoundation=2Eorg>:
>
>Hello,
>
>I am considering writing a replacement for the message signing tools
>that are currently broken for all but the legacy 1xx addresses=2E The
>approach (suggested by Pieter Wuille) is to do a script based
>approach=2E This does not seem to require a lot of effort for
>implementing in Bitcoin Core*=2E Below is my proposal for this system:
>
>A new structure SignatureProof is added, which is a simple scriptSig &
>witnessProgram container that can be serialized=2E This is passed out
>from/into the signer/verifier=2E
>
>RPC commands:
>
>sign <address> <message> [<prehashed>=3Dfalse]
>
>Generates a signature proof for <message> using the same method that
>would be used to spend coins sent to <address>=2E**
>
>verify <address> <message> <proof> [<prehashed>=3Dfalse]
>
>Deserializes and executes the proof using a custom signature checker
>whose sighash is derived from <message>=2E Returns true if the check
>succeeds, and false otherwise=2E The scriptPubKey is derived directly
>from <address>=2E**
>
>Feedback welcome=2E
>
>-Kalle=2E
>
>(*) Looks like you can simply use VerifyScript with a new signature
>checker class=2E (h/t Nicolas Dorier)
>(**) If <prehashed> is true, <message> is the sighash, otherwise
>sighash=3Dsha256d(message)=2E
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev

Wouldn't it be sufficient for old nodes to check for standardness of the s=
pending script and report non-standard scripts as either invalid outright, =
or at least highly questionable? That should prevent confusion as long as s=
oft forks are only making nonstandard behaviours invalid=2E

Cheers,
aj

--=20
Sent from my phone=2E