From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YyVhr-0007gd-4n for bitcoin-development@lists.sourceforge.net; Sat, 30 May 2015 01:36:59 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.44 as permitted sender) client-ip=209.85.220.44; envelope-from=da2ce7@gmail.com; helo=mail-pa0-f44.google.com; Received: from mail-pa0-f44.google.com ([209.85.220.44]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YyVhp-0003yj-86 for bitcoin-development@lists.sourceforge.net; Sat, 30 May 2015 01:36:59 +0000 Received: by pabru16 with SMTP id ru16so71847457pab.1 for ; Fri, 29 May 2015 18:36:51 -0700 (PDT) X-Received: by 10.68.195.2 with SMTP id ia2mr19846907pbc.33.1432949811511; Fri, 29 May 2015 18:36:51 -0700 (PDT) Received: from [192.168.1.63] (n119237161167.netvigator.com. [119.237.161.167]) by mx.google.com with ESMTPSA id bt16sm89736pdb.91.2015.05.29.18.36.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2015 18:36:50 -0700 (PDT) Message-ID: <55691427.6000600@gmail.com> Date: Sat, 30 May 2015 09:36:39 +0800 From: Cameron Garnham User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <16096345.A1MpJQQkRW@crushinator> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cWjc4qi9xNuOWrGi3ET8Wp7EQFX21X8dT" X-Spam-Score: -1.4 (-) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (da2ce7[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (da2ce7[at]gmail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YyVhp-0003yj-86 Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function 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: Sat, 30 May 2015 01:36:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cWjc4qi9xNuOWrGi3ET8Wp7EQFX21X8dT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable First off, I am glad that the idea of dynamic block size adjustment is gaining some attention, in particular the model that I proposed. I wanted to take some time and explain some of the philosophy of how, and why, I proposed this this particular model. When Bitcoin was first made, there was a 32MB block size limit; this was quickly found to be open to spam (and potentially DOS, as the code was not-at-all optimized to support large blocks), and was reduced to 1MB, this was a quick fix that was never intended to last; at some point the network should come to an understanding, a consensus if you will, of what (and how much) belongs in a block. The core point of this is that miners have always, and will always; hold the power, to decide what goes into blocks; this implicitly, obviously, includes how large blocks are. Miners are able to come any sort of agreement they wish, providing the bitcoin clients accept their blocks as valid. Say if Satoshi never decided to place the 1MB block limit: It would be up to the miners to decide what they consider a =91reasonable=92 block is= =2E However, they would need to find some way to communicate this and reach an agreement; some protocol. They, say, could have done this informally on what is now the bitcointalk forum, or used Twitter. However, what they really need is indeed a "consensus protocol". Some simple terms to define what is acceptable and what is not. Hence, the proposal introducing a consensus protocol for block sizes; instead of just having a hard limit (enforced by everyone), instead, we have a constant factor above the average block size over a fixed intervals that is soft-forked by only the miners. (The next simplest mathematical construct). This proposal is entirely a soft-fork and may be implemented without changing any client code what so ever. In-fact, it could be implemented by only a simple 51% majority of miners, with-or-without gaining the wider community consensus. (Assuming that the 1MB block size rule still applies). The nice thing about this is that it really is impossible to stop, for-example, if pre-relaying of block headers is implemented; the miners could always soft-fork to include the block-size in the coinbase. The only reason that the miners have not done this yet, is that there has not yet been a strong will to increase transaction fees. If we assume the miners will operate in a way to collectively maximize profit; then we can assume they will not try to maximize utility of the network (having as many transactions as possible), rather have as few transactions as the total economy can support the cost. Meaning that limiting to much smaller blocks will probably be much more profitable than having large blocks. Since there is no requirement for the clients to know about the block size consensus protocol, this truly can be a =91bi-directional-soft-fork=92, in that the miners can choose to change the rules at any time, with only a simple 51% majority. Therefore, any parameters that we pick are always up for debate. Why the 1.5x over 2016 blocks? - Using some game theory, and deduction: I wished to pick the type of agreement that would be natural for the miners to come to (selfishly). First, Why 1.5x, this means that only a super-majority of miners can easily increase the block size. =96 There is no natural incentive for miners to produce large blocks that have very few fees. Second, Why 2016 blocks for adjusting the average: Miners HATE unpredictability, for shorter time periods the miner will need to have infrastructure ready to support potentially much larger block almost immediately. 2016 blocks is a period that the miners are already well used to, meaning that it will take slightly less than a month for blocks of double size to be permitted. This entire infrastructure can be implemented without needing to update any clients; once implemented, tested, solid, and well accepted by the (mining) community then we can revisit increasing the 1M hard limit. (If we still have demand for it, maybe the average block size will reduce to say, 100KB). Cam. > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >=20 > While being in the Bitcoin community for a long time, I haven't > been so directly involved in the development. However I wish to > suggest a different pre-hard-fork soft-fork approach: >=20 >=20 > Set a 'block size cap' in the similar same way as we set > difficulty. >=20 > Every 2016 blocks take the average size of the blocks and multiply > the size by 1.5x, rejecting blocks that are larger than this size, > for the next 2016 period. >=20 > I would of-course suggest that we keep the limits at min 100kb and > max (initially) 990kb (not 1mb on purpose, as this should become > the new limit), rounding up to the nearest 10kb. >=20 > A: we don't have pressure at the 1mb limit, (we reduce the limit in > a flexible manner to 990kb). >=20 > B: we can upgrade the network to XYZ hard-limit, then slowly raze > the soft-limit after being sure the network, as-a-whole is ready. >=20 > If we on-day remove the block-size limit, this rule will stop a > rouge miner from making 10mb, or 100mb blocks, or 1gb blocks. >=20 > This could be implemented by the miners without breaking any of > the clients, and would tend to produce a better dynamic fee > pressure. >=20 >=20 > This will give the mechanics to the miners to create consensus to=20 > agree what block-sizes they believe are best for the network, and=20 > allows the block-sizes to dynamically grow in response to larger > demand. >=20 >=20 >=20 > On 5/8/2015 10:35 AM, Pieter Wuille wrote: >> On May 7, 2015 3:08 PM, "Roy Badami" wrote: >>>=20 >>> On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: >>>> I would not modify my node if the change introduced a >>>> perpetual 100 BTC subsidy per block, even if 99% of miners >>>> went along with it. >>>=20 >>> Surely, in that scenario Bitcoin is dead. If the fork you >>> prefer has only 1% of the hash power it is trivially vulnerably >>> not just to a 51% attack but to a 501% attack, not to mention >>> the fact that you'd only be getting one block every 16 hours. >>=20 >> Yes, indeed, Bitcoin would be dead if this actually happens. But=20 >> that is still where the power lies: before anyone (miners or=20 >> others) would think about trying such a change, they would need >> to convince people and be sure they will effectively modify >> their code. >>=20 >>=20 >>=20 >> ----------------------------------------------------------------------= > >>=20 - -------- >>=20 >>=20 > One dashboard for servers and applications across > Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications=20 >> Performance metrics, stats and reports that give you Actionable=20 >> Insights Deep dive visibility with transaction tracing using APM=20 >> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>=20 >>=20 >>=20 >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net=20 >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>=20 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 >=20 > iF4EAREIAAYFAlVMKZYACgkQBJ8cMDO159aTiQEApTITEBrhE1DRbj/w+GncNeqB=20 > 0hGvmIBa1z0hGww0kaMBAOhxjn/K5leRJgdt1fKhNEDKKHdeCOIX3QRgry90D3NO=20 > =3Dp0+H -----END PGP SIGNATURE----- --cWjc4qi9xNuOWrGi3ET8Wp7EQFX21X8dT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlVpFDQACgkQBJ8cMDO159bI2wD9HhWEr5Nmc5wkCZEPb6+Kjy9Q hYeBf/l3MIN8aIapyMQA/0nhr9fIe/bJM14e95KM1g1cOd2DaMHPN7mJkdKqAwJE =5fhM -----END PGP SIGNATURE----- --cWjc4qi9xNuOWrGi3ET8Wp7EQFX21X8dT--