H= i,

I realized that there isn't= any way to ask for a signature (or to verify a message) as easily you ca= n do when requesting a payment using a bitcoin URI scheme (BIP0021).

I think a URI scheme to use the signing tools in bitc= oin core might be useful, and with a proper consensus it could become ava= ilable in most bitcoin clients who already support message signing/verify= ing and payment url (or QRCode) and enable new uses of bitcoin signatures= .

A way to gain proper c= onsensus is going through a BIP, so that's why I'm here: to present my id= ea publicly before going any further (draft BIP and reference implementat= ion).

Some thoughts

=C2=A0- like BIP0021: "Bitcoin clients MUST NOT act o= n URIs without getting the user's authorization." so signing requires the= user to manually approve the process

=C2=A0- it = could use the same URI scheme than BIP0021 with an additional parameter (= ex: signaction=3D<verify/sign>) or use another one like BIP121 (ex:= btcsig:)

PS : I'll also= post a topic in "Development & Technical Discussion" section on Bitc= ointalk
=C2=A0

Arth= ur Bouquet

------=_Part_862_559512907.1442257021-- 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 5D0F41018 for ; Mon, 14 Sep 2015 23:51:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5EE5814B for ; Mon, 14 Sep 2015 23:51:29 +0000 (UTC) Received: by lbbvu2 with SMTP id vu2so3599012lbb.0 for ; Mon, 14 Sep 2015 16:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2Z/IhbWy+SJELm4sV4zkTIwxSUDTGpvtrE5oUXmru5U=; b=MnmylPwRRxYE39sp0YK+hH1iAVjs42NA2b0URitrz3/VM4IlnMUhZZxkmaIDoTxTu2 zP+Dp90rKy0xVyf07APew+tSKd6iac9GJwuNjKfWYtt6XfaTpOuJ697Q8NfvLPIePzH7 I+TlXxggdJ2gcgtAYIHuezlr3X/WvkpqNYVfG4FieYEdgB/a3tOtD6w7edIIUrK1+5Ae HVwjtdeOqTQc1DHlha1yecbxq/1p5sva0M9F+bPCg1Gxudh4Hg03VIASTNE+Z6Y5rel4 8VCWEDB072c3oJXJSiJ/G6EuyQa+EKqtboVG64Cy4S7I9Qgv7Mg802AvYQk0sxUHA0JY 7S8g== MIME-Version: 1.0 X-Received: by 10.152.120.164 with SMTP id ld4mr17106018lab.84.1442274687603; Mon, 14 Sep 2015 16:51:27 -0700 (PDT) Received: by 10.112.167.103 with HTTP; Mon, 14 Sep 2015 16:51:27 -0700 (PDT) Received: by 10.112.167.103 with HTTP; Mon, 14 Sep 2015 16:51:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Sep 2015 00:51:27 +0100 Message-ID: From: Thomas Kerin To: "Arthur - bitcoin-fr.io" Content-Type: multipart/alternative; boundary=089e012291126c5d2d051fbdbe88 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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] 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: Mon, 14 Sep 2015 23:51:30 -0000 --089e012291126c5d2d051fbdbe88 Content-Type: text/plain; charset=UTF-8 I think it would be more akin to bip70. I have a similar proposal, largely already written up around this. I'm very interested in having this for multi signature wallets. On 14 Sep 2015 8:06 pm, "Arthur - bitcoin-fr.io via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > I realized that there isn't any way to ask for a signature (or to verify a > message) as easily you can do when requesting a payment using a bitcoin URI > scheme (BIP0021). > I think a URI scheme to use the signing tools in bitcoin core might be > useful, and with a proper consensus it could become available in most > bitcoin clients who already support message signing/verifying and payment > url (or QRCode) and enable new uses of bitcoin signatures. > A way to gain proper consensus is going through a BIP, so that's why I'm > here: to present my idea publicly before going any further (draft BIP and > reference implementation). > Some thoughts > - like BIP0021: "Bitcoin clients MUST NOT act on URIs without getting the > user's authorization." so signing requires the user to manually approve the > process > - it could use the same URI scheme than BIP0021 with an additional > parameter (ex: signaction=) or use another one like BIP121 > (ex: btcsig:) > PS : I'll also post a topic in "Development & Technical Discussion" > section on Bitcointalk > > -- > Arthur Bouquet > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --089e012291126c5d2d051fbdbe88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think it would be more akin to bip70. I have a similar pro= posal, largely already written up around this. I'm very interested in h= aving this for multi signature wallets.

