From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4ocS-0002qO-Da for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 11:01:28 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.174 as permitted sender) client-ip=209.85.220.174; envelope-from=tier.nolan@gmail.com; helo=mail-qk0-f174.google.com; Received: from mail-qk0-f174.google.com ([209.85.220.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4ocR-0000VS-3f for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 11:01:28 +0000 Received: by qkhu186 with SMTP id u186so6622659qkh.0 for ; Tue, 16 Jun 2015 04:01:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.48.79 with SMTP id w76mr33070867qkw.21.1434452481705; Tue, 16 Jun 2015 04:01:21 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Tue, 16 Jun 2015 04:01:21 -0700 (PDT) In-Reply-To: <557FB198.7080905@mail.bihthai.net> References: <557FB198.7080905@mail.bihthai.net> Date: Tue, 16 Jun 2015 12:01:21 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a114902249e8d4c0518a07eb6 X-Spam-Score: 0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z4ocR-0000VS-3f Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 11:01:28 -0000 --001a114902249e8d4c0518a07eb6 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 16, 2015 at 6:18 AM, Venzen 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. --001a114902249e8d4c0518a07eb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, 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 mai= n principle of open source software is that anyone can fork the code if the= y wish.=C2=A0 They don't do it very often, but they can.

<= div>This means that if a project dies, someone can take it over.=C2=A0 If s= ome of the devs want to take things in a different direction, they can.=C2= =A0 Users can decide which version they prefer.

The software itself is what is valuable.=C2=A0

In the case of bit= coin, the blockchain is also (very) valuable.=C2=A0 Simply splitting into t= wo projects is not possible for bitcoin.

Otherwise, the d= iscussion would have ended already, those who want a larger block would sim= ply 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 fo= r a hard fork would be a nice thing to have, but it is hard to have rules a= bout how to change fundamental rules.

I think using the s= oft fork rules (maybe with a higher threshold than 95%) plus a delay is a r= easonable compromise on hard fork rules.=C2=A0

Even then, it would = be nice to include users of the software too.=C2=A0 Peter Todd's sugges= tion of encoding a vote in transactions is a step in that direction (YES tr= ansactions in YES blocks and NO transactions in NO blocks).
= =C2=A0
Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
you cannot have it.

Nobody owns it, so the= re is no court of final appeal.=C2=A0

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

Maybe the sequence could be

version 3 blocks me= ans no opinion
version 4 blocks means NO to fork
version 5 blocks means YES to fork & YES transactions
v= ersion 6 blocks means YES to fork & NO transactions

<= /div>
Transaction matching rule:

version 1, 2, 3 tran= sactions means no opinion (can be in any block)
version 4 tra= nsactions means YES to fork (cannot be in version 6 blocks)
v= ersion 5 transactions means NO to fork (cannot be in version 5 blocks)
<= /div>

Rules
0) if 750 of the last 1000 blo= cks are version 5 or 6 blocks, tx matching rule activates for version 5 &am= p; 6 blocks
1) if 950 of the last 1000 blocks are version 5 o= r 6 blocks, then version 4 blocks are rejected
2) if 750 of t= he 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 tra= nsactions and 950 of the last 1000 are version 5 or 6, then the fork is acc= epted
4) 25,000 blocks after 3 is accepted, hard fork actuall= y takes effect

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

75% of miners can kill the f= ork by producing version 4 blocks, but 95% is needed for acceptance.=C2=A0 = Even then, transaction volume needs to support the fork.=C2=A0 I think 75% = is reasonable here.=C2=A0 (95% of miners and 75% of merchants/users is a pr= etty strong majority).
=C2=A0
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.
<= br>
They are still suggesting some kind of fork threshold process= (or at least that is what is being suggested)

If their s= ystem requires 95% miner approval, they aren't taking unilateral action= .=C2=A0 Miners are though if they vote in favour.
--001a114902249e8d4c0518a07eb6--