public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: thomasV1@gmx.de
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP 21 (modification BIP 20)
Date: Tue, 31 Jan 2012 07:54:44 +0100	[thread overview]
Message-ID: <20120131065444.29110@gmx.net> (raw)
In-Reply-To: <CAKm8k+1VFYSt7115KKGy5C7orFoU-N=8vfkQ_sc8onfQq96_Ww@mail.gmail.com>


> Regarding the idea of a signed URI, it is appealing, however, it may not
> work. If I understand it correctly, the main idea appears to be to protect
> a URI from malicious replacement 

No. The main idea is to protect the consumer against a malicious seller pretending that he has not been paid. Please read the forum.

> If a Bitcoin URI is served up from a
> trusted source (e.g. a merchant site over HTTPS) then there is no need for
> signing. It should be assumed that the merchant will offer a clean room
> payment area so that no untrusted JavaScript will creep into the final
> page
> and wreak havoc.
> 
> It would seem that in any situation where the attacker has complete
> control
> over the content of the URI they will be able to successfully swab it to
> match their own fraudulent address. Imagine attempting to protect a QR
> code
> posted against a pole attempting to get BTC donations for a charity. How
> long before that was replaced by a different version operated by the
> thieves with good signatures all round?
> 
> Of course, I may have misunderstood so I would welcome further discussion.

The bitcoin address that is used to sign URIs will establish the online reputation of the merchant. If a merchant has received a payment and pretends not to have received it, the signed URI will prove him wrong. 

In principle it would be possible to use HTTPS signatures for that purpose, but this is not really the way HTTPS is supposed to work, and it has disadvantages:
- HTTPS is not always available; there are other communication channels.
- A website, even a single page, may contain URIs posted by various merchants; we need to distinguish the identity of the merchant from the identity of the website.
- with signed URIs, a Bitcoin client can easily keep track of the signatures for all the payments it made. if we used the HTTPS signature of the webpage as receipts, then users would need to save them manually. To my knowledge, nobody does that.



> One field that the MultiBit team would like to add to the BIP 21 proposal
> is "expires" which would contain an ISO8601 formatted date/time in UTC
> (e.g. "2000-01-01T23:59:59Z"). This would allow merchants to issue Bitcoin
> URIs that would expose them to a currency/inventory risk for a defined
> period of time.

yes, that too. see my proposal here: https://bitcointalk.org/index.php?topic=60828.0;topicseen

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de



  parent reply	other threads:[~2012-01-31  6:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 18:50 [Bitcoin-development] BIP 21 (modification BIP 20) Gary Rowe
2012-01-30 18:56 ` Luke-Jr
2012-01-30 19:13   ` Gary Rowe
2012-01-30 19:17     ` Luke-Jr
2012-01-31  6:54 ` thomasV1 [this message]
2012-01-31 13:12   ` Gavin Andresen
2012-01-31 13:20     ` Cameron Garnham
  -- strict thread matches above, loose matches on Subject: below --
2012-01-31 10:39 [Bitcoin-development] BIP 21 (modification BIP 20)] Pieter Wuille
2012-01-30 18:07 [Bitcoin-development] BIP 21 (modification BIP 20) thomasV1
2012-01-30 18:44 ` Luke-Jr
2012-01-29 23:55 Amir Taaki
2012-01-30  9:13 ` Wladimir
2012-01-31  8:23 ` Andreas Schildbach
2012-01-31  8:35   ` Wladimir
2012-01-31 10:01     ` Gary Rowe
2012-01-31 10:22       ` Wladimir
2012-01-31 11:55         ` Andreas Schildbach
2012-01-31 12:03           ` Wladimir
2012-01-31 10:44       ` Pieter Wuille

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=20120131065444.29110@gmx.net \
    --to=thomasv1@gmx.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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