Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.42 as permitted sender)
	client-ip=74.125.82.42; envelope-from=gavinandresen@gmail.com;
	helo=mail-wg0-f42.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAPg+sBhb3WOYnWRc020QbGwE0W4XeWWmXXTqYyAqrtB7h0+b8A@mail.gmail.com>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
	<CAPg+sBhb3WOYnWRc020QbGwE0W4XeWWmXXTqYyAqrtB7h0+b8A@mail.gmail.com>
Date: Thu, 8 Aug 2013 07:10:05 +1000
Message-ID: <CABsx9T0o2BN+UyZt-TYcEXX_U0ztP3Rq3+arr_2C1MPEtU_dUg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
Precedence: list

RE: making the bitcoin address in the bitcoin: URI optional:

Ok, I'm convinced, sometimes merchants won't want or need backwards
compatibility and sometimes it won't make sense for them to put an
arbitrary bitcoin: address there.

RE: should the customer's machine not broadcast the transaction:

I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ?  The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.

I'd also like to hear from merchants: any issue with your payment
processing server having "broadcast transaction" functionality?

My biggest worry is that the payment protocol will not get wide
support if it is too hard to implement.

-- 
--
Gavin Andresen