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 8F0A71384 for ; Tue, 15 Sep 2015 13:21:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.aaawop.com (area51.powaaa.com [62.210.66.225]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D34E8139 for ; Tue, 15 Sep 2015 13:21:57 +0000 (UTC) Received: from rainloop.aaawop.com (area51.powaaa.com [62.210.66.225]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: arthur@powaaa.com) by mail.aaawop.com (Postfix) with ESMTPSA id 3C78643093; Tue, 15 Sep 2015 15:21:56 +0200 (CEST) Mime-Version: 1.0 Date: Tue, 15 Sep 2015 13:21:56 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: RainLoop/1.8.2.291 From: "Arthur - bitcoin-fr.io" To: "Luke Dashjr" In-Reply-To: <201509151208.58326.luke@dashjr.org> References: <201509151208.58326.luke@dashjr.org> <201509150403.40909.luke@dashjr.org> <15ce53e7feabef3c9a40c5d3df9ff283@rainloop.aaawop.com> X-Virus-Scanned: clamav-milter 0.98.6 at area51 X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,URIBL_SBL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] URI scheme for signing and verifying messages X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 13:21:58 -0000 September 15 2015 2:10 PM, "Luke Dashjr" wrote:=0A> On = Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote:=0A>= =0A>> September 15 2015 6:04 AM, "Luke Dashjr" wrote:= =0A>>> I think probably the whole signed message thing needs to be rethou= ght.=0A>>> The most common "uses" today seem to be insecure cases that it= doesn't=0A>>> actually work in: people trying to prove ownership of bitc= oins and/or=0A>>> that they sent bitcoins (current signed messages can do= neither).=0A>>> Ideally, whatever the new method is should also avoid us= ing the same key=0A>>> as for signing transactions, since the public key = is technically private=0A>>> information. Furthermore, since addresses ar= e semi-deprecated (by the=0A>>> payment protocol), I'm not sure it makes = sense to do this without=0A>>> designing an entire authentication system,= which may be rather complex.=0A>>> =0A>>> Luke=0A>> =0A>> My proposal is= about the current signing process (which exists event it=0A>> it's not p= erfect) but it could also work with a new signing message system=0A>> tom= orrow. It more about give users an easier way to access existing tools=0A= >> than the "sign message thing" itself.=0A> =0A> One of my concerns is t= hat making the existing signatures even easier will=0A> cause incompatibl= e uses to become more prolific and accepted, increasing the=0A> overall r= isk. Hence my recommendation to satisfy these clearly-existing use=0A> ca= ses with a safe signature *first*.=0A> =0A=0AIdeally yes, but it will tak= e some time to make a new signature system.=0AI could also propose a URI = scheme that will work with a future implementation but be compatible with= the current one explaining its limitations (ex: sigversion=3D1 to use th= e current system, default value is sigversion=3D2 which won't work until = a new system is developped).=0A=0A>> BTW I'm aware of privacy issues, but= could you elaborate on why the use=0A>> case your are referring to doesn= 't actually work?=0A> =0A> The signed message proves that the person who = *receives* payment with the=0A> address agrees to a given message/contrac= t.=0A> =0A> It is therefore appropriate and a best practice for web walle= t providers=0A> (inherent problems with webwallets aside) to allow users = to sign messages=0A> with their deposit addresses. When bitcoins are rece= ived by this address, the=0A> transaction creates a low-level UTXO repres= enting the bitcoins *in the=0A> wallet*, but this UTXO is not associated = with the address itself. Therefore,=0A> it is entirely possible that this= UTXO remains unspent/valid on the=0A> blockchain even after the user in = question has spent their entire balance at=0A> the webwallet and therefor= e such a signature proves only that they once=0A> received the payment, b= ut *not* that they presently still have the bitcoins=0A> received.=0A> = =0A> Furthermore, it is proper for the UTXO to be redeemed at a low-level= by the=0A> wallet when an entirely unrelated user is sending a transacti= on. In such a=0A> circumstance, the original recipient of the bitcoins wo= uld still be able to=0A> sign a message, even though they have nothing to= do with nor any right to the=0A> goods/services purchased with the trans= action redeeming that UTXO.=0A> =0A>> Here are a use of=0A>> bitcoin sign= atures ( https://bitcointalk.org/index.php?topic=3D497545.0 ) to=0A>> spe= ak about a real case.=0A> =0A> Yes, there are a few good use cases for th= e current signed messages, but they=0A> appear to be a minority at the mo= ment. I suspect implementing any URI-based=0A> signing would actually mak= e them more difficult as well, since it is=0A> additional code on the req= uester's part.=0A=0AOk,thx for your answer, I actually agree with you up = until the last sentence. (if not I wouldn't propose this URI scheme :-)= =0A=0A--=0AArthur