Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.181 as permitted sender)
	client-ip=209.85.217.181; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f181.google.com; 
MIME-Version: 1.0
In-Reply-To: <CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
	<CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
	<CAN1xFdrGiWmn_EaBNMXXZAV38oeqP14YiMzMZQrkA+WL9QEMfA@mail.gmail.com>
	<CAAS2fgR5=nLTBQUBzjZQs91AVw5XSTiqe-KB_T9R9wKfBrOq6Q@mail.gmail.com>
	<CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
	<CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
	<CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com>
	<CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
Date: Wed, 13 Feb 2013 19:38:31 -0800
Message-ID: <CAAS2fgTNQZkUo3k4Uke7sLrZd1=o2TO1BLtdA6_Q7hUegHRQHQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Stephen Pair <stephen@bitpay.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule
 modifications into the block chain
Precedence: list

On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair <stephen@bitpay.com> wrote:
> One of the beauties of bitcoin is that the miners have a very strong ince=
ntive to distribute as widely and as quickly as possible the blocks they fi=
nd...they also have a very strong incentive to hear about the blocks that o=
thers find.  There will not be an issue with blocks being "jealously guarde=
d"

Then perhaps I totally misunderstood what you were suggesting.  I
believed you were saying blocksize would be controlled by people
having to pay to receive and pay to have blocks forwarded.

>(by which I mean the fee or cost associated with the bandwidth and validat=
ion that a transaction requires) with some amount of profit.  This means th=
at the relay node will not fetch and propagate those transactions whose fee=
 is too small (unless there was some other fee structure outside the miners=
 fee).

The only fee-or-cost they're worrying about is their own marginal
costs.  This says nothing about the externalized cost of the hundreds
of thousands of other nodes which also must validate the block they
produce, many of which are not miners=E2=80=94 if we are well distributed=
=E2=80=94 and
thus don't have any way to monetize fees.  And even if they are all
miners for some reason,  if these fees are paying the ever growing
validation/storage costs what expenditure is left for the proof of
work that makes Bitcoin resistant to reversal?

If the cost is soaked up by validation/forwarding then the capacity to
run a validating node ends up being the barrier to entry and
difficulty would be very low... which sounds fine until you realize
that an attacker doesn't have validation costs, and that selfish
("optimally rational") miners could just eschew validation (who cares
if you lose some blocks to invalidity if you're producing them so much
cheaper than the honest players?).

> It is good to be wary of these potential issues, but I don't see how the =
economics are likely to yield the outcome you fear.  And, really, there's n=
ot a lot that can be done to prevent economics from dictating the ultimate =
outcome.  In fact, what I write above is not so much about what I think *sh=
ould* be built, it's more about what I *predict* will be built.

What I want is for economics to dictate a positive outcome. They can
do this how the system is currently constructed where the economics of
using the system are clearly aligned with securing it.