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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
Return-Path: <bip@mattwhitlock.name>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E8E53DC6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Aug 2015 23:42:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from resqmta-ch2-04v.sys.comcast.net
(resqmta-ch2-04v.sys.comcast.net [69.252.207.36])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 361EE11E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Aug 2015 23:42:06 +0000 (UTC)
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102])
by resqmta-ch2-04v.sys.comcast.net with comcast
id APht1r0022D5gil01Pi5Gh; Fri, 28 Aug 2015 23:42:05 +0000
Received: from crushinator.localnet
([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0])
by resomta-ch2-06v.sys.comcast.net with comcast
id APi31r00S4eLRLv01Pi4lX; Fri, 28 Aug 2015 23:42:04 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: bitcoin-dev@lists.linuxfoundation.org,
Mark Friedenbach <mark@friedenbach.org>, Chris Pacia <ctpacia@gmail.com>
Date: Fri, 28 Aug 2015 19:42:03 -0400
Message-ID: <12011991.1tUHVb58Dn@crushinator>
User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.11; x86_64; ; )
In-Reply-To: <CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
<CAB+qUq7ZzLHrFZ5FQazrcALA-b-jFh_bf-XX1GaJbGY1KQB5YA@mail.gmail.com>
<CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
s=q20140121; t=1440805325;
bh=iw220UHmet4eJ78fZCrSeqRgKmK01boKAJnCsdsTStI=;
h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version:
Content-Type;
b=QuJYRbRvLHlZZcW324NLWGpn3/ASAeS6W27J9iUHCuFx4md3zo2r1LAa3fFyCo/B4
BEFOFlFChjjwte2LHfvtfsn8vLkNSsMwMwW46OHMs0yDp4OwWbuwwBsS72j1MypeFg
PcdKl104dTvs5afg7zJbGMIhPdLKsAqBUCJSrtNY7KYM0FnCtIrDFr+WWiUlcJgl7J
5ImZsAWFjP+QyAibsrWhk4mfcnJbGNuPH/M7GZERQAFkRc1I3zu5kkn+GQYbkHUoqT
qxx7uhixVEcs8cyD/CWIQRgwFW0LZmSICiZs+FDrET8dMs1R0NEFalwncrDhjaQLd6
Zbo6m+9fAfE3g==
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
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm
(draft)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 28 Aug 2015 23:42:07 -0000
But that's not what this proposal does. They have to pay the difficulty=
penalty merely for a *chance* at later being able to mine larger block=
s.
Maybe this could be fixed by allowing miners to produce a larger-than-l=
imit block *immediately* by paying a difficulty penalty. Then we can si=
mply take the 80th-percentile block size in each 2016-block period as t=
he nominal block-size limit in the next period.
On Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev=
wrote:
> It is in their individual interests when the larger block that is all=
owed
> for them grants them more fees.
>=20
> On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> > When discussing this with Matt Whitlock earlier we basically conclu=
ded the
> > block size will never increase under this proposal do to a collecti=
ve
> > action problem. If a miner votes for an increase and nobody else do=
es, the
> > blocksize will not increase yet he will still have to pay the diffi=
culty
> > penalty.
> >
> > It may be in everyone's collective interest to raise the block size=
but
> > not their individual interest.
> > On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> With this proposal, how much would it cost a miner to include an '=
extra'
> >> 500-byte transaction if the average block size is 900K and it cost=
s the
> >> miner 20BTC in electricity/capital/etc to mine a block?
> >>
> >> If my understanding of the proposal is correct, it is:
> >>
> >> 500/900000 * 20 =3D 0.11111 BTC
> >>
> >> ... Or $2.50 at today's exchange rate.
> >>
> >> That seems excessive.
> >>
> >> --
> >> Gavin Andresen
> >>
> >>
> >> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> >> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >
> >> > This is the best proposal I've seen yet. Allow me to summarize:
> >> >
> >> > =E2=80=A2 It addresses the problem, in Jeff Garzik's BIP 100, of=
miners selling
> >> their block-size votes.
> >> > =E2=80=A2 It addresses the problem, in Gavin Andresen's BIP 101,=
of blindly
> >> trying to predict future market needs versus future technological
> >> capacities.
> >> > =E2=80=A2 It avoids a large step discontinuity in the block-size=
limit by
> >> starting with a 1-MB limit.
> >> > =E2=80=A2 It throttles changes to =C2=B110% every 2016 blocks.
> >> > =E2=80=A2 It imposes a tangible cost (higher difficulty) on mine=
rs who vote to
> >> raise the block-size limit.
> >> > =E2=80=A2 It avoids incentivizing miners to vote to lower the bl=
ock-size limit.
> >> >
> >> > However, this proposal currently fails to answer a very importan=
t
> >> question:
> >> >
> >> > =E2=80=A2 What is the mechanism for activation of the new consen=
sus rule? It is
> >> when a certain percentage of the blocks mined in a 2016-block reta=
rgeting
> >> period contain valid block-size votes?
> >> >
> >> >
> >> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.media=
wiki
> >> >
> >> >
> >> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev=
wrote:
> >> >> Pull request: https://github.com/bitcoin/bips/pull/187
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev@lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
|
