Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.47 as permitted sender)
	client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f47.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <20121129170713.GD6368@giles.gnomon.org.uk>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<20121128233619.GA6368@giles.gnomon.org.uk>
	<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
	<20121129170713.GD6368@giles.gnomon.org.uk>
Date: Thu, 29 Nov 2012 18:31:24 +0100
Message-ID: <CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Roy Badami <roy@gnomon.org.uk>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
Precedence: list

> I'd still like to understand the rationale for having the merchant
> broadcast the transaction

There are several reasons for this:

1) P2P network sockets are a limited resource and bringing up
connections to the network, whilst somewhat fast today, is not
guaranteed to be fast in future. Passing transactions to the merchant
for broadcast reduces the load on the P2P nodes because lots of thin
clients aren't any longer connecting and disconnecting when sending.
They only need to talk to the network when the user has received
money.

2) Some users may not have network connectivity at all. For example,
this happens quite often whilst traveling at Bitcoin conferences ;)
The solution, which Andreas and I prototyped in Berlin together, is
for the buyer to communicate only with the seller which can be done
over Bluetooth or WiFi Direct or some other mobile radio protocol.
Again, send only, but for the common case where you load up your
wallet before setting out and then buy things, it works OK.

4) A longer term reason - in time, people may choose to not broadcast
transactions at all in some cases. I think how network speed will be
funded post-inflation is still an open question. Assuming the simplest
arrangement where users pay fees, getting transactions into the chain
has a cost. In cases where you trust the sender to not double spend on
you, you may keep a fee-less transaction around "in your pocket". Then
when it's your turn to pay, you use some unconfirmed transactions to
do so. People pass around longer and longer chains of un-broadcast
transactions until a payment crosses a trust boundary, at which point
the receiver adds on their own transaction that spends back to himself
but with a fee, and broadcasts them all together as a unit. In this
way only people who genuinely need to fear double spends pay for
security.