Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Gregory Maxwell <gmaxwell@gmail.com>]

On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn <mike@plan99.net> wrote:
> The complexity overhead is trivial - we already used coinbase scriptSigs for
> voting on P2SH, I'm sure it'll be used for voting on other things in future
> too.

We use coinbase sigs to gauge the safety of enforcing a soft fork
several times and not just for P2SH, to determine when enforcement of
it will be decisive and not result in risking a partition in the
network that might permit transaction reversals. This is not voting.
As a feature decision mechanism his is a rather coercive thing because
it gives the highest hash-power bidders control even when their
interests may be rather thoroughly unaligned with population that owns
and uses bitcoin in general, but as a plain indicator of when its safe
to enforce a new rule (same mechanism, different motivation— though a
point is that safe usage means using much more than 50% as the
threshold) it works pretty well.

> .... that's hugely complex and messy.

Yes, making really distributed systems that work in a complex world is
hard. It certantly would be /easier/ to just declare miners "trusted
parties" and require them to always collude to produce a single
consensus view of the world that is always honest and never
contradictory, except that it doesn't work. Because they aren't
individually trusted or even trustworthy.

> Why? Remember deleting coinbases with nothing more than a simple majority is
> already possible in the existing protocol and always has been.

Temporarily censoring transactions by orphaning otherwise valid blocks
that contain them for as long as you retain a majority is possible and
impossible to prevent in this architecture. This isn't the same as
deleting.  Deleting suggests the common misconception that a majority
of miners can do anything they want.