Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.178 as permitted sender)
	client-ip=209.85.223.178; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ie0-f178.google.com; 
MIME-Version: 1.0
In-Reply-To: <CABsx9T3BgjYnsi_UgRM7r0auUgA6BMFjEbSy8kNs_uLBiak8ow@mail.gmail.com>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
	<20130807214757.GA45156@giles.gnomon.org.uk>
	<CAPg+sBhTYTiW-7btDuNJKqv8nMiZTUzMU2c+N+YcUVf1EejNJA@mail.gmail.com>
	<20130807220358.GB45156@giles.gnomon.org.uk>
	<CABsx9T3BgjYnsi_UgRM7r0auUgA6BMFjEbSy8kNs_uLBiak8ow@mail.gmail.com>
Date: Thu, 8 Aug 2013 16:13:17 +0200
Message-ID: <CAPg+sBhjZCAZvaj5VjWaiQskv1fYb7iokWbJ+hdbLi893qVP=g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
Precedence: list

On Thu, Aug 8, 2013 at 2:48 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so
> the bitcoin address is optional:
>
> "If the "request" parameter is provided and backwards compatibility is
> not required, then the bitcoin address portion of the URI may be
> omitted (the URI will be of the form: bitcoin:?request=... )."

Sounds good.

I'd still like to see some effort to avoid losing metadata and
reducing the responsibilities of the sender.

I see there's an implementation difficulty in avoiding to broadcast a
transaction, but for example, if a payment_uri is specified, and it
cannot be contacted (at all), the transaction should fail. As soon as
you manage to connect, and have at least attempted to submit the
transaction, the merchant may have received it, and you want to mark
the coins spent, so store it after that point. But without such
protection we'll likely see a unnecessary payments happening without
metadata, when the payment server cannot be contacted for some reason.

Also, the receiver most certainly needs a P2P implementation (and
probably a strongly validating one) to verify incoming transactions,
so having him broadcast it shouldn't be hard. I don't think the client
should be required to stay online to broadcast at all, after a
paymentACK is received. The transaction arrived safely at that point.

-- 
Pieter