From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V4fr4-0004ZY-3u for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 23:30:54 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.174 as permitted sender) client-ip=209.85.212.174; envelope-from=ewillbefull@gmail.com; helo=mail-wi0-f174.google.com; Received: from mail-wi0-f174.google.com ([209.85.212.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V4fr2-0002gs-V7 for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 23:30:54 +0000 Received: by mail-wi0-f174.google.com with SMTP id j17so5575142wiw.13 for ; Wed, 31 Jul 2013 16:30:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.95.100 with SMTP id dj4mr31120471wjb.55.1375313446703; Wed, 31 Jul 2013 16:30:46 -0700 (PDT) Received: by 10.194.162.34 with HTTP; Wed, 31 Jul 2013 16:30:46 -0700 (PDT) In-Reply-To: References: <20130731084538.GL16713@giles.gnomon.org.uk> Date: Wed, 31 Jul 2013 17:30:46 -0600 Message-ID: From: E willbefull To: Gavin Andresen , bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=047d7bb03d5e721b0f04e2d71d03 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ewillbefull[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V4fr2-0002gs-V7 Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 23:30:54 -0000 --047d7bb03d5e721b0f04e2d71d03 Content-Type: text/plain; charset=ISO-8859-1 I think it's important to expect PaymentRequest-only bitcoin URIs in the future. Some types of payments (exotic transactions) may not make sense to have a single fallback address. Or, a page with a bitcoin URI link may be relying on a separate service provider to assemble the transaction. On Wed, Jul 31, 2013 at 5:33 AM, Gavin Andresen wrote: > On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami wrote: > > > > Is it envisaged to be possible/sensible to have a URI that is *only* a > > payment request? i.e. something like the following (although I'm not > > sure this is a valid URI): > > > > bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe > > I think we'll want a bitcoin address in there for a long time for > backwards compatibility. > > If web browser support for arbitrary MIME types is strong enough (I > haven't tested), then a payment request can be initiated with just an > anchor tag: > type="application/bitcoin-paymentrequest"> > > Doing it that way saves a http round-trip. > > -- > -- > Gavin Andresen > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --047d7bb03d5e721b0f04e2d71d03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think it's important to expect PaymentRequest-only b= itcoin URIs in the future. Some types of payments (exotic transactions) may= not make sense to have a single fallback address. Or, a page with a bitcoi= n URI link may be relying on a separate service provider to assemble the tr= ansaction.


On Wed,= Jul 31, 2013 at 5:33 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
On Wed, Jul 31, 2013 at 6:= 45 PM, Roy Badami <roy@gnomon.org.u= k> wrote:
>
> Is it envisaged to be possible/sensible to have a URI that is *only* a=
> payment request? =A0i.e. something like the following (although I'= m not
> sure this is a valid URI):
>
> bitcoin:?request=3Dhttps%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc= 2fbe

I think we'll want a bitcoin address in there for a long time for=
backwards compatibility.

If web browser support for arbitrary MIME types is strong enough (I
haven't tested), then a payment request can be initiated with just an anchor tag:
=A0 <a href=3D"https://merchant.com/pay.php?3D2a8628fc2fbe"=
type=3D"application/bitcoin-paymentrequest">

Doing it that way saves a http round-trip.

--
--
Gavin Andresen

---------------------------------------------------------------------------= ---
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D49501711&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--047d7bb03d5e721b0f04e2d71d03--