1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
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
|
