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
|
Return-Path: <james.hilliard1@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3507E4A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 21:55:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f66.google.com (mail-oi0-f66.google.com
[209.85.218.66])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A4DE134
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 21:55:57 +0000 (UTC)
Received: by mail-oi0-f66.google.com with SMTP id m75so8828583oig.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 13:55:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=EZcls1fviydcB1GIQjuIHeTU/8+NvTw04Od0cRBocP4=;
b=BTYEnOIwcCVjtKcfmzh78iblZeAJBC6wDHCM2XFwfTa+u17tjQlXsoV4m3l9mT1hbT
cTuABkqSgNR82O28cyrBtZPsGP5NL0KLWXmZYD1n6ZhfuI/1hF8ji/Ki2JhtJtStY9uo
lFbVWWG0eXWmHvSvlnINxhfEUhue7V6PNCJ09ky5uhb4R7M8K1qWkv0vV2I5WJEVbjng
z/L2IK0sdzsJV6R3mLjmSF1CarPZB6crnRXiaX9yD8tCTLLjdru6GGYriyjQiS+GzIwC
14XMTvECIgru6nN3i+8b/leFLDDL17srlvCWkPa23Qb2IZR8gkGAzkzqYZj/tDyJojHy
oHJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=EZcls1fviydcB1GIQjuIHeTU/8+NvTw04Od0cRBocP4=;
b=gZqTNk6sfniLmAwaKiIP/E9PBY3awOnQYbfGOpcxqYKrqdl+q7FWfUmHzSEs+2+G63
L9+OKIk6zPDIM/xGBIKKV7OY90aWpxjo/C+NTM8RB0vdGcJuAZWHjG9DxSpM3FOukQgc
2jcPYwdWrIKM25MYOKNTxEvqvp2BXRKhJTPFcsYKm36Sk47yIKvzceLlEJKEXRGVl0bS
zzV4rMUiBg+Jl2FULLkXkeduYHeZmDs83crg86AIVifUwpogw9Mjwp0/NNXnF5MJ/pzL
BqyE9vC3mYFoG7F26duER971QwtoS0o07KthsO/LKgwY8fgdq8C7nP1BH5YqJRUmtcES
mRjA==
X-Gm-Message-State: AKaTC00cv9vQIycQj4rkCN/Tids3kfzB8zm/flsTMNysZX01M+UMICsH7xKpAeZMqMXVWARZKGX5jsERWkT/pw==
X-Received: by 10.202.8.205 with SMTP id 196mr47093517oii.13.1481493356714;
Sun, 11 Dec 2016 13:55:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.77.130 with HTTP; Sun, 11 Dec 2016 13:55:55 -0800 (PST)
In-Reply-To: <CAGCNRJqEVo6cMOLeENNue3=2mAHnWL2ViUKXVXAke_W0CXKKEg@mail.gmail.com>
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>
<CAGCNRJo_VE9nBhP=oY7hV0UJ-OSuTBxu+Tf28_utJW8qi7rzxg@mail.gmail.com>
<CADvTj4rC6OyCFCwpExRdRF_ZVU_ONjtb3PycR3T_fkm6d=b_Wg@mail.gmail.com>
<CAGCNRJqEVo6cMOLeENNue3=2mAHnWL2ViUKXVXAke_W0CXKKEg@mail.gmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Sun, 11 Dec 2016 15:55:55 -0600
Message-ID: <CADvTj4qSeASzHPNnFaBs8bAogDfLvnzLzgEPgbX0YX-VnN89aA@mail.gmail.com>
To: "t. khan" <teekhan42@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 11 Dec 2016 21:55:59 -0000
I think the main thing you're missing is that there will always be
transactions available to mine simply because demand for blockspace is
effectively unbounded as fees approach 0. Nodes generally have a
static mempool size and dynamic minrelaytxfee nowadays so as
transactions get mined lower fee transactions get accepted into the
mempool. An individual opting to not send a transaction would not make
the blocks smaller simply because there will always be other
transactions available(it would really only have an effect on the
transaction fees needed to get mined).
On Sun, Dec 11, 2016 at 3:40 PM, t. khan <teekhan42@gmail.com> wrote:
>
> On Sun, Dec 11, 2016 at 3:31 PM, James Hilliard <james.hilliard1@gmail.com>
> wrote:
>>
>> What's most likely to happen is miners will max out the blocks they
>> mine simply to try and get as many transaction fees as possible like
>> they are doing right now(there will be a backlog of transactions at
>> any block size). Having the block size double every year would likely
>> cause major problems and this proposal allows over a 7x increase it
>> seems.
>
>
> Block75 is not exponential scaling. It's true the max theoretical increase
> in the first year would be 7x, but the next year would be a max of 2x, and
> the next could only increase by 50% and so on.
>
> However, to reach the max in the first year: 1) ALL blocks would have to be
> 100% full and 2) transactions would have to increase at the same rate. We'd
> have to be doing 2.1 million transactions a day within a year to make that
> happen, and would therefore need blocks to be that big.
>
> Realistically, max block size will grow (and shrink) at a much slower rate
> ... even more so with SegWit.
>
>>
>> The main problem with this proposal I think is that users effectively
>>
>> have no way to stop the miners from increasing block size
>> continuously.
>
>
> Yes they could, simply by not sending transactions. Users don't care at all
> about block size. They just want their transactions to be fast and
> relatively cheap.
>
> -t.k.
|
