summaryrefslogtreecommitdiff
path: root/d3/8ed8d3fac19dd3fe08df07e27074247fcd10e5
blob: 7da2fa9f1cd1da28d69f29e88a58004a45deba53 (plain)
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
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 828DF279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  2 Jan 2017 19:00:20 +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 6CCF2130
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  2 Jan 2017 19:00:19 +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 2F2C26031C;
	Mon,  2 Jan 2017 20:00:16 +0100 (CET)
From: Tom Zander <tomz@freedommail.ch>
To: "t. khan" <teekhan42@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Mon, 02 Jan 2017 20:01:11 +0100
Message-ID: <2273244.fZU5ULDz4l@cherry>
In-Reply-To: <CAGCNRJoN7u3yvzitH2KSmVty-p0tX9jxWLHPb8uO5CPZmxmoRg@mail.gmail.com>
References: <CAGCNRJoN7u3yvzitH2KSmVty-p0tX9jxWLHPb8uO5CPZmxmoRg@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: Mon, 02 Jan 2017 19:12:26 +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 19:00:20 -0000

On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote:
> Thoughts? 

This proposal doesn't change the block size, it only changes the maximum 
block size. Which is expected, nothing bad there.

The direct consequence of this, though is that the miners set the maximum 
block size. Because they decide on the actual created block size.

This leads me to the simple question why we can't just give the miners full 
control of the maximum block size directly?

The fact of the matter is that miners have for the full history of Bitcoin 
been able to set the block size, until they hit the 1MB limit.
And your proposal keeps that property, but why have a maximum in the 
protocol?
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel