Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.178 as permitted sender)
	client-ip=209.85.213.178; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ig0-f178.google.com; 
MIME-Version: 1.0
Date: Mon, 13 Jan 2014 17:43:41 +0100
Message-ID: <CAPg+sBhdgVQvumL_r9thLD5wm7UOJx=2DE+01-T58HHdimvpXw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Bitcoin-development] Payment protocol and reliable Payment messages
Precedence: list

Hi all,

while thinking about what use cases the stealth addresses covers, in
particular in addition to the payment protocol, I found it useful to
bring this up again.

currently, BIP70 says for "payment_url": Secure (usually https)
location where a Payment message (see below) may be sent to obtain a
PaymentACK.

The fact that this is optional makes the "memo" and "refund" and
"merchant_data" fields in the Payment message useless, as merchants
cannot rely on it, thus need to provide an alternative, thus nobody
would have a use for trying to use the in-Payment versions. If we
truly want the use of this Payment being sent be optional, I'd vote to
get rid of these and just send the transaction.

In particular in the case of more anonymous senders, if the Payment
message isn't sent, it may result in funds being transferred without a
way to know who to refund it to if something goes wrong.

That would be a pity. I think having bi-directional communication in
the protocol is one of the nicest things the payment protocol can add.
I would prefer to at least formulate it in the BIP as "location where
a Payment message must be attempted to be sent to". In case it fails,
it should probably be stored in the client and retried later.

As an optimization (and I believe this is what Mike plans to implement
in BitcoinJ), if a payment_url is present, it should be encouraged to
only send the payment there, and not broadcast the transaction at all
on the P2P network (minimizing the risk that the transaction confirms
without the payment being received; it can't be guaranteed however).

-- 
Pieter