Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=mh.in.england@gmail.com;
	helo=mail-we0-f175.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <1339765735.31489.40.camel@bmthinkpad>
References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
	<1339765735.31489.40.camel@bmthinkpad>
Date: Fri, 15 Jun 2012 15:34:19 +0200
Message-ID: <CANEZrP2rZEwQqkceTN3yOqx_Mo_8gyRyBUgv8NnfKd8ZWGYzww@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Near-term scalability
Precedence: list

> The idea can be more generalized in that there are many cases where the
> generator of a transaction doesn't care about confirmation times, and
> would really be willing to make their transaction lower priority than
> other 0-fee transactions.

Just to be clear, I think this solution is a hack and don't support it
because it's yet another change of network rules. Some random people
will get whacked because of a heuristic "rule of thumb".

If it's implemented, SD could/would switch to fresh addresses and
nothing would have been achieved except making an already complex
system more complex.

I disagree with the notion that you need "less important than free".
If you care about the confirmation time of a transaction that was sent
to you and you need space in a limited resource, you can pay for it.
It's an auction like any other. Besides, the idea that transactions
are free today is just a psychological trick befitting governments but
not us - transactions are funded by aggressive hyperinflation. I would
never describe Bitcoin as a free system and I suggest nobody else does
either.

If grouped fee calculations are implemented, we can keep the nice
property that the person who cares about double spending risk pays the
fees, and if you assume most transactions are hub-and-spoke from
buyers to merchants, rather than a pure p2p graph, in practice it'll
work out to seeming free most of the time even if seen globally it
doesn't make much difference.

> My point was that the easiest way to do it would be to ship a pruned
> snapshot with Bitcoin, and such a system, while verifiable, would
> increase Bitocin's centralization.

I'm not sure why. If you want to audit everything from scratch, after
checking the code you could just blow away the included files and then
"-connect=archive.bitcoin.org" or something like that. After
rebuilding the chain from scratch, check the databases for consistency
with the included data.

It reduces the number of nodes with full copies of the block chain,
yes, but as long as there's at least one copy of the old data in an
accessible location new nodes can still bootstrap just fine.

I'm sure we can find organizations willing to host full chains for
people who want to rebuild their databases from scratch, given how
cheap disk space is.

> connect to, possibly complicating using Bitcoin for clients that either
> wish to run a full IBD or older clients which need a non-fClient node

Yes, but old nodes probably have a copy of the chain already, so it
wouldn't affect them. New blocks would still be fully distributed,
right?

The only case where it'd cause issues is if you install a fresh copy
of a very old node. Not a common occurrence, and those nodes will have
to wait until they find an archival node announcing itself. Those
nodes could be made to announce more frequently than normal, if need
be.