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 DAF861025 for ; Thu, 15 Mar 2018 03:01:28 +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 105FD224 for ; Thu, 15 Mar 2018 03:01:27 +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 B3AAD14C0F2 for ; Thu, 15 Mar 2018 12:01:26 +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; 15 Mar 2018 12:01:26 +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 AAC964C072 for ; Thu, 15 Mar 2018 12:01:26 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw26.oz.hdemail.jp (ip-10-185-1-211.ap-northeast-1.compute.internal [10.185.1.211]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id A575114C0F2 for ; Thu, 15 Mar 2018 12:01:26 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from mail-qk0-f199.google.com (lb05.oz.hdemail.jp [54.238.57.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw26.oz.hdemail.jp (Postfix) with ESMTP id 35BBA148C12D for ; Thu, 15 Mar 2018 12:01:26 +0900 (JST) X-Received: by mail-qk0-f199.google.com with SMTP id u200so3512491qka.21 for ; Wed, 14 Mar 2018 20:01:26 -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:content-transfer-encoding; bh=CIUc28v/lvmhI2yXAva1xS2ZATFwISGD55Or8mfCU1o=; b=lXIigM7SoqvNhW06tIwOfNHmwOE4qkHks3aLaicFD7JWWJcTvkgXBcQrs5V1eGOMo7 vaZNaLaYpwWoWn6kZp1GUrlQ9vu9ANkjNned8aAUVrOfw2qS6QI/nO4j2NapzKif9Rl/ cT8ZhN+WbypRn6CIX6xs0Y0Fotocyf6yz8gbY5mx0t3Es3lAk/Tu0SJ/7FagSxUVii8t ANZEkQw+4TxnJQcZDQR0AJvyqbAdnLR77CRL/Cse098kUzwHRItoOkmYveIT8em5O53+ 3rdSz0a+PkpjceMSbqJHTgIyGTdf+6UtlB6XMliZT9zXq6xx4bg94/QXEF7MdIwf+IG2 LUvQ== X-Gm-Message-State: AElRT7GUqUEUYCLKfktMMdh1xZO5iTpQHGJ2NriqLGnokO0Jc+IP+md+ Ua3AXSuvafVtCHdcWyLpG+t64MZwHiXVIuibPAjjXTNSE/emKdJ90Ox3kv+BRFnhLpujq9zK/Hg vhspj8v0kOju0UHYHPtpsliEZcQQ4ZjWlbmEzdSdm+Ha5w96/4Vn/MnpM30NRjJOHWPZyvO+JkN HPMhnZ/VpKVKscm5mPhUp7K5IbpA1IPwDZ2VPysUu4jy8AxuFL+AV6S0bUerz5PSsGCO1z4uks+ aGRmnfRCve2SZBuJb8WjR/wRRcLq2zdPTBH+VrdgQlBcf1+uBSJAzJD3epop0G3KiBaBAojcHiZ dY8SfAIGP+UMyfBmAW8A8MNVpNM= X-Received: by 10.200.6.6 with SMTP id d6mr6628885qth.112.1521082884550; Wed, 14 Mar 2018 20:01:24 -0700 (PDT) X-Google-Smtp-Source: AG47ELvxvalg2ge55NcMM1l0G28vSbMNFvalwk2LeB6IPcJfbiidyIm4FZ//s7mQRDm3aIbrGCl+tuG8AGydXgcw8Ng= X-Received: by 10.200.6.6 with SMTP id d6mr6628862qth.112.1521082884220; Wed, 14 Mar 2018 20:01:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.12.176.3 with HTTP; Wed, 14 Mar 2018 20:01:03 -0700 (PDT) In-Reply-To: References: From: Karl Johan Alm Date: Wed, 14 Mar 2018 23:01:03 -0400 Message-ID: To: Kalle Rosenbaum Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-dev 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: Thu, 15 Mar 2018 03:01:29 -0000 On Wed, Mar 14, 2018 at 5:46 AM, Kalle Rosenbaum wrote= : > 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. I'm not sure I see the problem. The scriptPubKey is derived directly from the address in all cases, which means the unknown witness version would have to be committed to in the address itself. So yeah, I can make a P2SH address with a witness version > 0 and a to me unknown pubkey and then fool you into thinking I own it, but I don't really see why you'd ultimately care. In other words, if I can SPEND funds sent to that address today, I can prove that I can spend today, which is the purpose of the tool, I think. For the case where the witness version HAS been upgraded, the above still applies, but I'm not sure it's a big issue. And it doesn't really require an old node. I just need to set witness version > current witness version and the problem applies to all nodes. On Wed, Mar 14, 2018 at 8:36 AM, Luke Dashjr wrote: > I don't see a need for a new RPC interface, just a new signature format. All right. > Ideally, it should support not only just "proof I receive at this address= ", > but also "proof of funds" (as a separate feature) since this is a popular > misuse of the current message signing (which doesn't actually prove funds= at > all). To do this, it needs to be capable of signing for multiple inputs. I assume by inputs you mean addresses/keys. The address field could optionally be an array. That'd be enough? > Preferably, it should also avoid disclosing the public key for existing o= r > future UTXOs. But I don't think it's possible to avoid this without somet= hing > MAST-like first. Perhaps it can be a MAST upgrade later on, but the new > signature scheme should probably be designed with it in mind. I'd love to not have to reveal the public key, but I'm not sure how it would be done, even with MAST. On Wed, Mar 14, 2018 at 12:12 PM, Anthony Towns wrote: > Wouldn't it be sufficient for old nodes to check for standardness of the = spending script and report non-standard scripts as either invalid outright,= or at least highly questionable? That should prevent confusion as long as = soft forks are only making nonstandard behaviours invalid. That seems sensible to me. A warning would probably be useful, in case the verifier is running old software. -Kalle.