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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C30682C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Jan 2017 21:20:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 25160137
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Jan 2017 21:20:01 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 6AF9838A17C1;
Mon, 2 Jan 2017 21:19:23 +0000 (UTC)
X-Hashcash: 1:25:170102:bitcoin-dev@lists.linuxfoundation.org::VbkUzWENxZmEzCq8:a0Qdx
X-Hashcash: 1:25:170102:tomz@freedommail.ch::DVbmepu7nEAAyUpF:aa3R0
X-Hashcash: 1:25:170102:teekhan42@gmail.com::VkvP62H5aQy9lskj:b6hm7
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Tom Zander <tomz@freedommail.ch>,
"t. khan" <teekhan42@gmail.com>
Date: Mon, 2 Jan 2017 21:19:10 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.39-gentoo; KDE/4.14.24; x86_64; ; )
References: <CAGCNRJoN7u3yvzitH2KSmVty-p0tX9jxWLHPb8uO5CPZmxmoRg@mail.gmail.com>
<CAGCNRJp71NCxQ3jk4hu-kXF94RiqfeD=AVnxR37TrJ7bDG310w@mail.gmail.com>
<1944321.hguq3JoYe1@cherry>
In-Reply-To: <1944321.hguq3JoYe1@cherry>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201701022119.11115.luke@dashjr.org>
X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
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] 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 21:20:01 -0000
On Monday, January 02, 2017 8:35:40 PM Tom Zander via bitcoin-dev wrote:
> 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?
If you reject a block based on a particular condition, that is BY DEFINITION
part of the consensus protocol, and NOT a policy. The protocol is literally
the set of rules by which blocks are determined to be valid or invalid.
Policies are things that can vary node-to-node without affecting the validity
judgement of blocks.
On Monday, January 02, 2017 8:41:42 PM t. khan wrote:
> On Mon, Jan 2, 2017 at 3:04 PM, Luke Dashjr <luke@dashjr.org> wrote:
> > It would probably behave as an ever-increasing block size limit. Spam has
> > typically filled blocks to the max, and miners have stopped
> > self-enforcing reasonable limits.
>
> Using the growth rate over the last year as a model (
> https://blockchain.info/charts/avg-block-size?daysAverageString=14 ),
> Block75 would also have frequently decreased the limit. Though, yes, more
> transactions would equal larger blocks over time, but that's the entire
> point of this.
Then it doesn't solve the actual problems of either miner spam or growth in
resource requirements, which are the entire purpose of the block size limit.
> What is your definition of "spam"?
Anything that consumes more data than necessary to properly convey the
intended transfer of value (bitcoins) from one entity to another, including
all data that is not intended for such a purpose.
> > I doubt you'll get consensus for such a fundamentally broken proposal.
> > I certainly don't foresee any circumstance where I could reasonably
> > support it... The block size limit exists to restrict miners; it makes no
> > sense to put it in their control.
>
> Specifically, what is broken about it?
Putting group X in control of a limit that exists for the sole purpose of
restricting group X.
> There would still be a block size limit, it would just change slightly
> every two weeks. I agree that miners shouldn't have control of this, and
> Block75 doesn't give them any (at least none they can make a profit on).
It gives miners complete control over the limit. They can make blocks of any
size (within the current limit), thus triggering the conditions by which your
proposal would raise the limit further.
Luke
|
