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; 
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)
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)
Precedence: list


--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--