summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRoss Nicoll <jrn@jrn.me.uk>2015-07-22 18:18:45 +0100
committerbitcoindev <bitcoindev@gnusha.org>2015-07-22 17:18:47 +0000
commit8c60256a957c2dac3b6347bce013de6b5c008f7a (patch)
tree48a016a97c6cdb21ae5d33ec0a5d2241c3b2f4f3
parenta6b1fa14624476bf119a14fa8418b583e84884aa (diff)
downloadpi-bitcoindev-8c60256a957c2dac3b6347bce013de6b5c008f7a.tar.gz
pi-bitcoindev-8c60256a957c2dac3b6347bce013de6b5c008f7a.zip
Re: [bitcoin-dev] Bitcoin Core and hard forks
-rw-r--r--67/3ba4d7c594ffea82b62ee418fad761ec589b60238
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--
+