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 5A55011DC for ; Wed, 14 Mar 2018 09:46:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A57D85CE for ; Wed, 14 Mar 2018 09:46:57 +0000 (UTC) Received: by mail-vk0-f48.google.com with SMTP id p189so1567427vkd.10 for ; Wed, 14 Mar 2018 02:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rosenbaum-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=otLWfI8x5bMaCYfx022hPXrverAlsa3za0y3yPl63w8=; b=O081/x8mmMImA8YcYipEN9L/5FYk4Z2/A4LbpegDXxp7lWmarEo+gqHo4HZCt85opO ChMvL31XZnL1hQ4VmL6a3jS8+tTZunMIXhts9TqhXluH1AWNGoTsx12XfAaNHUWE8zZ/ SD12pjHAScBasOVVQZ1YdVSDShfaFEC5LfxyCv6RteOiD160gdXasxwcgylyNYOvVp3b DPQ/DhlF86IgkrKm4I7O7pyClzXo2T+M9CDW9R8pGNSs0XYqOnLasaZrT3djelxt+QuN MizDBwKc/lxP0P8Ovh93wRyKbMng40ETEZjKjV79aJG/+1uEYU1HqawLMpVrQaZMg3TC 9ZJQ== 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; bh=otLWfI8x5bMaCYfx022hPXrverAlsa3za0y3yPl63w8=; b=n5/KleotMbIt74fdUrFLGPipwjN+w9RpE0UDIMJa7WDZcCALN6XD7PAhLOy2D+jAD+ 7g4/p2aWVfkUfwoef7W17TbkrVRFNNIealUrN4AmrJRJMDaK+SQBdkvGpkosKiJ4C8kA zimyt6WvQQPaT1py7xKBwk5vtUpN4aoABoTHAWgvlcAw8ZzbisyZBad4F45Dz5PoO/HG BBTOfHYBB7eZRy7prQHFUKUfzsi3LTB9/kx6RSle8KnF2ijIw2hCw4p0hlp6N7Ed0J6g YMq4gpSgZLsk5idXPskp45c/G4+Ax7JlNonkV/VgaN3AOGKCdryi0z+SzeiL2BxJxUwW dh+g== X-Gm-Message-State: AElRT7Hr4xfQjwzI8Vt1HSJOa0xvut+F/xsPxMHuxpoAK9o8saiy4BHx Zs7dqT1q9Hdnf+lA9tyjpxKS9QJ5v2ZzQ9+04C1WY5gS X-Google-Smtp-Source: AG47ELuX+0sWnLT5OEFcNn9x26P85sF5v7ks0xnFwjyCgbC6zLt9QUrQ5f67v94NjmpJcoDqRemUGuzhzEFQrkgRT9k= X-Received: by 10.31.131.197 with SMTP id f188mr2781437vkd.24.1521020816699; Wed, 14 Mar 2018 02:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.65 with HTTP; Wed, 14 Mar 2018 02:46:55 -0700 (PDT) Received: by 10.159.61.65 with HTTP; Wed, 14 Mar 2018 02:46:55 -0700 (PDT) In-Reply-To: References: From: Kalle Rosenbaum Date: Wed, 14 Mar 2018 10:46:55 +0100 Message-ID: To: Karl Johan Alm , bitcoin-dev Content-Type: multipart/alternative; boundary="001a1143df5c79cc7005675c414c" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, 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 X-Mailman-Approved-At: Wed, 14 Mar 2018 13:10:34 +0000 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: Wed, 14 Mar 2018 09:46:58 -0000 --001a1143df5c79cc7005675c414c Content-Type: text/plain; charset="UTF-8" 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
[=false] Generates a signature proof for using the same method that would be used to spend coins sent to
.** verify
[=false] Deserializes and executes the proof using a custom signature checker whose sighash is derived from . Returns true if the check succeeds, and false otherwise. The scriptPubKey is derived directly from
.** Feedback welcome. -Kalle. (*) Looks like you can simply use VerifyScript with a new signature checker class. (h/t Nicolas Dorier) (**) If is true, is the sighash, otherwise sighash=sha256d(message). _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --001a1143df5c79cc7005675c414c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you.=C2=A0

I can't really see from your proposal if you had though= t of this: A soft fork can make old nodes accept invalid message signatures= as valid. For example, a "signer" can use a witness version unkn= own to the verifier to fool the verifier. Witness version is detectable (ju= st reject unknown witness versions)=C2=A0 but there may be more subtle chan= ges. Segwit was not "detectable" in that way, for example.=C2=A0<= /div>

This is the reason why I= withdrew BIP120. If you have thought about the above, I'd be very inte= rested.=C2=A0

/Kalle=C2= =A0

Sent from my Sinclair ZX81

Den 14 mars 2018 16:10 skrev "Ka= rl 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 &<= br> witnessProgram container that can be serialized. This is passed out
from/into the signer/verifier.

RPC commands:

sign <address> <message> [<prehashed>=3Dfalse]

Generates a signature proof for <message> using the same method that<= br> would be used to spend coins sent to <address>.**

verify <address> <message> <proof> [<prehashed>=3Df= alse]

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, otherwis= e
sighash=3Dsha256d(message).
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a1143df5c79cc7005675c414c--