diff options
author | Ross Nicoll <jrn@jrn.me.uk> | 2015-07-22 18:18:45 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-22 17:18:47 +0000 |
commit | 8c60256a957c2dac3b6347bce013de6b5c008f7a (patch) | |
tree | 48a016a97c6cdb21ae5d33ec0a5d2241c3b2f4f3 | |
parent | a6b1fa14624476bf119a14fa8418b583e84884aa (diff) | |
download | pi-bitcoindev-8c60256a957c2dac3b6347bce013de6b5c008f7a.tar.gz pi-bitcoindev-8c60256a957c2dac3b6347bce013de6b5c008f7a.zip |
Re: [bitcoin-dev] Bitcoin Core and hard forks
-rw-r--r-- | 67/3ba4d7c594ffea82b62ee418fad761ec589b60 | 238 |
1 files changed, 238 insertions, 0 deletions
diff --git a/67/3ba4d7c594ffea82b62ee418fad761ec589b60 b/67/3ba4d7c594ffea82b62ee418fad761ec589b60 new file mode 100644 index 000000000..99539f49c --- /dev/null +++ b/67/3ba4d7c594ffea82b62ee418fad761ec589b60 @@ -0,0 +1,238 @@ +Return-Path: <jrn@jrn.me.uk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id C36A4504 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 Jul 2015 17:18:47 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com + [208.97.132.208]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id AAC2015A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 Jul 2015 17:18:46 +0000 (UTC) +Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) + by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 3C75D62606E + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 Jul 2015 10:18:46 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to + :references:from:message-id:date:mime-version:in-reply-to: + content-type; s=jrn.me.uk; bh=CTN0xNU5fvcOe3Q1xN21bKwngg8=; b=Ae + mQp8bxpUxkUJDa3sp2y41quEo/Xn+N7WkAGwXBxI4yUG9KJXkFmTeOwa9I2/gMdO + rCi6Y2gF5ql6qHGxwPHTvsDZUZYYFvgT0sftWlaQrQxg7rvW51Q7ERD/zg8jsSMW + RcB5AulT2VYplK5uKQv6xVXHnxjv8Li63pQWeu3e0= +Received: from [10.9.1.133] (unknown [89.238.129.18]) + (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) + (No client certificate requested) + (Authenticated sender: jrn@jrn.me.uk) + by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 8E96062606A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 22 Jul 2015 10:18:45 -0700 (PDT) +To: bitcoin-dev@lists.linuxfoundation.org +References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com> + <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com> +From: Ross Nicoll <jrn@jrn.me.uk> +Message-ID: <55AFD075.1000806@jrn.me.uk> +Date: Wed, 22 Jul 2015 18:18:45 +0100 +User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 + Thunderbird/38.1.0 +MIME-Version: 1.0 +In-Reply-To: <CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com> +Content-Type: multipart/alternative; + boundary="------------070905090506060105050601" +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham + version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 22 Jul 2015 17:18:47 -0000 + +This is a multi-part message in MIME format. +--------------070905090506060105050601 +Content-Type: text/plain; charset=windows-1252; format=flowed +Content-Transfer-Encoding: 7bit + +So, if consensus shouldn't really be between the developers (which is +fine), should we empower users to control consensus? I've been working +on a fork framework anyway, which can support reasonably arbitrary +consensus changes (currently against block height, but moving towards +block time). Theoretically it could be modified to load consensus +parameters (which block size would have to be added to) from disk at +startup, rather than having them hard-coded. + +Is that considered desirable? Will raise as a PR if so. If not, where do +we draw a line between developer and user consensus? + +Ross + +On 22/07/2015 17:52, Pieter Wuille via bitcoin-dev wrote: +> +> Hello all, +> +> I'd like to talk a bit about my view on the relation between the +> Bitcoin Core project, and the consensus rules of Bitcoin. +> +> I believe it is the responsibility of the maintainers/developers of +> Bitcoin Core to create software which helps guarantee the security and +> operation of the Bitcoin network. +> +> In addition to normal software maintenance, bug fixes and performance +> improvements, this includes DoS protection mechanism deemed necessary +> to keep the network operational. Sometimes, such (per-node +> configurable) policies have had economic impact, for example the dust +> rule. +> +> This also includes participating in discussions about consensus +> changes, but not the responsibility to decide on them - only to +> implement them when agreed upon. It would be irresponsible and +> dangerous to the network and thus the users of the software to risk +> forks, or to take a leading role in pushing dramatic changes. Bitcoin +> Core developers obviously have the ability to make any changes to the +> codebase or its releases, but it is still up to the community to +> choose to run that code. +> +> Some people have called the prospect of limited block space and the +> development of a fee market a change in policy compared to the past. I +> respectfully disagree with that. Bitcoin Core is not running the +> Bitcoin economy, and its developers have no authority to set its +> rules. Change in economics is always happening, and should be +> expected. Worse, intervening in consensus changes would make the +> ecosystem more dependent on the group taking that decision, not less. +> +> So to point out what I consider obvious: if Bitcoin requires central +> control over its rules by a group of developers, it is completely +> uninteresting to me. Consensus changes should be done using consensus, +> and the default in case of controversy is no change. +> +> === +> +> My personal opinion is that we - as a community - should indeed let a +> fee market develop, and rather sooner than later, and that "kicking +> the can down the road" is an incredibly dangerous precedent: if we are +> willing to go through the risk of a hard fork because of a fear of +> change of economics, then I believe that community is not ready to +> deal with change at all. And some change is inevitable, at any block +> size. Again, this does not mean the block size needs to be fixed +> forever, but its intent should be growing with the evolution of +> technology, not a panic reaction because a fear of change. +> +> But I am not in any position to force this view. I only hope that +> people don't think a fear of economic change is reason to give up +> consensus. +> +> -- +> Pieter +> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + +--------------070905090506060105050601 +Content-Type: text/html; charset=windows-1252 +Content-Transfer-Encoding: 7bit + +<html> + <head> + <meta content="text/html; charset=windows-1252" + http-equiv="Content-Type"> + </head> + <body bgcolor="#FFFFFF" text="#000000"> + So, if consensus shouldn't really be between the developers (which + is fine), should we empower users to control consensus? I've been + working on a fork framework anyway, which can support reasonably + arbitrary consensus changes (currently against block height, but + moving towards block time). Theoretically it could be modified to + load consensus parameters (which block size would have to be added + to) from disk at startup, rather than having them hard-coded.<br> + <br> + Is that considered desirable? Will raise as a PR if so. If not, + where do we draw a line between developer and user consensus?<br> + <br> + Ross<br> + <br> + <div class="moz-cite-prefix">On 22/07/2015 17:52, Pieter Wuille via + bitcoin-dev wrote:<br> + </div> + <blockquote +cite="mid:CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com" + type="cite"> + <p dir="ltr">Hello all,</p> + <p dir="ltr">I'd like to talk a bit about my view on the relation + between the Bitcoin Core project, and the consensus rules of + Bitcoin.</p> + <p dir="ltr">I believe it is the responsibility of the + maintainers/developers of Bitcoin Core to create software which + helps guarantee the security and operation of the Bitcoin + network.</p> + <p dir="ltr">In addition to normal software maintenance, bug fixes + and performance improvements, this includes DoS protection + mechanism deemed necessary to keep the network operational. + Sometimes, such (per-node configurable) policies have had + economic impact, for example the dust rule.</p> + <p dir="ltr">This also includes participating in discussions about + consensus changes, but not the responsibility to decide on them + - only to implement them when agreed upon. It would be + irresponsible and dangerous to the network and thus the users of + the software to risk forks, or to take a leading role in pushing + dramatic changes. Bitcoin Core developers obviously have the + ability to make any changes to the codebase or its releases, but + it is still up to the community to choose to run that code.</p> + <p dir="ltr">Some people have called the prospect of limited block + space and the development of a fee market a change in policy + compared to the past. I respectfully disagree with that. Bitcoin + Core is not running the Bitcoin economy, and its developers have + no authority to set its rules. Change in economics is always + happening, and should be expected. Worse, intervening in + consensus changes would make the ecosystem more dependent on the + group taking that decision, not less.</p> + <p dir="ltr">So to point out what I consider obvious: if Bitcoin + requires central control over its rules by a group of + developers, it is completely uninteresting to me. Consensus + changes should be done using consensus, and the default in case + of controversy is no change.</p> + <p dir="ltr">===</p> + <p dir="ltr">My personal opinion is that we - as a community - + should indeed let a fee market develop, and rather sooner than + later, and that "kicking the can down the road" is an incredibly + dangerous precedent: if we are willing to go through the risk of + a hard fork because of a fear of change of economics, then I + believe that community is not ready to deal with change at all. + And some change is inevitable, at any block size. Again, this + does not mean the block size needs to be fixed forever, but its + intent should be growing with the evolution of technology, not a + panic reaction because a fear of change.</p> + <p dir="ltr">But I am not in any position to force this view. I + only hope that people don't think a fear of economic change is + reason to give up consensus.</p> + <p dir="ltr">-- <br> + Pieter</p> + <br> + <fieldset class="mimeAttachmentHeader"></fieldset> + <br> + <pre wrap="">_______________________________________________ +bitcoin-dev mailing list +<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a> +<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a> +</pre> + </blockquote> + <br> + </body> +</html> + +--------------070905090506060105050601-- + |