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: <e11d23636bee1bfc73e89b375c2844ac@rainloop.aaawop.com>
From: "Arthur - bitcoin-fr.io" <arthur@bitcoin-fr.io>
To: "Luke Dashjr" <luke@dashjr.org>
In-Reply-To: <201509151208.58326.luke@dashjr.org>
References: <201509151208.58326.luke@dashjr.org>
	<201509150403.40909.luke@dashjr.org>
	<c5f5105e2d5b9cc1873f84cb0b172285@rainloop.aaawop.com>
	<15ce53e7feabef3c9a40c5d3df9ff283@rainloop.aaawop.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] URI scheme for signing and verifying messages
Precedence: list

September 15 2015 2:10 PM, "Luke Dashjr" <luke@dashjr.org> 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" <luke@dashjr.org> 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