On 14 Sep 2015 8:06 pm, "Arthur - bitcoin-fr.io via bitcoin-dev" <bitcoin-dev@lists.linux= foundation.org> wrote:

Hi,
I realized that there isn't any way to ask for= a signature (or to verify a message) as easily you can do when requesting = a payment using a bitcoin URI scheme (BIP0021).
I think a URI sch= eme to use the signing tools in bitcoin core might be useful, and with a pr= oper consensus it could become available in most bitcoin clients who alread= y support message signing/verifying and payment url (or QRCode) and enable = new uses of bitcoin signatures.
A way to gain proper c= onsensus is going through a BIP, so that's why I'm here: to present= my idea publicly before going any further (draft BIP and reference impleme= ntation).
Some thoughts
=C2=A0- like BIP0021= : "Bitcoin clients MUST NOT act on URIs without getting the user's= authorization." so signing requires the user to manually approve the = process
=C2=A0- it could use the same URI scheme than BIP0021 wit= h an additional parameter (ex: signaction=3D<verify/sign>) or use ano= ther one like BIP121 (ex: btcsig:)
PS : I'll also = post a topic in "Development & Technical Discussion" section = on Bitcointalk
=C2=A0
--
Arthur Bouquet
<= /div>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e012291126c5d2d051fbdbe88-- 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 A65DA1102 for ; Tue, 15 Sep 2015 04:04:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 48DC8136 for ; Tue, 15 Sep 2015 04:04:35 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 0D7EB10801D0; Tue, 15 Sep 2015 04:03:51 +0000 (UTC) X-Hashcash: 1:25:150915:bitcoin-dev@lists.linuxfoundation.org::3q83k9EM/N3jPnET:aXtj8 X-Hashcash: 1:25:150915:arthur@bitcoin-fr.io::8/NgUB4sc1cJB8/z:arJ2d From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, "Arthur - bitcoin-fr.io" Date: Tue, 15 Sep 2015 04:03:40 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.6-gentoo; KDE/4.14.8; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201509150403.40909.luke@dashjr.org> 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] 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 04:04:35 -0000 On Monday, September 14, 2015 6:57:01 PM Arthur - bitcoin-fr.io via bitcoin- dev wrote: > Hi,I realized that there isn't any way to ask for a signature (or to verify > a message) as easily you can do when requesting a payment using a bitcoin > URI scheme (BIP0021).I think a URI scheme to use the signing tools in > bitcoin core might be useful, and with a proper consensus it could become > available in most bitcoin clients who already support message > signing/verifying and payment url (or QRCode) and enable new uses of > bitcoin signatures.A way to gain proper consensus is going through a BIP, > so that's why I'm here: to present my idea publicly before going any > further (draft BIP and reference implementation).Some thoughts - like > BIP0021: "Bitcoin clients MUST NOT act on URIs without getting the user's > authorization." so signing requires the user to manually approve the > process - it could use the same URI scheme than BIP0021 with an additional > parameter (ex: signaction=) or use another one like BIP121 (ex: btcsig:)PS > : I'll also post a topic in "Development & Technical Discussion" section > on Bitcointalk --Arthur Bouquet I think probably the whole signed message thing needs to be rethought. The most common "uses" today seem to be insecure cases that it doesn't actually work in: people trying to prove ownership of bitcoins and/or that they sent bitcoins (current signed messages can do neither). Ideally, whatever the new method is should also avoid using the same key as for signing transactions, since the public key is technically private information. Furthermore, since addresses are semi-deprecated (by the payment protocol), I'm not sure it makes sense to do this without designing an entire authentication system, which may be rather complex. Luke 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 14ADC1248 for ; Tue, 15 Sep 2015 10:49:39 +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 5BCDC145 for ; Tue, 15 Sep 2015 10:49:38 +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 4CA2543092; Tue, 15 Sep 2015 12:49:36 +0200 (CEST) Mime-Version: 1.0 Date: Tue, 15 Sep 2015 10:49:36 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <15ce53e7feabef3c9a40c5d3df9ff283@rainloop.aaawop.com> X-Mailer: RainLoop/1.8.2.291 From: "Arthur - bitcoin-fr.io" To: "Luke Dashjr" , bitcoin-dev@lists.linuxfoundation.org In-Reply-To: <201509150403.40909.luke@dashjr.org> References: <201509150403.40909.luke@dashjr.org> 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 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 10:49:39 -0000 September 15 2015 6:04 AM, "Luke Dashjr" wrote:=0A> I t= hink probably the whole signed message thing needs to be rethought. The= =0A> most common "uses" today seem to be insecure cases that it doesn't a= ctually=0A> work in: people trying to prove ownership of bitcoins and/or = that they sent=0A> bitcoins (current signed messages can do neither). Ide= ally, whatever the new=0A> method is should also avoid using the same key= as for signing transactions,=0A> since the public key is technically pri= vate information. Furthermore, since=0A> addresses are semi-deprecated (b= y the payment protocol), I'm not sure it=0A> makes sense to do this witho= ut designing an entire authentication system,=0A> which may be rather com= plex.=0A> =0A> Luke=0A=0AMy proposal is about the current signing process= (which exists event it it's not perfect) but it could also work with a n= ew signing message system tomorrow. It more about give users an easier wa= y to access existing tools than the "sign message thing" itself.=0A=0ABTW= I'm aware of privacy issues, but could you elaborate on why the use case= your are referring to doesn't actually work?=0AHere are a use of bitcoin= signatures ( https://bitcointalk.org/index.php?topic=3D497545.0 ) to spe= ak about a real case.=0A=0A--=0AArthur 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 AD93C131F for ; Tue, 15 Sep 2015 12:10:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9B0739C for ; Tue, 15 Sep 2015 12:10:21 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 45AB01080051; Tue, 15 Sep 2015 12:08:59 +0000 (UTC) X-Hashcash: 1:25:150915:arthur@bitcoin-fr.io::vA0rRuq8rKpB5Ssk:bW3OB X-Hashcash: 1:25:150915:bitcoin-dev@lists.linuxfoundation.org::AKNNvw2gSwJz0S63:a5T/+ From: Luke Dashjr To: "Arthur - bitcoin-fr.io" Date: Tue, 15 Sep 2015 12:08:57 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.6-gentoo; KDE/4.14.8; x86_64; ; ) References: <201509150403.40909.luke@dashjr.org> <15ce53e7feabef3c9a40c5d3df9ff283@rainloop.aaawop.com> In-Reply-To: <15ce53e7feabef3c9a40c5d3df9ff283@rainloop.aaawop.com> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201509151208.58326.luke@dashjr.org> X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, 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 12:10:22 -0000 On Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote: > September 15 2015 6:04 AM, "Luke Dashjr" wrote: > > I think probably the whole signed message thing needs to be rethought. > > The most common "uses" today seem to be insecure cases that it doesn't > > actually work in: people trying to prove ownership of bitcoins and/or > > that they sent bitcoins (current signed messages can do neither). > > Ideally, whatever the new method is should also avoid using the same key > > as for signing transactions, since the public key is technically private > > information. Furthermore, since addresses are semi-deprecated (by the > > payment protocol), I'm not sure it makes sense to do this without > > designing an entire authentication system, which may be rather complex. > > > > Luke > > My proposal is about the current signing process (which exists event it > it's not perfect) but it could also work with a new signing message system > tomorrow. It more about give users an easier way to access existing tools > than the "sign message thing" itself. One of my concerns is that making the existing signatures even easier will cause incompatible uses to become more prolific and accepted, increasing the overall risk. Hence my recommendation to satisfy these clearly-existing use cases with a safe signature *first*. > BTW I'm aware of privacy issues, but could you elaborate on why the use > case your are referring to doesn't actually work? The signed message proves that the person who *receives* payment with the address agrees to a given message/contract. It is therefore appropriate and a best practice for web wallet providers (inherent problems with webwallets aside) to allow users to sign messages with their deposit addresses. When bitcoins are received by this address, the transaction creates a low-level UTXO representing the bitcoins *in the wallet*, but this UTXO is not associated with the address itself. Therefore, it is entirely possible that this UTXO remains unspent/valid on the blockchain even after the user in question has spent their entire balance at the webwallet and therefore such a signature proves only that they once received the payment, but *not* that they presently still have the bitcoins received. Furthermore, it is proper for the UTXO to be redeemed at a low-level by the wallet when an entirely unrelated user is sending a transaction. In such a circumstance, the original recipient of the bitcoins would still be able to sign a message, even though they have nothing to do with nor any right to the goods/services purchased with the transaction redeeming that UTXO. > Here are a use of > bitcoin signatures ( https://bitcointalk.org/index.php?topic=497545.0 ) to > speak about a real case. Yes, there are a few good use cases for the current signed messages, but they appear to be a minority at the moment. I suspect implementing any URI-based signing would actually make them more difficult as well, since it is additional code on the requester's part. Luke 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