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

From: Gregory Maxwell <[email-masked]>
Date: Thu, 24 Apr 2014 01:19:20 -0700

On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn <[email-masked]> 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.