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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5UEr-0002zj-Hq for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 07:27:53 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z5UEn-0003T1-VO for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 07:27:53 +0000 Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 0AFAB4120D for ; Thu, 18 Jun 2015 07:27:44 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id C9714400E7 Message-ID: <558272EE.9040305@riseup.net> Date: Thu, 18 Jun 2015 00:27:42 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bitcoin Dev Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.8 (-) 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5UEn-0003T1-VO Subject: [Bitcoin-development] Scope narrowing for proposals to address block size limit debate, an inquiry 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: Thu, 18 Jun 2015 07:27:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The purpose of this post is to present an inquiry related to the possible narrowing of scope of what sort of proposals are likely to "bear fruit" at this stage. The inquiry or question is, "Are there some proposals that are more likely to succeed, in addressing the whole block size limit debate meaningfully?" The flip side of this inquiry, is that if you think that an attempt to do such "scope narrowing" _at this time_ is foolhardy, inappropriate, wrong, or otherwise flawed, please say so and explain. I'm not religious about this notion. I throw out proposals below which I think would be likely to advance further ~ and thus I ask the question again, and rephrase, "Are there some proposals (some shown below as examples, not all-inclusive) that are more likely to succeed, in addressing the whole block size limit debate meaningfully?" ~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of Huobi's mining project Digcoin, clarified that the big Chinese mining pools consider further adjustments to the protocol beyond the suggested 8 MB block size limit adjustment =E2=80=94 such as the Bitcoin = core developer Jeff Garzik's BIP-100 draft =E2=80=94 to be feasible) ~ Adam Back, with a simplified soft-fork one-way peg ~ Gavin Andresen, developing an 8 MB block size limit adjustment in the context of Core (as an example) with one or more of the above authors rather than focusing on XT. (This is a big assumption but, roll with it) All of this assumes that developer(s) are willing to abandon intentionally contentious proposals such as the "hard fork to XT w/ 20 MB," remain within the context of Core and be reasonable. Here I am being aware of the fact that "Pushing a hard fork in the face of such controversy is a folly, a danger to the network, and that deserves to be said." - Wladimir J. van der Laan https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917 And if I'm lucky, this thread may get comments from DumbFruit, who writes stuff like this: https://bitcointalk.org/index.php?topic=3D1085436.msg11643203#msg11643203 So now... your thoughts? - --=20 http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVgnLuAAoJEGxwq/inSG8CchMH/0zm+A7Uqp8SpU+CsJr3lF2+ 0re+5Ql4qVVmOI560918BtkdFjcq33jsKU9cYUDXqZ4wHfJTAGLGDqNgUZGpGkmJ bqGgSvdF64P52Vb9PVnz1I9+aClas8Mjvl8XUYoD0yEA14XVBakYDRbVqZ5yPM8n hBi6EpWLUnkFvvEj2dkgwddvPCvrnhVL/aRfmhet1pfOELfIrXtXI7hs2F1RyaqK sbR/Qg3SFlyHzbxSzRVcZQ0G81exq/fxHqxc5kSLMiR7TODIJxCl6cJDCjf8LbeS n6tL/I8vWN2zraYfb0cWu5uIjz5XnXpsitu951109zoS8IYle3uTfCF+6xdG3tY=3D =3DHQ9R -----END PGP SIGNATURE-----