summaryrefslogtreecommitdiff
path: root/ba/5be3762e96e0a37ea1cec631acb685da071c4f
blob: f9f19ac59a41ec7f95ee96859679a5e8891ca01c (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
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
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@friedenbach.org>) id 1YrZlL-0007lD-Nb
	for bitcoin-development@lists.sourceforge.net;
	Sun, 10 May 2015 22:31:55 +0000
X-ACL-Warn: 
Received: from mail-ie0-f175.google.com ([209.85.223.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YrZlI-00024n-Hd
	for bitcoin-development@lists.sourceforge.net;
	Sun, 10 May 2015 22:31:55 +0000
Received: by iepj10 with SMTP id j10so92790527iep.0
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 10 May 2015 15:31:47 -0700 (PDT)
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:date
	:message-id:subject:from:to:cc:content-type;
	bh=lzEhH/dkb0fGi0fd/+lDv2o2bPG76nqqu4M3Xv+TuDA=;
	b=kcBVguZ68t+36tb1idvloA3jvx3Gs0dZXhghcKq6i7GLB4uYE+AKNwpfJhWKY6zg3K
	fnpKbPL3cAAOZYiiwtyOrK/lFwha5OqcfrGsgpYNNZ+8LImmUp2horYl+wxldieMQ0t7
	UO1tClOmooqlCkJGpJyP/upDYIT1DVa5Q9WXdL1Z/T4HLg1CO13quDQQ6uH+40OEP64y
	ebpiS6zb5/acblOvMuTzQ8Fl1SppPkLaeRyrIapUs7fWRXTa303LaKpGU0El73l3iQnW
	0xCkWNGNt0nfAGyTKqqdkR4D+6mO9YmqAF77vOlpwH54bA51jyFnT4BKg29tFTfUNIju
	tcVg==
X-Gm-Message-State: ALoCoQkzMxsaCFMPvAjRyB0mQHPHCocwrrTH4muavcP3JvVD+8k2dP4YT+ND1QZgTBeFK9RXPFLK
MIME-Version: 1.0
X-Received: by 10.50.143.38 with SMTP id sb6mr9692080igb.44.1431297107135;
	Sun, 10 May 2015 15:31:47 -0700 (PDT)
Received: by 10.107.25.203 with HTTP; Sun, 10 May 2015 15:31:46 -0700 (PDT)
X-Originating-IP: [172.56.39.36]
Received: by 10.107.25.203 with HTTP; Sun, 10 May 2015 15:31:46 -0700 (PDT)
In-Reply-To: <554FD237.2020009@electrum.org>
References: <16096345.A1MpJQQkRW@crushinator>
	<CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
	<554FD237.2020009@electrum.org>
Date: Sun, 10 May 2015 15:31:46 -0700
Message-ID: <CAOG=w-uZBGaprOV2ztYYNtiOSgxTpRUn_8zKTsNSkGAL1N1=nA@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Thomas Voegtlin <thomasv@electrum.org>
Content-Type: multipart/alternative; boundary=001a1135ffb8a3a9c00515c1d3a2
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YrZlI-00024n-Hd
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 10 May 2015 22:31:55 -0000

--001a1135ffb8a3a9c00515c1d3a2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm on my phone today so I'm somewhat constrained in my reply, but the key
takeaway is that the proposal is a mechanism for miners to trade subsidy
for the increased fees of a larger block. Necessarily it only makes sense
to do so when the marginal fee per KB exceeds the subsidy fee per KB. It
correspondingly makes sense to use a smaller block size if fees are less
than subsidy, but note that fees are not uniform and as the block shrinks
the marginal fee rate goes up..

Limits on both the relative and absolute amount a miner can trade subsidy
for block size prevent incentive edge cases as well as prevent a sharp
shock to the current fee-poor economy (by disallowing adjustment below 1MB)=
.

Also the identity transform was used only for didactic purposes. I fully
expect there to be other, more interesting functions to use.
On May 10, 2015 3:03 PM, "Thomas Voegtlin" <thomasv@electrum.org> wrote:

> Le 08/05/2015 22:33, Mark Friedenbach a =C3=A9crit :
>
> >   * For each block, the miner is allowed to select a different difficul=
ty
> > (nBits) within a certain range, e.g. +/- 25% of the expected difficulty=
,
> > and this miner-selected difficulty is used for the proof of work check.
> In
> > addition to adjusting the hashcash target, selecting a different
> difficulty
> > also raises or lowers the maximum block size for that block by a functi=
on
> > of the difference in difficulty. So increasing the difficulty of the
> block
> > by an additional 25% raises the block limit for that block from 100% of
> the
> > current limit to 125%, and lowering the difficulty by 10% would also
> lower
> > the maximum block size for that block from 100% to 90% of the current
> > limit. For simplicity I will assume a linear identity transform as the
> > function, but a quadratic or other function with compounding marginal
> cost
> > may be preferred.
> >
>
> Sorry but I fail to see how a linear identity transform between block
> size and difficulty would work.
>
> The miner's reward for finding a block is the sum of subsidy and fees:
>
>  R =3D S + F
>
> The probability that the miner will find a block over a time interval is
> inversely proportional to the difficulty D:
>
>  P =3D K / D
>
> where K is a constant that depends on the miner's hashrate. The expected
> reward of the miner is:
>
>  E =3D P * R
>
> Consider that the miner chooses a new difficulty:
>
>  D' =3D D(1 + x).
>
> With a linear identity transform between block size and difficulty, the
> miner will be allowed to collect fees from a block of size: S'=3DS(1+x)
>
> In the best case, collected will be proportional to block size:
>
>  F' =3D F(1+x)
>
> Thus we get:
>
>  E' =3D P' * R' =3D K/(D(1+x)) * (S + F(1+x))
>
>  E' =3D E - x/(1+x) * S * K / D
>
> So with this linear identity transform, increasing block size never
> increases the miners gain. As long as the subsidy exists, the best
> strategy for miners is to reduce block size (i.e. to choose x<0).
>
>
> -------------------------------------------------------------------------=
-----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a1135ffb8a3a9c00515c1d3a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I&#39;m on my phone today so I&#39;m somewhat constrained in=
 my reply, but the key takeaway is that the proposal is a mechanism for min=
ers to trade subsidy for the increased fees of a larger block. Necessarily =
it only makes sense to do so when the marginal fee per KB exceeds the subsi=
dy fee per KB. It correspondingly makes sense to use a smaller block size i=
f fees are less than subsidy, but note that fees are not uniform and as the=
 block shrinks the marginal fee rate goes up..</p>
<p dir=3D"ltr">Limits on both the relative and absolute amount a miner can =
trade subsidy for block size prevent incentive edge cases as well as preven=
t a sharp shock to the current fee-poor economy (by disallowing adjustment =
below 1MB).</p>
<p dir=3D"ltr">Also the identity transform was used only for didactic purpo=
ses. I fully expect there to be other, more interesting functions to use.</=
p>
<div class=3D"gmail_quote">On May 10, 2015 3:03 PM, &quot;Thomas Voegtlin&q=
uot; &lt;<a href=3D"mailto:thomasv@electrum.org">thomasv@electrum.org</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 08/05=
/2015 22:33, Mark Friedenbach a =C3=A9crit :<br>
<br>
&gt;=C2=A0 =C2=A0* For each block, the miner is allowed to select a differe=
nt difficulty<br>
&gt; (nBits) within a certain range, e.g. +/- 25% of the expected difficult=
y,<br>
&gt; and this miner-selected difficulty is used for the proof of work check=
. In<br>
&gt; addition to adjusting the hashcash target, selecting a different diffi=
culty<br>
&gt; also raises or lowers the maximum block size for that block by a funct=
ion<br>
&gt; of the difference in difficulty. So increasing the difficulty of the b=
lock<br>
&gt; by an additional 25% raises the block limit for that block from 100% o=
f the<br>
&gt; current limit to 125%, and lowering the difficulty by 10% would also l=
ower<br>
&gt; the maximum block size for that block from 100% to 90% of the current<=
br>
&gt; limit. For simplicity I will assume a linear identity transform as the=
<br>
&gt; function, but a quadratic or other function with compounding marginal =
cost<br>
&gt; may be preferred.<br>
&gt;<br>
<br>
Sorry but I fail to see how a linear identity transform between block<br>
size and difficulty would work.<br>
<br>
The miner&#39;s reward for finding a block is the sum of subsidy and fees:<=
br>
<br>
=C2=A0R =3D S + F<br>
<br>
The probability that the miner will find a block over a time interval is<br=
>
inversely proportional to the difficulty D:<br>
<br>
=C2=A0P =3D K / D<br>
<br>
where K is a constant that depends on the miner&#39;s hashrate. The expecte=
d<br>
reward of the miner is:<br>
<br>
=C2=A0E =3D P * R<br>
<br>
Consider that the miner chooses a new difficulty:<br>
<br>
=C2=A0D&#39; =3D D(1 + x).<br>
<br>
With a linear identity transform between block size and difficulty, the<br>
miner will be allowed to collect fees from a block of size: S&#39;=3DS(1+x)=
<br>
<br>
In the best case, collected will be proportional to block size:<br>
<br>
=C2=A0F&#39; =3D F(1+x)<br>
<br>
Thus we get:<br>
<br>
=C2=A0E&#39; =3D P&#39; * R&#39; =3D K/(D(1+x)) * (S + F(1+x))<br>
<br>
=C2=A0E&#39; =3D E - x/(1+x) * S * K / D<br>
<br>
So with this linear identity transform, increasing block size never<br>
increases the miners gain. As long as the subsidy exists, the best<br>
strategy for miners is to reduce block size (i.e. to choose x&lt;0).<br>
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>

--001a1135ffb8a3a9c00515c1d3a2--