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
|
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 <gavinandresen@gmail.com>) id 1VgkEq-0003qg-Vs
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Nov 2013 23:52:49 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.179 as permitted sender)
client-ip=209.85.212.179; envelope-from=gavinandresen@gmail.com;
helo=mail-wi0-f179.google.com;
Received: from mail-wi0-f179.google.com ([209.85.212.179])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VgkEp-00031E-PZ
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Nov 2013 23:52:48 +0000
Received: by mail-wi0-f179.google.com with SMTP id fb10so1622039wid.12
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Nov 2013 15:52:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.11.166 with SMTP id r6mr22737717wib.9.1384386761565;
Wed, 13 Nov 2013 15:52:41 -0800 (PST)
Received: by 10.194.156.163 with HTTP; Wed, 13 Nov 2013 15:52:41 -0800 (PST)
Date: Thu, 14 Nov 2013 09:52:41 +1000
Message-ID: <CABsx9T0ZchCDReG5W6_7r+BU=zH7aZ=JzV0G4LUs3BpW926d2w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c248f027af3804eb17a99f
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: blockchain.info]
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VgkEp-00031E-PZ
Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation
formula: f > bounty*fork_rate/average_blocksize
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: Wed, 13 Nov 2013 23:52:49 -0000
--001a11c248f027af3804eb17a99f
Content-Type: text/plain; charset=ISO-8859-1
Couple of thoughts:
RE: the marvelous coincidence that the average fee these days is very close
to the modeled minimum orphan cost:
Engineers tend to underestimate the power of markets, even inefficient
markets, to arrive at the 'correct' price. It would not surprise me at all
if the messy, chaotic inefficient market with tens of thousands of
individual decisions ("which mining pool should I join" and "how high
should my dice site set fees" and "how large should the minimum payout be"
and "should I make my blocks bigger or smaller") might arrive at the
'correct' price, even if NOBODY involved has any clue how or why it
happened.
Or it might just be a coincidence.
RE: orphan rate:
The network-wide orphan rate has been very steady apart from the March
blockchain fork. Kudos to Ben Reeves for keeping track of the data and
giving us a nice chart:
http://blockchain.info/charts/n-orphaned-blocks
RE: new block latency:
We should be able to reduce the size of new block announcements by about a
factor of ten with very little additional effort (transmit/relay as
"merkleblock" with full bloom filters-- the factor of 10 is because a
transaction id hash is 32 bytes, average transaction size is a few hundred
bytes).
Mining revenue is a fixed-size pie, so if EVERYBODY agreed to accept
(somewhat) higher orphan rates for more transaction volume then, in the
long run, there is no difference. Well, except that more transaction
volume means more utility for Bitcoin as a whole, so everybody should
benefit from a higher bitcoin price.
That's a classic free-rider problem, though-- a miner could defect to try
to get a lower orphan rate.
This is one of the reasons why I think relaying all blocks in a race is
probably the right thing to do; if a miner is mildly punished (by losing
the occasional block race) for creating blocks that don't include "enough"
already-relayed transactions, that is a strong incentive to go along with
whatever consensus has been established.
The same argument applies for a miner producing too-large blocks, or blocks
with lots of transactions that were never relayed across the network.
--
--
Gavin Andresen
--001a11c248f027af3804eb17a99f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Couple of thoughts:<br><div class=3D"gmail_quote"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">RE=
: the marvelous coincidence that the average fee these days is very close t=
o the modeled minimum orphan cost:</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Engineers t=
end to underestimate the power of markets, even inefficient markets, to arr=
ive at the 'correct' price. It would not surprise me at all if the =
messy, chaotic inefficient market with tens of thousands of individual deci=
sions ("which mining pool should I join" and "how high shoul=
d my dice site set fees" and "how large should the minimum payout=
be" and "should I make my blocks bigger or smaller") might =
arrive at the 'correct' price, even if NOBODY involved has any clue=
how or why it happened.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Or it might=
just be a coincidence.</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">RE: orphan rate:</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">
The network-wide orphan rate has been very steady apart from the March bloc=
kchain fork. Kudos to Ben Reeves for keeping track of the data and giving u=
s a nice chart:</div><div class=3D"gmail_extra">=A0=A0<a href=3D"http://blo=
ckchain.info/charts/n-orphaned-blocks" target=3D"_blank">http://blockchain.=
info/charts/n-orphaned-blocks</a></div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">RE: new blo=
ck latency:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">We should be able to reduce the size of new block announcements by ab=
out a factor of ten with very little additional effort (transmit/relay as &=
quot;merkleblock" with full bloom filters-- the factor of 10 is becaus=
e a transaction id hash is 32 bytes, average transaction size is a few hund=
red bytes).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Mining reve=
nue is a fixed-size pie, so if EVERYBODY agreed to accept (somewhat) higher=
orphan rates for more transaction volume then, in the long run, there is n=
o difference. =A0Well, except that more transaction volume means more utili=
ty for Bitcoin as a whole, so everybody should benefit from a higher bitcoi=
n price.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">That's =
a classic free-rider problem, though-- a miner could defect to try to get a=
lower orphan rate.</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">
This is one of the reasons why I think relaying all blocks in a race is pro=
bably the right thing to do; if a miner is mildly punished (by losing the o=
ccasional block race) for creating blocks that don't include "enou=
gh" already-relayed transactions, that is a strong incentive to go alo=
ng with whatever consensus has been established.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The same ar=
gument applies for a miner producing too-large blocks, or blocks with lots =
of transactions that were never relayed across the network.</div><span clas=
s=3D"HOEnZb"><font color=3D"#888888"><div class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">-- <br>--<br>Gavin Andresen<br>
</div></font></span></div>
</div><br>
</div>
--001a11c248f027af3804eb17a99f--
|
