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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Return-Path: <tomh@thinlink.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EFE10B55
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Dec 2016 01:42:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb0-f173.google.com (mail-yb0-f173.google.com
[209.85.213.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 454F7DF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Dec 2016 01:42:58 +0000 (UTC)
Received: by mail-yb0-f173.google.com with SMTP id d59so53700267ybi.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Dec 2016 17:42:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=thinlink-com.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=G171N52CzUGVEglFggHmFCpkqCqK3zN4zmNNyeMwuwQ=;
b=vLmlXb4zXfvqe38KU/gIvJIMT3NrFsFCafgTd1YLsctjfC8jqjwwMNLwWf65FEzG7B
A0MTvR/bqL3J2SdGgEDIfUVEg5RXtPSA05pW4fIXCyVQBfpOIlLXHJgYq1xA61lgW/nc
JNwTM5wXj51albN5Bt0PKCzqUy46n5B3ZwTS4FsdfHaRRLpN2ThaIX1r7Qx8QsdRVirU
8LhSvspFWsUcnwPoPgoSRniJgDlsRJIjC/SEfGw3Nx9Z6Lm9n7QAS5p6Y+cRRN/doY0J
O2P11KdPyvt+EgDpfTWrBcV81uVARF4aJS4m+1IDzBCwuGe1Yy3YB3eyw0O2gttDjOjo
8pKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=G171N52CzUGVEglFggHmFCpkqCqK3zN4zmNNyeMwuwQ=;
b=hvg44H33hnbQ/OYtBcSl1U887M7Md9VcTIJrrNdNVCV0oCpbp6CJFYzIrY/ZwA3QgF
JFz7vip/OvbK6TiWZN4u7hsQ+EusUF6+/XOwbA+6NPZ8bPnP+qeQrOCoL5QQX8Ha27mD
fP27C/U+3oq3XihOcrWALw2Ay79bk3ZqnVzWvTbXb1lIIOFammoEEg9RsS+/VwfHKugK
HUZKunqhTbtieV+3ze7X9w5sYZWYAIoFpfbRkq9UXVpiEW04j16zuQdyKSVBTyFq3q8B
SuwnFCb+nDm1pIu0QYEkv++zG3EzlSegcXWorbyXeOq19c/l6F6QsMMhkj3zhkRaBf37
ZWRA==
X-Gm-Message-State: AIkVDXJ+xfBe1bEX6j0X+JSHH5dxQ+Z5BXPWGwwqyRXLCjYiwwph9iIAhn/ed2/ZHYN+3ZTF
X-Received: by 10.37.13.85 with SMTP id 82mr775066ybn.152.1482111776903;
Sun, 18 Dec 2016 17:42:56 -0800 (PST)
Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net.
[99.8.65.117]) by smtp.googlemail.com with ESMTPSA id
m8sm4772513ywh.30.2016.12.18.17.42.55
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 18 Dec 2016 17:42:55 -0800 (PST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
<CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
<d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
<CAAy62_KLAJ2OOv863HB4CzoAr7QOURRMFF2pH2pGUVQ9gMpecg@mail.gmail.com>
<8679ecea-b449-0f5a-d4d7-1f23ae6e29b2@sky-ip.org>
<CAH+Axy7H547kSh8y7OHzGRh0a=o0FDZ7N0eG3f5oAMTUGKJ-Fw@mail.gmail.com>
From: Tom Harding <tomh@thinlink.com>
Message-ID: <8e329517-4fdf-925a-4a23-98cdaf844b7c@thinlink.com>
Date: Sun, 18 Dec 2016 17:42:38 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAH+Axy7H547kSh8y7OHzGRh0a=o0FDZ7N0eG3f5oAMTUGKJ-Fw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 19 Dec 2016 01:51:45 +0000
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
(aka Block75)
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, 19 Dec 2016 01:42:59 -0000
James,
I share your conviction that miners are the natural gatekeepers of the
maximum block size.
The trouble I see with Block75 is that linear growth won't work forever.
Also, by reading actual and not miners' preferred max blocksize, this
proposal is sensitive to randomness in block timing and tx rate, and so
incentivizes miners to manipulate their block content unnaturally in
either the up or down direction to influence the calculation.
The EB/AD scheme of Bitcoin Unlimited recognizes implementation of the
max blocksize by miners, who publish their preferred max blocksize. But
it expects forks of unpredictable (probably short) length as network
behavior evolves.
BIP100, which also recognizes miner implementation of the max blocksize,
but has a change support threshold, and like Block75 defines the timing
of max blocksize increases, looks superior to me.
On 12/18/2016 1:53 PM, James MacWhyte via bitcoin-dev wrote:
> Hi All,
>
> I'm coming late to the party. I like the Block75 proposal.
>
> Multiple people have said miners would/could stuff blocks with
> insincere transactions to increase the block size, but it was never
> adequately explained what they would gain from this. If there aren't
> enough legitimate transactions to fill up the block, where do you plan
> to earn extra income once the block is bigger?
>
> Miners would be incentivized to include as many legitimate
> transactions as possible, but if propagation time is as big an issue
> as some of you have said it is, miners would also be incentivized to
> keep their blocks small enough to propagate. So why not give them the
> choice? Once the block size gets too big to propagate effectively,
> miners would be naturally incentivized to limit how much data they put
> in each block, finding the perfect balance.
>
> In my opinion, none of the downsides presented so far have been a good
> argument. Risk of a 51% attack is not unique to this proposal, saying
> "we could also do that with hardcoded limits" doesn't actually point
> out any problem with this proposal, and miners already have the
> ability to add or withhold transactions from their blocks.
>
> We trust our miners to serve us by acting in their own best interests,
> and this proposal simply gives them more options for doing that. If
> anyone can make a strong argument against that would earn top marks in
> a high school debate class, I'd love to hear it!
>
> James
>
|
