Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.78 as permitted sender)
	client-ip=62.13.149.78; envelope-from=pete@petertodd.org;
	helo=outmail149078.authsmtp.net; 
Date: Sat, 23 Feb 2013 20:06:51 -0500
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20130224010651.GA22686@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Bitcoin-development] How small blocks make delibrate orphan mining
	costly
Precedence: list


--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

In the low-subsidy future fees will be the main source of income for
miners. Thus in some circumstances large miners may even have a reason
to delibrately try to mine a block that would orphan the current best
block. A simple example would be what would happen if a 1000BTC fee tx
was created, but more realistic examples would be just due to a large
number of tx's with decent fees.

However, with limited block-sizes such a strategy runs into a problem at
a point: you can't fit more tx's into your block so you can't increase
the fees collected by it even if you wanted too. Best strategy will soon
be to accept it and move on.


The second thing that could help defeat that strategy is if clients use
nLockTime by default. Clients should always create their transactions
with nLockTime set such that only the next block can include the
transaction, or if the transaction isn't time sensitive, possibly even
farther in the future.

Remember that to get ahead, you need to mine two blocks, and with
nLockTime the first block could only gain the transactions in the block
it orphans, so any further transactions could only go in the second.
With limited blocksizes that creates even more pressure in that the
block becomes full.

I don't see any reason why nLockTime in this fashion would harm clients,
so I think it's a perfectly reasonable thing to do and provides some
nice benefits down the road.

--=20
'peter'[:-1]@petertodd.org

--tThc/1wpZn/ma/RB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJRKWeqAAoJEH+rEUJn5PoEy9YH/1ft/3wdDtAduE1M7oatThhh
zY4jHnk4WdYBH3AYYJBAB71nRiG9UJNi0glMeFqFbZ7qqEJerZ+6zG/euwjejGtc
XlqIGRIY9VRK7RS2MH72TGwNb4LV2HkMIbCdl/Jdj0Norce+nf4jj/izgi4EXOSz
vznr/8DNhffF4P875yJ50//E1khmwcuUaPlSomdPjsrDUFaUMrY2+uvWKZAz74Sc
VMAhvf/UkDuxK8T4LruspJloNEx/0DV2MtvMN33ND3vGMNQuDFpecLuLNOXEBi0U
nTpO9rlKTnKGJwWyTWnuh1lVnNRjeK61hV43ISM3g43OiBVBBe/V0SKa1MIvrYw=
=/6qg
-----END PGP SIGNATURE-----

--tThc/1wpZn/ma/RB--