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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VhH1f-0004eg-4j
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 10:53:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.112 as permitted sender)
client-ip=62.13.148.112; envelope-from=pete@petertodd.org;
helo=outmail148112.authsmtp.co.uk;
Received: from outmail148112.authsmtp.co.uk ([62.13.148.112])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VhH1d-0003rk-TQ for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 10:53:23 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id rAFAqj9O054639;
Fri, 15 Nov 2013 10:52:45 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rAFAqfgH036122
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 15 Nov 2013 10:52:43 GMT
Date: Fri, 15 Nov 2013 05:52:40 -0500
From: Peter Todd <pete@petertodd.org>
To: Michael Gronager <gronager@ceptacle.com>
Message-ID: <20131115105240.GD17034@savin>
References: <527B9F9B.4060808@ceptacle.com>
<20131107203123.GB3805@petertodd.org>
<527C0D12.8030905@ceptacle.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="SO98HVl1bnMOfKZd"
Content-Disposition: inline
In-Reply-To: <527C0D12.8030905@ceptacle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 0ea042a5-4de4-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwcUFloCAgsB AmUbWlReVV97XWc7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqcGpw R0hJKhlxcQREejBx ZE5nVz5bCRV6cUQs
R1NQQTgCeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4sGHYg Rx1KGi0zHEgMQ205
KxstKRYHHVQcekw0 PRM+WUN6ewMIAwtF FkpRAShfb1cMSjFj
BBlXFR5WDDxYTDwU HhovahtPHXQSXTAQ GFFMTQoGAD9EVy9T
AGYVTiwoAUNhO0Ut ei4ePkBZ
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 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: petertodd.org]
X-Headers-End: 1VhH1d-0003rk-TQ
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] On the optimal block size and why
transaction fees are 8 times too low (or transactions 8 times too big)
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: Fri, 15 Nov 2013 10:53:23 -0000
--SO98HVl1bnMOfKZd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Nov 07, 2013 at 10:58:42PM +0100, Michael Gronager wrote:
> > Q=3D0 -> f =3D 0.0033 BTC/kB Q=3D0.1 -> f =3D 0.0027 BTC/kB Q=3D0.2=
5 -> f
> > =3D 0.0018 BTC/kB Q=3D0.40 -> f =3D 0.0012 BTC/kB
>=20
> You second list of numbers is an unlikely extreme:
>=20
> > k =3D 1mS/kB
>=20
> The propagation latency in the network is more due to the block
> verification than due to its network (fiber) propagation time,
> bringing down the number of hops helps tremendously, so I agree that
> we can probably bring down k by a factor of ~10 (k=3D8-12) if we
> consider only pools directly connected. This should bring us close to
> break even with the current fee size, but we should really get some
> empirical data for interconnected large pools.
Well if large pools wanted it would be trivial for all of them to just
connect to each other... but my 25kB/s average data rate sure indicates
that they either aren't bothering, or aren't bothering to do that
correctly.
> However - important
> note - if you are a 1% miner - don't include transactions!
Which is an awful solution, although probably a correct one.... After
all, if you don't include transactions, you can start mining blocks
earlier too based on just the header.
> > Q=3D0 -> f =3D 0.000042 BTC/kB Q=3D0.1 -> f =3D 0.000034 BTC/kB Q=
=3D0.25
> > -> f =3D 0.000023 BTC/kB Q=3D0.40 -> f =3D 0.000015 BTC/kB
> >=20
>=20
> >=20
> > This problem is inherent to the fundemental design of Bitcoin:=20
> > regardless of what the blocksize is, or how fast the network is,
> > the current Bitcoin consensus protocol rewards larger mining pools
> > with lower costs per KB to include transactions.
>=20
> I don't see a problem of rewarding economy of scale, as long as the
> effect is not too grave (raising the min fee would actually make it
> more profitable for smaller miners).
That's a fundemental misunderstanding; there's no such thing as a min
fee.
As for economies of scale, the "product" we're paying miners for is
decentralization and resistance to 51% attack. If instead only get 51%
attack resistance, we're getting a bum deal. If that's all we're
getting, we don't actually have 51% resistance...
--=20
'peter'[:-1]@petertodd.org
00000000000000075ed91531e07d2045b5823da050fe373bde7bb363965e44ae
--SO98HVl1bnMOfKZd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJShfz4XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDBiNGZmNDljZDJjYWQ4NjVkNmNiY2E5OTgyODk4N2EwMmYz
ZDVmNDEwNjdlYWIwMGEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftRWQgAuGdbfZK4mPr4p/z2L78/NeDx
AvxpagwqbTkze/sDYqCYV/lixlCqIvq++uW6VYbNMig2PnJxqS8izJ2Azik2YU3S
+xoKjpTXSFJde4LT8QiAurnHHMeR+Ixprapc3Yrve/6vAfuYZFA4DbI7PO2upNOn
sl/jqqulFt0JqMNOHETKGDMWgOWqJ+njsWok7/9pIZW7wAquufOE6yRg6bYdOWeV
dggp+TZGdTlmovwlJnHTK91Gj8w52LbI4gGAkkuPy6S0YR583VEEnWiQsZrB7HsI
0gSVbi5r9ZDxYUXo/8thR9ZxWLy+Z6OkWYAEzCNV6VQp5WRdaWSuRnHsla234A==
=HoYV
-----END PGP SIGNATURE-----
--SO98HVl1bnMOfKZd--
|
