From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
Date: Tue, 16 Jun 2015 12:01:21 +0100 [thread overview]
Message-ID: <CAE-z3OVGYmXJa3crAPX=PtJdmrCqq3T5akkxHbvMm2nCE4968w@mail.gmail.com> (raw)
In-Reply-To: <557FB198.7080905@mail.bihthai.net>
[-- 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 --]
next prev parent reply other threads:[~2015-06-16 11:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 0:04 Adam Back
2015-06-15 9:56 ` Mike Hearn
2015-06-15 18:03 ` Adam Back
2015-06-15 20:55 ` Mike Hearn
2015-06-15 21:56 ` Bryan Bishop
2015-06-15 22:17 ` Faiz Khan
2015-06-15 22:56 ` Brian Hoffman
2015-06-15 23:05 ` [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Raystonn .
2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine
2015-06-16 0:41 ` Mark Friedenbach
2015-06-16 1:17 ` Alex Morcos
2015-06-16 4:00 ` Aaron Voisine
2015-06-17 3:54 ` Peter Todd
2015-06-18 15:23 ` Jorge Timón
2015-06-16 11:29 ` Mike Hearn
2015-06-16 11:20 ` Mike Hearn
2015-06-16 12:33 ` Pindar Wong
2015-06-16 13:33 ` Peter Todd
2015-06-16 13:55 ` Pindar Wong
2015-06-17 3:59 ` Peter Todd
2015-06-25 6:43 ` [bitcoin-dev] " Pindar Wong
2015-06-26 19:30 ` Peter Todd
2015-06-15 22:54 ` odinn
2015-06-16 1:20 ` Eric Lombrozo
2015-06-16 5:18 ` Venzen
2015-06-16 6:09 ` Marcel Jamin
2015-06-16 9:21 ` Benjamin
2015-06-16 11:01 ` Tier Nolan [this message]
2015-06-17 3:52 ` Troy Benjegerdes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE-z3OVGYmXJa3crAPX=PtJdmrCqq3T5akkxHbvMm2nCE4968w@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox