From: "Arthur - bitcoin-fr.io" <arthur@bitcoin-fr•io>
To: "Luke Dashjr" <luke@dashjr•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] URI scheme for signing and verifying messages
Date: Tue, 15 Sep 2015 13:21:56 +0000 [thread overview]
Message-ID: <e11d23636bee1bfc73e89b375c2844ac@rainloop.aaawop.com> (raw)
In-Reply-To: <201509151208.58326.luke@dashjr.org>
September 15 2015 2:10 PM, "Luke Dashjr" <luke@dashjr•org> wrote:
> On Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote:
>
>> September 15 2015 6:04 AM, "Luke Dashjr" <luke@dashjr•org> 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*.
>
Ideally yes, but it will take some time to make a new signature system.
I 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=1 to use the current system, default value is sigversion=2 which won't work until a new system is developped).
>> 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.
Ok,thx for your answer, I actually agree with you up until the last sentence. (if not I wouldn't propose this URI scheme :-)
--
Arthur
prev parent reply other threads:[~2015-09-15 13:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 18:57 Arthur - bitcoin-fr.io
2015-09-14 23:51 ` Thomas Kerin
2015-09-15 4:03 ` Luke Dashjr
2015-09-15 10:49 ` Arthur - bitcoin-fr.io
2015-09-15 12:08 ` Luke Dashjr
2015-09-15 13:21 ` Arthur - bitcoin-fr.io [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e11d23636bee1bfc73e89b375c2844ac@rainloop.aaawop.com \
--to=arthur@bitcoin-fr$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox