From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U9PjU-0007EK-Bp for bitcoin-development@lists.sourceforge.net; Sun, 24 Feb 2013 00:46:24 +0000 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; Received: from outmail149078.authsmtp.net ([62.13.149.78]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1U9PjR-0004Vr-QF for bitcoin-development@lists.sourceforge.net; Sun, 24 Feb 2013 00:46:24 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r1O0kAxw084446 for ; Sun, 24 Feb 2013 00:46:10 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 r1O0k6F2054977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 24 Feb 2013 00:46:09 GMT Date: Sat, 23 Feb 2013 20:06:51 -0500 From: Peter Todd 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) X-Server-Quench: 948f2b83-7e1b-11e2-b5c5-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQF1 Jh0bXVBSFQZ4ARwL AhgUUhA8cANYeX5u ZEFqQHFbVVt/fUFi QwAWFBIGPmEWamAa VElfcE1RcgVMMBZB YgZ9BnsOfGJSZyh9 RlY+ZXU7YD4CbXwN GFxcdVtLHEoCQSgc QA9KBjAmGUlNTSE0 JB89YlsVH0tZPkg2 MFE7UE4VexgIEg1X GQlIASlYIVZJTC0w EQdLNQAA X-Authentic-SMTP: 61633532353630.1023: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 X-Headers-End: 1U9PjR-0004Vr-QF Subject: [Bitcoin-development] How small blocks make delibrate orphan mining costly X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 00:46:24 -0000 --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--