From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqYiP-0002vu-Mg for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 03:12:41 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.175 as permitted sender) client-ip=209.85.192.175; envelope-from=da2ce7@gmail.com; helo=mail-pd0-f175.google.com; Received: from mail-pd0-f175.google.com ([209.85.192.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqYiO-00023I-LL for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 03:12:41 +0000 Received: by pdbqd1 with SMTP id qd1so59353046pdb.2 for ; Thu, 07 May 2015 20:12:35 -0700 (PDT) X-Received: by 10.68.213.135 with SMTP id ns7mr2814316pbc.157.1431054743121; Thu, 07 May 2015 20:12:23 -0700 (PDT) Received: from [192.168.1.63] (42-98-198-160.static.netvigator.com. [42.98.198.160]) by mx.google.com with ESMTPSA id fo5sm3492668pbb.41.2015.05.07.20.12.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 20:12:22 -0700 (PDT) Message-ID: <554C2996.5030509@gmail.com> Date: Fri, 08 May 2015 11:12:22 +0800 From: Cameron Garnham User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20150507200023.GI63100@giles.gnomon.org.uk> <20150507214200.GJ63100@giles.gnomon.org.uk> <20150507220848.GK63100@giles.gnomon.org.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: 1YqYiO-00023I-LL Subject: Re: [Bitcoin-development] Mechanics of a hard fork 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: Fri, 08 May 2015 03:12:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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: Set a 'block size cap' in the similar same way as we set difficulty. 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. 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. A: we don't have pressure at the 1mb limit, (we reduce the limit in a flexible manner to 990kb). 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. 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. This could be implemented by the miners without breaking any of the clients, and would tend to produce a better dynamic fee pressure. This will give the mechanics to the miners to create consensus to agree what block-sizes they believe are best for the network, and allows the block-sizes to dynamically grow in response to larger demand. On 5/8/2015 10:35 AM, Pieter Wuille wrote: > On May 7, 2015 3:08 PM, "Roy Badami" wrote: >> >> 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. >> >> 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. > > Yes, indeed, Bitcoin would be dead if this actually happens. But > that is still where the power lies: before anyone (miners or > others) would think about trying such a change, they would need to > convince people and be sure they will effectively modify their > code. > > > > ---------------------------------------------------------------------- - -------- > > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights Deep dive visibility with transaction tracing using APM > Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlVMKZYACgkQBJ8cMDO159aTiQEApTITEBrhE1DRbj/w+GncNeqB 0hGvmIBa1z0hGww0kaMBAOhxjn/K5leRJgdt1fKhNEDKKHdeCOIX3QRgry90D3NO =p0+H -----END PGP SIGNATURE-----