summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Zander <tomz@freedommail.ch>2017-01-02 23:33:16 +0100
committerbitcoindev <bitcoindev@gnusha.org>2017-01-02 22:32:22 +0000
commit5794a12abf30a6a10fa86b699ec368b925548790 (patch)
tree0573a206c3f8bf3a7740048ddfe5a2019b0a8155
parent7d88fc5ad74ffdfbcb3abfd18451c25dd9821e01 (diff)
downloadpi-bitcoindev-5794a12abf30a6a10fa86b699ec368b925548790.tar.gz
pi-bitcoindev-5794a12abf30a6a10fa86b699ec368b925548790.zip
Re: [bitcoin-dev] BIP - 'Block75' - New algorithm
-rw-r--r--e7/49acca2df4ec554f78504fb66f3ffb7a5bdad5108
1 files changed, 108 insertions, 0 deletions
diff --git a/e7/49acca2df4ec554f78504fb66f3ffb7a5bdad5 b/e7/49acca2df4ec554f78504fb66f3ffb7a5bdad5
new file mode 100644
index 000000000..c933c70e4
--- /dev/null
+++ b/e7/49acca2df4ec554f78504fb66f3ffb7a5bdad5
@@ -0,0 +1,108 @@
+Return-Path: <tomz@freedommail.ch>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id ACCC79C
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 2 Jan 2017 22:32:22 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C88E217B
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 2 Jan 2017 22:32:21 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at kolabnow.com
+X-Spam-Score: -2.9
+X-Spam-Level:
+X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
+ autolearn=ham version=3.3.1
+Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101])
+ by mx-out01.mykolab.com (Postfix) with ESMTPS id 1485760201
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 2 Jan 2017 23:32:19 +0100 (CET)
+From: Tom Zander <tomz@freedommail.ch>
+To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Date: Mon, 02 Jan 2017 23:33:16 +0100
+Message-ID: <2491464.ujv6hLnuF3@cherry>
+In-Reply-To: <CAGCNRJpBMEha+cqXbgL6z9Fk5aoDOJF8tHu+XhYmMtgmdY2osw@mail.gmail.com>
+References: <CAGCNRJoN7u3yvzitH2KSmVty-p0tX9jxWLHPb8uO5CPZmxmoRg@mail.gmail.com>
+ <1944321.hguq3JoYe1@cherry>
+ <CAGCNRJpBMEha+cqXbgL6z9Fk5aoDOJF8tHu+XhYmMtgmdY2osw@mail.gmail.com>
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7Bit
+Content-Type: text/plain; charset="us-ascii"
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+X-Mailman-Approved-At: Tue, 03 Jan 2017 07:09:02 +0000
+Subject: Re: [bitcoin-dev] BIP - 'Block75' - New algorithm
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Protocol 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: Mon, 02 Jan 2017 22:32:22 -0000
+
+On Monday, 2 January 2017 16:05:58 CET t. khan wrote:
+> On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz@freedommail.ch> wrote:
+> > If the input of your math is completely free and human created, how does
+> > it follow that it was math that created it ?
+> > Why do you want it math created anyway?
+>
+> The beauty of math is that everyone on the planet agrees how it works.
+> Everything in Bitcoin is math, with the exception of the blocksize limit
+> (1MB) which was a stop-gap solution at the time.
+
+In actual fact the block size *is* set by miners, not math. And always has
+been.
+In your proposal the max blocksize continues to be set by miners as a
+secondary effect of them choosing the block size.
+
+Saying the max is actually math is painting an illusion that is rather thin
+and easy to see through because every single usecase for your suggestion
+starts with the choice of blocksize that a human makes. There is not really
+any other input except some rather simple algorithm.
+
+> > A maximum is needed, yes. But does it have to be part of the protocol?
+> > A simple policy which is set by node operators (reject block if greater
+> > than
+> > X bytes) will solve this just fine, no?
+>
+> No. That would be an epic disaster. There's no such thing as a "simple
+> policy" when humans are involved.
+
+This is ignoring history where miners have successfully set policy on block
+size for years now.
+
+> Obviously no one would agree on what X
+> bytes would be and you'd have some nodes rejecting blocks that others
+> already accepted.
+
+Not sure about your "obviously". I don't agree. In fact, there is plenty of
+reason to think it does work.
+
+Miners have always been the ones to decide on the block size, and they have
+always done this in a coordinated fashion. This is a natural consequence of
+the rather elegant (economic) design of Bitcoin.
+
+* Miners earn more fee-based income when they produce bigger blocks.
+* Miners take more risk of their blocks being orphaned with bigger blocks.
+* Miners want to avoid emptying the memory pool every block as that removes
+a total need for users to pay fees.
+* Miners want to make sure the mempool does not become backlogged because
+users that do not see their transactions confirmed will get disappointed and
+find other means to do payments. Which hurts the price and in effect hurts
+the miners income.
+
+This behaviour in block size means blocks will not get huge and they will
+not stay small either, because there are reasons for both. And so the size
+will be something in the middle.
+
+--
+Tom Zander
+Blog: https://zander.github.io
+Vlog: https://vimeo.com/channels/tomscryptochannel
+