Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-wg0-f53.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CA+8xBpcNd-s9S-zDGO6gGwnd1sFSUikH1fAnCUoG1WiL5kkmVg@mail.gmail.com>
References: <CA+8xBpc5CZ9Sx4MwPdeS0-5frnV9B+mJ5OwcPoUVrygTawiJBg@mail.gmail.com>
	<CANEZrP28Wf6RVOgd85COkE-vLdtCbyQYa0b9QvPFt9W1DzNJag@mail.gmail.com>
	<CA+8xBpcNd-s9S-zDGO6gGwnd1sFSUikH1fAnCUoG1WiL5kkmVg@mail.gmail.com>
Date: Sat, 14 Apr 2012 17:13:47 +0200
Message-ID: <CANEZrP33d9zHaf9A9+2BG-YHZEf_pA2SSTNL-_Ht4tT22qV6Xw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic
	behavior
Precedence: list

> So, to be specific... a A->B chain of transactions, that collectively
> meet the network's fee requirements?

Yes.

> Ideally the fee, if any, is market based and negotiated. Problem is... like
> democracy, no matter how ugly it is, people have trouble finding a
> better system :)

I think this is something we can explore over the coming years. I
favor having people commonly pass transactions around outside the
broadcast network with the transactions and their dependencies being
broadcast only when there's a lack of trust between recipient and
sender. The block chain is an optional service after all.

> Furthermore, many of these ideas -- like sending TX's directly to the
> merchant -- involve far more direct payee<->payer communication on the
> part of the wallet client than is currently envisioned

Yes, though it's worth remembering that the original Bitcoin design
did have participants communicate directly. When I talked with Satoshi
in 2009 he saw the pay-to-IP-address mode imagined as the normal way
to make payments, with pay-to-address being used as a kind of backup
for when the recipient was offline.

In the end that's not how things evolved, but it the pendulum could
easily swing back the other way.