Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Tier Nolan <tier.nolan@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3798 bytes --]

On Tue, Jun 16, 2015 at 6:18 AM, Venzen <venzen@mail.bihthai.net> wrote:

> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus.


The main principle of open source software is that anyone can fork the code
if they wish.  They don't do it very often, but they can.

This means that if a project dies, someone can take it over.  If some of
the devs want to take things in a different direction, they can.  Users can
decide which version they prefer.

The software itself is what is valuable.

In the case of bitcoin, the blockchain is also (very) valuable.  Simply
splitting into two projects is not possible for bitcoin.

Otherwise, the discussion would have ended already, those who want a larger
block would simply create a fork of the software and create an alt chain.

The fundamental problem is that there is no clear way to make this decision
once and for all.

An agreed set of rules for a hard fork would be a nice thing to have, but
it is hard to have rules about how to change fundamental rules.

I think using the soft fork rules (maybe with a higher threshold than 95%)
plus a delay is a reasonable compromise on hard fork rules.

Even then, it would be nice to include users of the software too.  Peter
Todd's suggestion of encoding a vote in transactions is a step in that
direction (YES transactions in YES blocks and NO transactions in NO blocks).


> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.


Nobody owns it, so there is no court of final appeal.

If miners vote >95% for the fork, users could still refuse to accept the
change.

Maybe the sequence could be

version 3 blocks means no opinion
version 4 blocks means NO to fork
version 5 blocks means YES to fork & YES transactions
version 6 blocks means YES to fork & NO transactions

Transaction matching rule:

version 1, 2, 3 transactions means no opinion (can be in any block)
version 4 transactions means YES to fork (cannot be in version 6 blocks)
version 5 transactions means NO to fork (cannot be in version 5 blocks)

Rules
0) if 750 of the last 1000 blocks are version 5 or 6 blocks, tx matching
rule activates for version 5 & 6 blocks
1) if 950 of the last 1000 blocks are version 5 or 6 blocks, then version 4
blocks are rejected
2) if 750 of the last 1000 blocks are version 4 blocks, then version 5 & 6
blocks are rejected
3) if 750 of the last 1000 blocks are version 5 transactions and 950 of the
last 1000 are version 5 or 6, then the fork is accepted
4) 25,000 blocks after 3 is accepted, hard fork actually takes effect

Once miner acceptance is achieved, then only version 5 and 6 blocks are
allowed.  The split between version 5 and 6 blocks should be roughly in
proportion to the number of transactions of each kind produced.

75% of miners can kill the fork by producing version 4 blocks, but 95% is
needed for acceptance.  Even then, transaction volume needs to support the
fork.  I think 75% is reasonable here.  (95% of miners and 75% of
merchants/users is a pretty strong majority).


> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>

They are still suggesting some kind of fork threshold process (or at least
that is what is being suggested)

If their system requires 95% miner approval, they aren't taking unilateral
action.  Miners are though if they vote in favour.

[-- Attachment #2: Type: text/html, Size: 5034 bytes --]