Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E68CD9AB for ; Fri, 13 Nov 2015 13:13:59 +0000 (UTC) X-Greylist: delayed 00:06:21 by SQLgrey-1.7.6 Received: from smx-7fb.smtp.startmail.com (smx-7fb.smtp.startmail.com [37.153.204.247]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3936168 for ; Fri, 13 Nov 2015 13:13:58 +0000 (UTC) Received: from smx-8a9.int1.startmail.com (smx-8a9.int1.startmail.com [10.1.137.139]) by smx-7fb.smtp.startmail.com (Postfix) with ESMTPS id 30C60B7A3A for ; Fri, 13 Nov 2015 14:07:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=startmail.com; s=dkim; t=1447420055; bh=eg+kqs0x+4G3yykFfffoSv6SDUl7SxXOTmdMA/lA7ps=; h=From:Subject:To:Date:From; b=ePQcXlJSyqjuOSKetofb238JiywjZuC3VtZsVSXevKhKPFhC2qLuWvGdirrM9sWDv 84KfXy4haQ7b/PqeAHOZtTlNdVowewuyJmNQOXwwkuPBvfB4HPvyP73/qxLjbRwoBT O9EyNONAqZiXNKq7m8+GkHo/+uBc+XXnjus0nvS4o7a1/qtH+OKXEximA293JUSTcL W/3CwBGEDBxq3X2fCH64mkdTADkmt7wqtXJAvfhgKn6nifkl9SLAehdpyuI/JoRyrd cOH/hgAm7+mb82hSJmfISXacuq+MMMO4/60j/wnuoyUJGZ56j2LhyCNfOF/Je+DHCd XWXZKyVvvwrlg== From: Erik X-Enigmail-Draft-Status: N1111 To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <5645E095.4050704@startmail.com> Date: Fri, 13 Nov 2015 14:07:33 +0100 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040402020902060600040507" X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 13 Nov 2015 15:23:51 +0000 Subject: [bitcoin-dev] BIP proposal - Max block size X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 13:14:00 -0000 This is a multi-part message in MIME format. --------------040402020902060600040507 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs. I was discussing the BIP proposals concerning max block size yesterday in the #bitcoin channel. I believe that BIP101 fully utilized will outperform consumer hardware soon or later and thereby centralize Bitcoin. I would therefore like to do a different proposal: Motivations: * BIP101 propose a doubling of the block max size every second year. This is very fast and may make the blockchain to grow faster than consumer hardware can cope with. * BIP102 is only a one-time solution, thus a new discussion of the next block max size will need to arise soon after it has been implemented. * BIP100 is an interesting solution in that the miners vote on the block max size. Althoigh it has several cons: 1) The block max size can never extend 32 MiB, even if we are so far in the future that it is need for larger blocks. 2) The block max size could reach a size of 32 MiB in a rather fast manner if pools vote for it, even though consumer hardware today isn't really ready for the growth it implicates. 3) Block max size can be pushed backwards, which will make TX fees higher, cause a lot of orphaned low-fee TXes. It could make some smaller mining pools dependant on lots of TXes with fees unprofitable. It is a serious flaw which could damage the trust of the network. * We does not for sure know how the evolution will proceed and if there will be storage for the larger block chain in the future. * There is a benefit of having a limit on the amount of transactions that will be processed in that the fees will rise. * Also there is a large problem if the fees rise too high because it will prevent mainstream users from using the network. There will also be a lot of orphan TXes which will cause uncertainity and fear of losses among users that don't know how bitcoin works. * Pruning is a problem if the blockchain grows too fast because some, although a few, nodes still must store the complete data -> centralizatio= n. Concepts: There is always a growth in the block max size. Never a decrease. The growth rate desicion should be in the hands of the miners. It's good to have limits on the block max size to keep back spam TXes. Use rules that makes a more smooth and predictable growth. Rules: 1) Main target growth is 2^(1/2) every second year, or a doubling of the block max size every four years. 2) The growth rate every second year will strictly be limited by the formula 2^2 > growth > linear growth. 3) The target growth could be modified with positive or negative votes, but it will not exceed the limits of 2) in any direction. Miners could also choose to not vote. 4) The linear y=3Dkx+m will be formed from the genesis block date with size 1 MiB (m) through the last retarget block date with current size. 5) Target growth is based on votes from the last 26280 blocks (half a yea= r). 6) Block max size grows at the same time as block difficulty retarget (2016 blocks) with the formula 2^(((1/2)+(1/2*amount positive votes)-(1/2*amount negative votes))/52). If the votes propose a lower growth than the linear, use the linear growth instead. Block size is floored to byte precision. 7) Amount positive/negative votes are calculated as following: number of votes, positive or negative / 26280. 8) When this rule are put in force, the block max size will immidiately be set to 4 MiB. Notes: * The number 52 came from 52 weeks/year * 2 years / 2 weeks. It measures number of week pairs or difficulty retargets per two years. * When there are no votes, the growth speed is set as main target as in 1). Also blocks mined before the implementation counts as blocks with no votes. Examples: * After implementation, the block max size will be 4 MiB. * At the first retarget, if no miner has left a vote, or equal number of votes exists for positive and negative side. Then the next block max size is 4096 KiB*2^((1/2)/52)=3D4123.3905 KiB (or exactly 4 222 351 bytes= ) * If the block max size is exactly 11 MiB, it has been exactly 10 years and 2 weeks since the genesis block, the next block is a retarget and every vote is negative. Then 2^(((1/2)-(1/2))/52) =3D 1. It is lower than= the linear, then the next block max size will follow the linear derived from: (11 MiB - 1 MiB) / (10.00 years) =3D 1 =3D k. Formula for a linear = is y=3Dkx+m. m is the genesis block max size in MiB. Then y =3D 1 * (10+1/52= ) + 1 =3D 11.019 [MiB] (or exactly 11 554 500 bytes) * If everyone in the past example continue voting negative for the next four years, then the block max size will then be y =3D 1*14 + 1 =3D 15 [M= iB]. * If the block max size was 10 MiB four years ago and every miner instead has put positive votes into the block chain since 4.5 years, then the block max size now is 10 MiB * 2^( ((1/2+1/2)/(52)) * 2) =3D 10 MiB * 4 =3D 40 MiB * If there was 2628 negative votes and 5256 positive votes in the last 26280 blocks, then the formula will look like: size*2^(((1/2)+(1/2*0.2)-(1/2*0.1))/52) Pros: Provides a long term solution that give opportunities to the network to itself cope with the actual state and hardware limits of the future network. No need to make a hard fork to adapt to other growth rates within this proposal's limits. Provides a smooth growth rate based on a large consensus, thus making the growth for the near future almost predictable. No big jumps in block max size provides stability to the network. Miners can choose pools that votes in a way that conforms to the miners interest. Eliminates fluctuating block size as could happen with BIP100 proposal. Cons: A few single, large entities could either vote for smaller growth of blocks for a long time, causing TX congestion and mistrust in the bitcoin network. On the contrary they could vote for a larger growth of blocks, causing the blockchain to be too large for consumer hardware. It will then result in fewer nodes and in worst cases closing of small pools. These cases seems to be extremely unlikely partly because of the time and mining power that will be needed, partly also because of limits in how much the votes can adjust the growth rate. It would therefore not pose a large risk. Sincerely, Erik Fors -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWReCVAAoJEJ51csApon2oLBgP/jn7mL5AzvU7/PCeAD39Kmc3 IsgFwh9LrHin/SaerPebusRGbjKXezP86kbiQVGEsSu3K3BxUAf9O09UoQiWECoc g2EOw5E1XrtzBopxYTO06daM/2CqDydpLVIVv6NwwLMpXKvmbixdqaD6vOKfzhNF 1B5tmg9Vh1zqEkBj7exnuypagG/3llkCt3DRb0+siVzkIM/O9GzgHbGtt8rtDEnH XHIhwLw+ySGuHg6hRhLo3uHs3gCUQmarxx1AoqR6AyvzgR6TGhJcy22vXct7QK5G B2K4+JseyVD0bvkBeIpjuqJpGoCq4lmNu/AmI/nQ82TmqqzvOBi/ljFF/Q+HArjZ UQO6p28lE7rmXf80GB6L117QLHktA5CdY++vW4Gwz3KDYEafs6H3CptvSmj9JbQz SVAt/eVvvdnVkRcYw++b0WrRuOS3Z+105QIX4yqt0Kyghr87LQ76LXnZHPMKZeHt IRX3wv7ZFqrJEpmGrTK4ZMZUAPVpkGe0kPms5kLHjEtjU92rvZJA726JJFoaAv5S rFDiGUupLvHttZLTYfTdyFhCo6ZStOI095qDZ69awVCLMmYpC9aR/tjQ5zMu5eNS y4hQdrX0Z4sdrJ2mTB+OXO7broLDn2G9dIqfpZwcIU493ljcXk/Uma4lj3oDrGTA oc5Q5ie/OVUclWB6GIho =3DcocM -----END PGP SIGNATURE----- --------------040402020902060600040507 Content-Type: application/pgp-keys; name="0x29A27DA8.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x29A27DA8.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFQlrIUBEADAv1PfCV1G1R4S4Q3dqSCC40BUvwsHLNAJBsfMU7XLtNU1u8YI 0AUrLoN17SEXSpSQ3jcGPkn558uSbJMlEfeEqQ6FKWNkpZz8XLiT0ILb8800PCXj 6+Ka9zfa30X/RwSqUWNcbMyaZqUcwnehcj2KamQDGTEH8IJQx1DAUEENdvkOvSCr E9AEO+kVxwJd9u0Buv5AetDtVRYZBdadllH1xDuzAwQRfN7Sprq8gBOT2Y+ZKc/z UKNfusrfZuA/p4wJDXt2zUwh9vY7JqwjUpsyWvRzSHYi0OycJMWPVQPRW16yTrr0 iUaAcLTrL4aow0oH/MfOvF+15yldYj63WQ5RTUCy4s5b98w7vFlCSRax6xcmu3dk cfm31us0gWNpyJpllbzHcsvozoZAbwgTQHt1WIucKXnNHNugwbysbubpUtZiykAF z6wOz82/R6E6QZRxRqgaqlLoY2Ls3cVuKHRSDeiiHcwpHymmZw+VFLzEGw6cURY+ tfnqJo9Z836pmLNwtqCd3d4q3UWKe5EG687vS9Ti6wLB6tcSuPG4Z/nFjq3JLA9Q 3plc7Q1wycq1jXZYhYE/KW+9z84ajwxA50i+TFece5VITxrpLopdGmcBYJl/rm5i R9WkD7pP/5PiZvKWpbaf4OiDGmxodwK9CvSWrYQbpx3LXNv6gbmtMpebMQARAQAB tB5FcmlrIDxlcmlrLmZvcnNAc3RhcnRtYWlsLmNvbT6JAj4EEwECACgFAlQlrIUC GwMFCQlmNtsGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJ51csApon2o9ZMQ ALlqC8r8/QVBEr9csCUH/XycjppLXYl/noObJP1/sEZMmHCAQQRppgk1koQA3ARo +ZW3PnCe1EcqbFBVsnptMsbtwJKT98n6BufwdZvnzV3uI4Qu7TTfHFlSqFPrRgLo TrfvEvVQQ7UwKGJheuEz+GQMdBq75Vvo/LKtVaetkzZdyB+HzwOauMvObTrnZBox ZWQYlPT18iUUNmV8AADC2QJNYcy6L+aU/whxWjMWJNdDesSpgZEdRsh5EVS552eP 7rzz9Ck+4yLzuqkEvcXiIdsQdxmMKx1PtNkIFRi9yEg3VuFsUDPuPBQ3GbZWhffR kyaZdkfc9r2b3PE27d+NZJYSFsmJk4tQEY00e+ld3OCcfhnWYcW/wirN24ORMTcB 64irT1h024xX2Fy2mHpeE/aYYsqpjMpGh+pdojPwxWvWVdNYiRMiaU82qYtos7QQ rKgcK6sLM65a9iDIPZDFSHpXauaE6L2aaiKaxXFzwf8LLLZNI9O3nlMLc5Nbus6y mFyutHmA6GZAhDq4r7PUH5KtPYCo8zpwwPueMHcqVTFD05FXZ0/7eFNsMKmqJqHk UmChg8tM6l2eEHlyHv0/vvyoP/WiYdwXF/3o/pvZB8c7TM2JyxhOtHDEZMm7dR2/ GXBo5kHV15cIDqCBcmzZ8QGvAY0JWMDeamqIbEcvEypSuQINBFQlrIUBEAC+wgEf cH8KnAnAc+TLwiXKm3PxUJcZCKiFoBAumpCWn4rLwI0WZbk0PNGfBkivXb6UQBu1 VyTGIxysGDUnw/O+OUyeMAZV8ojF0A3bT2Hx2v1WL69WsExorVbzbvsOiPcnvX3R xNrEDwlCbHLUNe1TnzMtmzNJyOQ36eQUXxLx/GNLa9sK1QCWv2MIpImmTejQCUWK JUqbvevnWiBsS1/37c1dMUtnJG+pU+FDmUCqKLGqImDM3VawIX1Rj+izm8+tjoO5 4Q+6HrexQGjp16Jkm+4XpV7kHEwc3/d+IeYxQy8e50rl+Pm7TkqJ7P5hFpjhgAP2 OOx+2yAHXs087w5S899GrkZeF9wG+0yScypjfxPmoFAwBxc/LsALYUYaAP2lbkyY AQ0dFTFxq4JPoakQtpXIDgxN71fIHzDd6vxysIlpOZ57GDzf7p5LoL+ULClmepjR a9JFCkL8ptWtCHa/mhCrMQ1nt/Y+rANk/VtoVkIMX+Fnfl3osA1/Dn9XIvXsQm+C JyMVpWJ0HBCJrMbIh7pJgMhtOfMgIKL4TRVU9BQdGH8ie+GS/VnPTraljlbRozU8 YLCScG/Z/cp0Yv3/O73UXUep+MvZBWqtfdEtaytTWXpsBTIXyLKHQXOniAQX0ZwN yE2ZcmSsfny/Ef984ttS+OAvL39MfhSlno4xjwARAQABiQIlBBgBAgAPBQJUJayF AhsMBQkJZjbbAAoJEJ51csApon2ogvQP/1IRXyEOkc7GjBIhDB5RRsVSxfGqwsxe 7oEfXb0Y9frZtiNnfhKd/AbRC8ir+Rz6vDNbeD89cvG8O0bfUxADF3XVtPu9wCBf WCeMjjylBSZam1jz7N5VM1wOnzaZu2XrME3uXAv+99ZcttysrkSCQRbtzxv7ur3t dx09EZOnj0Z9IRbOt/AUAxAhCoDtAcxceCeHXi7kQAdANzczOvnXKxFSjzkzmbbk 2mGc2P0DCQSIYW0ldQcV/eYT+F3MMnjXrfRxn9nv/T52so5GBxlFcYpuYqQXSLwh ouxAXYkqsSvtIgcmJUWyvthdEJJF/6GIaaQJhZEFwA1qZ3F2XCebzBxnoza2NrjJ q3UuZDjMDWvFagZ76WU9cTGKM2C6M7PiS2TZ0H5XU5c9WXk0omTRKbhVWY2tmZxt RhLw3316j5JQbkSl7U1D5kRgGFyWOEnSDmuhslNheN7Zzj5Mb7xhqCuzZ0PKJrcm weTL3sO2qZD4yDeSxK7hHx0yPKhz0e9oOB1acK6YQYJNmZInFSjAtKoRIQiyNV4o X0mG1/xmBOF1vOdkKz47SC7N9+nVNE2+TElVDqlF0cG6cb3qzVii9uOi3eJLZlo6 7XEMVT117ApuJfFZAn/EO/1yL6L3PDlmOrrwUYKpZN3Tk4rMEGajWgYH/6tYSanx FAq83n41jav5 =3DQOmj -----END PGP PUBLIC KEY BLOCK----- --------------040402020902060600040507--